Stop trying to 'be original' and be prolific instead (2016) - <AUTHOR> http://prolifiko.com/prolific/ <comment><USER2> I stopped caring about this type of ambition porn in my late twenties, and I'm a lot happier for it. I'm a lazy, average guy who will probably have a pretty average life. When I stopped being so "hungry," it opened up a world of tranquility and joy that had always been there.

<comment><USER3> There's a weird mentality in America (assuming that's where you are located) that average is bad.

Average is just average. There's no reason you need to be a multi-millionaire with 6 houses, 12 cars, and endless spending cash.

I also think that there should be more emphasis on separating personal/professional ambition from how much you earn. When people talk about career goals, they usually only mean "money making goals".

There's nothing wrong with working just enough to survive and finding satisfaction outside of spending money on crap you don't need. There's nothing "lazy" about making a living (even if its bare minimum to pay the essential bills).

What's the point in working 80 hour weeks for a set number of years, spending money excessively, and having a heart attack by age 50 from being over worked? Personally I'd rather be dead broke and happy then over worked and stressed about un-important crap.

That's not to say you shouldn't work hard towards your goals, they should just be defined out side of "make more money so I can impress my friends with a new car"

<comment><USER4> Hyperbole about stress-induced medical problems aside, money is quantifiably good. A man who makes 10x your salary can take 10x more vacations to the south of France, justify taking more time off work to spend with his family, doesn't have to worry as much about monetary concerns like loan payments or health problems, and so on. It's not just "impressing your friends", having a nice car can be a joy in and of itself, but I'm always weirded out by people who say they don't want social status.

<comment><USER5> I don't understand it either. I can't begin to list the comforts and options that come from being rich. Guess we all know. There's really no alternate reality where it's much better to be average and have little or no options.

I usually take the view that I'd listen more to you if, to prove your point more empirically, you got reasonably rich and then just decided to give away all your wealth and resign to some lonely cabin in Maine.

<comment><USER6> >I can't begin to list the comforts and options that come from being rich.

I can't either, but for a rather different reason. What exactly does being rich get you these days?

You get to sit in a slightly nicer seat on an aeroplane. You get to drive a car that has vastly more power than any sane person needs, rather than one that merely has substantially more power than any sane person needs. You get to own a house with a lot of surplus rooms to fill up with stuff that has no discernible impact on your standard of living.

Rich people don't get access to a super-duper internet, they don't get to watch better movies or listen to better music, they don't really get to make better friends. Most material comforts are perfectly accessible to someone on an ordinary middle-class income.

Never having to work again is cool, but most people are unlikely to reach that point. Your probability of accumulating that level of wealth before retirement age is remote, the hedonic treadmill is a powerful trap and most people find meaning and value in work anyway.

Being average isn't better than being rich, but it isn't much worse either, at least not in a country with a sane government. The stuff that makes a real difference is mostly a matter of public policy - Germans and Scandinavians don't live in fear of a medical bankruptcy or an at-will dismissal, nor do they desperately want to own a home to escape shady landlords and rising rents.

<comment><USER4> But wealthy people DO have access to better internet (speed and quantity) and have more leisure time to enjoy media. Also you can do other neat things, like pay for your childrens' education. THAT is a list that goes on for a while.

And the statistically average American is barely treading water. I realize that the average European is better off, but that's not relevant to America right now.

<comment><USER6> Again, it's mostly public policy. I can get unmetered 100Mb/s broadband for $42 a month, because the broadband market in my country is competitive and well-regulated. Paying for your childrens' education is a completely alien concept in many countries, because public primary and secondary education is uniformly excellent and university is state-funded for all.

Financially, the average European is a fair bit worse off than the average American. Gross median household incomes in Germany are about 25% lower than in the US; America has the sixth highest median household income in the world. GDP per capita tells a similar story. This simply isn't a question of money.

Americans don't need to get rich, they need to vote for someone who gives a damn.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> There was an interesting study I remember reading along these lines.

They took two equivalent classes of pottery students. Group A was told that they'd be graded based on the number of pieces made, while group B was based off the quality of a single submitted piece. Following the given incentives involved, group A made a bunch of pottery, while group B tried really hard at making good pottery.

What's interesting is at the end of the class, group A's pottery was better than group B's. Making a lot of pottery without caring about the quality of any individual piece is _better_ at making high quality pottery.

The key takeaway I got is that you're generally able to magically become better at things you do a lot of. So if you want to get good at something, just do it more, and results will generally follow.

<comment><USER8> My 2 moneys.

I worked in construction a while ago. I was always slow, pedantic, and the work i did usually reflected that (usually, some things benefit from being done fast). Everybody kept telling me that i was slow so one day i said "f it" and started working faster. The quality of work went down, for obvious reasons, and never got to the quality that was before (for most of it, some work like cutting things to size stayed precise). But if you, for example, paint a hundred windows really fast, you will probably not find many windows painted nicely. (mind you that nobody notices the little imperfections in construction, like, for example, a drop of white wall paint on the white radiator pipe)

Of course doing more means learning more, but so does thinking and experimenting.

Pottery, i never tried, but i assume it is more about the "feel" then anything else. While programming benefits a lot more from learning random stuff. It's easier to write a huge mess of code that works fine then it is to make a huge pot that doesn't fall apart.

All in all, why not bout ? Hack some 100 programs quickly, and write a couple programs with lots of preparation and research.

<comment><USER9> Do you think there was any change in quality from the first window you painted after you decided to start going fast, versus the last one? Like, did you get better at painting windows quickly, even if they weren't up to the quality of the pedantic, slow one?

<comment><USER8> It was a long time ago and i did do more of the heavier construction then stuff like painting.

Biggest thing i learned from doing things quickly is where precision matters and where not. For example if i'm painting the ceiling it doesn't matter if i touch a wall as i will paint that wall later (unless i splat a bunch of it, ofc), but it does matter if i touch the ceiling when i'm paining the wall. Of course painting things quickly brings the risk of spraying paint around, especially when using a roller. Painting things too slowly can also be bad if the paint is highly viscous, like with the paint for outside metal surfaces (railings) as it ends up being obvious where you stopped to detail something else. Or wall paint if you cba to do it in two layers so you mix thicker paint and do it in one.

With windows specifically (and doors and such) you would put the.. paper tape (idk how to translate it) (edit: masking tape) some 2 or more cm wide on the edges so you would have a nice margin of error. With paining fast there is a bigger risk of going over it, and that can be bad (oil based window paint on a wall is really bad, wall paint on a window easily goes away with a wet rag).

In most construction it doesn't matter if you are little off, it was just me being anal.

TL;DR I learned where it matters to go a bit slower and where i can go fast without consequences.

edit: Forgot to answer the question. Yes, i did get better. Mostly because i learned where i _can_ go fast and where i need to pay more attention. Learning to not wave brushes full of paint around like a figure skater also had a bit to do with it. I did also learn that some things come out better by default if you do them fast.

<comment><USER10> As someone who spent ~10 years in construction (log homes mostly), only newbies and weekend warriors seem to have this mentality. Yeah, always do quality work, but unless you are an artist, you've gotta get shit done quickly.

I've tried to paint my own house and my professional painter friends can absolutely destroy me in both speed & skill. A major problem I have is smooth caulking. It takes me forever to shittily caulk a window while a pro can make a few quick swipes and be done.

</comment></comment></comment></comment></comment><comment><USER11> My wife is a 3D print-designer, who takes her prints to craft shows. We've quickly learned that the best way to increase sales is to have a large variety of designs rather than a smaller selection of high-quality designs. She can make $30 selling one high-quality replica of a historic landmark that took her weeks of painstaking modeling time, but she has to find the one person who wants that print. Alternatively, she can mass-produce refrigerator magnets of birds, flowers, and animals that take just a few hours of modeling time and output them in such a variety that she can easily sell dozens in a day at $5 each.

It's what makes Amazon so profitable and AliBaba such a threat. It's the "longtail" business model, but for ideas. Like Linus Pauling said, "The best way to have a good idea is to have a lot of ideas."

</comment><comment><USER12> I've seen this advice repeated elsewhere, with more academic analysis. And also repeated in terms of startup advice.

patio11 has a phrase: "increase the luck surface", and it is kin to this as well. If % of Making It is 1 in 500, then it's much more straightforward to increase the number of dice rolls than to attempt the perfection of your roll.

This also ties into the findings about _grit_ , or perseverance through rough patches. Grit and trying over and over, learning each time, is a pretty good predictor of some decent success.

In my _own_ career, I've found that being aggressively prolific is key to getting better. Careful tweaking so as not doing the same thing over and over is hugely important as well: searching the learning hillclimb for improvement.

<comment><USER13> That phrase comes from the TechZing podcast ("increase one's luck surface area") and is a really valuable insight (surface area = depth of value created times breadth of people who see it), so all the credit to them.

<comment><USER14> Can you share which podcast it was?

Nvm. Reference : [http://www.codusoperandi.com/posts/increasing-your-luck- surf...](http://www.codusoperandi.com/posts/increasing-your-luck-surface-area)

</comment></comment></comment><comment><USER15> Winston Churchill produced 51 volumes of history and is generally regarded, in this pursuit, as having drank a cup and pissed an Ocean. I doubt they will continue to be read much once his personal historical aura has sufficiently faded.

Gibbon on the other hand in 6 volumes wrote a work that will probably be in print until Western Civilisation sinks into the dust.

So - kinda depends I would say.

<comment><USER16> > having drank a cup and pissed an Ocean

I've never heard this figure of speech and Google isn't turning anything up. What does it mean?

<comment><USER17> From the context, I think it means that the 51 volumes (the ocean) contains very little content (the cup). I also don't think the grandparent comment reflects the intent of the original post -- prolificness is the number of attempted works, not the length of any single work.

<comment><USER18> Churchill didn't write 51 volumes as one work; he was very prolific in the sense of many attempted works. Gibbon's six volumes were in a single work, and he wrote a few other shorter works. By the standard of number of attempted works, Churchill and Gibbon are good examples.

</comment></comment></comment></comment><comment><USER19> One of my favorite HN posts [1] relates directly to this. It was called "Prolific Engineers Take Small Bites". The big idea was to 1. take small bites, 2. make meaningful change, and 3. commit often. In the original article commit refers to committing to a repo. However, I treat it as commitment in a general sense. This mindset has considerably helped me keep on track with all my projects from game development, aerospace engineering day job, software contracting, learning to play music instruments, learning to draw, physical fitness, etc.

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

</comment><comment><USER20> YES YES YES!! More support for this!

That said, be prolific and deep...try not to repeat yourself depending on what you're doing but go deeper...

Aaron Levie of box.com I believe started 10 different websites and box.com was the one that took off.

A friend of mine in Japan started 3 companies...and only 1 took off...initially all 3 looked equally promising. Imagine if he took 2 years per experiment and gave up after 2 of the 3.

The hit rate of Beethoven between masterpiece and so-so piece was relatively steady in his middle and late periods.

Often works that are pre-planned "masterpieces" slaved over fail to engage, while some things made quickly live forever...think of Leonardo's drawing the Vitruvian Man, a quick sketch that's one of the most famous drawings in the world vs. his destroyed or not-made (I forget) statue of a horse (it is being re-built by someone and the world is still not taking much notice).

Google, Amazon, etc...how many failures do they have, if you look at that list they'd look like giant failures...remember Google Knol? The wikipedia killer. Or Amazon Fire Phone? Really embarrassing...do they care? Not at all! They simply don't care...but it's a little bit because despite a hundred failures, two of the more experimental things they did become $100 billion dollar businesses namely Android and AWS.

</comment><comment><USER21> I find the polarization of this debate a bit bizarre. While the article may have a point, I don't think anyone believes in pushing it to the absurdity of its logical extreme which would be to write terabytes of output using a pseudo random algorithm (plus a little learning from audience feedback).

So we see there should be a minimal acceptable quality for whatever you're doing, and if this is exceeded then by all means push out the volume.

The question then becomes, how to tell whether you're meeting the quality threshold?

I do agree that trying to be original is a red herring though. In a sea of mediocrity, being good _is_ an original outcome in its own right.

</comment><comment><USER17> I think this article is being somewhat selective in it's evidence. Several great mathematicians were highly selective in what they published, e.g., Gauss and Riemann. I don't think Einstein published that many papers. Though it might be the case that gauging quality is easier in math and physics, so being prolific is less important.

<comment><USER22> Gauss and Riemann may have been selective publishers, but they produced and thought about topics constantly. We can see this in their correspondence and private notes.

They probably weren't making lists of topics they wanted to study one day and getting stuck not even starting.

<comment><USER23> >They probably weren't making lists of topics they wanted to study one day and getting stuck not even starting.

Is that common? I have this problem of making lists of things that I want to do, but typically it doesn't get much further than that. I feel like a constantly plan, but never do anything.

Also, I agree regarding those that may have selectively published, it doesn't mean that they weren't incredibly prolific.

</comment></comment></comment><comment><USER24> _Alexander Dumas wrote a total of 277 novels over his lifetime – six every year of his working life_

Woah, that is _insane_.

<comment><USER25> It's also stretching the truth a little bit. Dumas had 45 employees who worked with him to write the novels. So, he was more running a studio with a process to create great novels rather than actually writing each novel.

<comment><USER26> Ah. So James Patterson didn't invent the fiction sweatshops?

Are all Dumas novels written this way? Even the 'big' ones like Count of MC and Three musketeers?

<comment><USER25> Hi, sorry, didn't see your comment before. Yes, even the big ones. A big part of the research and writing of the Count of Monte Cristo was done by Auguste Maquet who was one of his main ghostwriter. August Maquet also worked on all the sequels from the Three Musketeers but not the first novel.

</comment></comment></comment></comment><comment><USER27> This is basically an ad for their course. I'm not very impresseed with the article.

Writing comes really easily to me (many of you would say a bit too easily, considering my tendency to drop 1000 word comments on HN). I really don't think the route to quality is just churning out as much as possible; if anything, you run the risk of getting some small success and then churning out that lowish-level of quality for as long as the money keeps flowing. It's very obvious from a day reading blogs or magazines that there is a flourishing market for bad writing. In my view, the best way to improve your writing is to read. Read a lot, be snobbish about the quality of what you read, invest effort in reading stuff you find difficult to understand. Many people pursue style at the expense of learning how to write substantively; this is the literary equivalent of painting pictures with glitter. You might produce a masterpiece after a while, but more likely whatever you do is going to look really tacky.

It's easier to get paid if you're prolific and can churn out lots of material on demand. But you're also putting a ceiling on the quality of your output and probably your earning power. If you want to go good work, learn to work slowly and without the validation (and dopamine hit) that comes from a quick turnaround. I paint now and have a mix of simple things that I know out quickly and large difficult pieces that I labor over for months at a time and that are likely not that interesting or easy to appreciate to the casual glance. I like both kinds, but guess which ones have priority if the house catches fire.

</comment><comment><USER28> If you get really really good at something, original is automatic. And if you practice really really hard at something, getting good is automatic.

Passion is a simple advantage because it gives you the focus, the persistence, and the satisfaction needed to keep practicing efficiently.

Maybe it'll take 10 years to do what a genius could accomplish in 1, but if the genius is working on something else, it's all you. But even if not, your body of work will be different.

</comment><comment><USER29> Depth-first search through a concept space doesn't lead to originality as quickly as performing a breadth-first search at each new level of depth.

The shortest path to an idea may require disparate ideas.

I know I'm only rephrasing the headline, but the article's point follows easily from this model of how thoughts are structured in Memory Evolutive Neural Systems.

[https://doi.org/10.1016/j.pbiomolbio.2015.07.004](https://doi.org/10.1016/j.pbiomolbio.2015.07.004)

(to read for free, go to [https://sci-hub.bz](https://sci-hub.bz) and search for 10.1016/j.pbiomolbio.2015.07.004)

EDIT: To be clear, the point follows easily from the model, which says nothing about what's required to understand the model.

</comment><comment><USER30> I wonder if this has something to do with why certain comedians are so good (e.g., Carlin and Louis CK).

"...[Louis] wished he could be like Carlin and do new albums and specials every year — all of them brilliant. It wasn't until much later in his career that C.K. would get the important advice from Carlin to throw out all of his material every year and start fresh..."

[http://www.huffingtonpost.com/2011/09/06/louis-ck-honors- geo...](http://www.huffingtonpost.com/2011/09/06/louis-ck-honors-george- carlin-video_n_950134.html)

</comment><comment><USER31> Quantity trumps quality.

[https://blog.codinghorror.com/quantity-always-trumps- quality...](https://blog.codinghorror.com/quantity-always-trumps-quality/)

</comment><comment><USER32> Adam Grant whose book "Originals" is a main topic in this this article gave a great Ted Talk on "Originals" here:

"The surprising habits of original thinkers"

[https://www.ted.com/talks/adam_grant_the_surprising_habits_o...](https://www.ted.com/talks/adam_grant_the_surprising_habits_of_original_thinkers)

</comment><comment><USER33> Yeah, I have to say I agree with this article for the most part.

For example, I've spent most of my time recently as a writer, and found that it's been almost impossible to tell what works will become popular and what won't. You can throw something out in minutes and have tons of people sharing it and liking it, or spend months researching a piece and find that no one gives a toss.

But (somewhat sadly), I'm not sure I'd agree with the article that:

> being prolific doesn't give you an excuse to get sloppy and start blurting > out half formed ideas – that's just going to piss off everyone apart from > your mum. Your work still needs to be the very best you can do.

Because somewhat unfortunately, that's exactly what search engines and social networks kind of want now. They want quick responses to breaking news and trends, not well thought out pieces that take all the facts and views into consideration.

Look at YouTube for example. Many popular channels there basically cash in on whatever the latest controversy or drama is, usually within about a day of it occurring. A lot of popular games and apps are ones that literally just cash in on a recent trend, quality be kind of damned (see that Mega Man Xover 'fan game' which showed you could copy Capcom's product by spending 5 minutes in Flash or various game mods and stuff which stick Donald Trump into existing games). And when news is concerned... well, the most successful papers and sites (as far as traffic is concerned) are those that rush out stories as quickly as possible. Someone who watched yesterday's Pokemon themed Nintendo Direct would get a lot more clicks if they capitalised on the typo that said it'd released for the Switch rather than if they waited for more facts before proceeding.

So being prolific definitely helps more than trying to be 'original' and focusing too much on any one piece. But I'd also say the setup on a lot of modern internet sites actually goes further and kind of advantages people who can just get stuff done quickly in general, quality be damned.

</comment><comment><USER34> Well, being prolific OR a genius would be fine by me.

In the absence of either I do think it's valuable to try more things in parallel to see what works, and not get put off by 'failures' (experience you gained just after you needed it), or not being 'perfect' (since there rarely is such a thing, objectively).

</comment><comment><USER35> Exploiting a power law. Search it with content marketing. The article, like others on that site, also has a listicle, which you might also search with content marketing.

</comment><comment><USER36> When you are making rough drafts I agree. However once a rough draft has promise you need to spend a lot of time on it to make it good.

I have observed that authors tend to go downhill once they are known. The pressure to publish (more money I guess), along with name recognition meaning they don't have to put out quality work is my theory.

</comment><comment><USER37> Songwriters have realized this a long time ago. Most successful bands write between 80-100 songs per album release.

Hard work and practice pretty much always makes one better.

</comment><comment><USER38> Appreciate the simple distillation of a useful analysis.

</comment><comment><USER39> I was an intellectual whore for 25 years. Personally there is more joy and satisfaction in being original than there is in the money that results in being prolific.

I would rather make less and be happy.

<comment><USER40> Easy to say after 25 years of making money ;)

<comment><USER39> Would you rather find that out in 20 more years or now?</comment></comment></comment>


Validating Email Addresses with a Regex? Do Yourself a Favor and Don't - <AUTHOR> http://blog.onyxbits.de/validating-email-addresses-with-a-regex-do-yourself-a-favor-and-dont-391/ <comment><USER2>
      For the local part, we only accept an RFC5322 dot-atom. However, for practical purposes,
      we further limit {atext} to alphanumeric characters, hyphens, underscores and plus signs.
      The rationale here being to keep it simple for the software we are validating for (it must
      deal with whatever we allow to pass).

_ugh_ The dot-atom production in the RFC 5322 grammar is only for _unquoted_ tokens. There's nothing preventing an e-mail address from, e.g., having two adjacent dot characters in the local-part. Ignoring the fact that in 2016 we shouldn't be limiting local-part components to ASCII, adding more needless constraints is even worse.

RFC 5322 DOES NOT define the syntax of an e-mail address. It defines the syntax of embedding e-mail addresses in To:, Cc:, and similar headers. That's a critical distinction.

If you're using RFC 5322 as your guide, you _must_ handle text quoting correctly. Otherwise the dot-atom restriction is completely and utterly arbitrary. It's being chosen for basically no defensible reason; just to give an air of credibility to a really bad approach to implementing networking software.

FWIW, no finite state machine can parse RFC 5322 constructs correctly because of the way that comments can nest.

If you want to write a parser for mailbox addresses in MIME headers, just follow the algorithm DJB very helpfully explains at [http://cr.yp.to/immhf/token.html](http://cr.yp.to/immhf/token.html). It's much more correct; it harms interoperability less (if at all); and it's a great way to learn how to implement recursive grammars.

That said, finite state machines are very powerful. One could do much worse than learn a tool like Ragel. Its syntax supports both regular expressions _and_ state charts. The machines it produces are blazingly fast. And unlike almost any other tool, it supports restartable parsing so you can parse data off-the-wire without having to buffer all of it or even any of it. Most network protocols are line-based or TLV-based precisely because the tooling sucks for implementing restartable parsers. But Ragel is great even when you're afforded that convenience.</comment>


Gizmodo:  Latest firmware neuters the iPhone . . . upon re-review, don't buy the iPhone - <AUTHOR> http://gizmodo.com/gadgets/iphone/iphone-re+reviewed-verdict-dont-buy-302075.php From Gizmodo:<p>I was planning to change our "Wait" verdict to a full-on and rabid "Buy". That wasn't because of Apple, but because of the cool apps being offered by independent developers. All that came to an end yesterday after the new Apple firmware 1.1.1 neutered the handset.  With this, I'm going to have to move our recommendation from "Wait" to "Don't hold your breath." I'm done with this handset until third-party apps come back. <comment><AUTHOR> From the Gizmodo reviewer:

I was planning to change our "Wait" verdict to a full-on and rabid "Buy". That wasn't because of Apple, but because of the cool apps being offered by independent developers. All that came to an end yesterday after the new Apple firmware 1.1.1 neutered the handset. Sure, unlocked iPhones were broken. But more importantly, Apple wiped away the powerful programs that helped push the iPhone to greatness. With this, I'm going to have to move our recommendation from "Wait" to "Don't hold your breath." I'm done with this handset until third-party apps come back.

</comment><comment><USER2> The iPhone has been the best advertizing Nokia's N95 could get.

</comment><comment><USER3> Who are these people?</comment>


The $10 million Photo and other VC Stories - <AUTHOR> http://steveblank.com/2011/07/19/throw-in-the-painting-and-other-vc-stories/ <comment><USER2> It's a cute pair of stories, but the only lesson I can take away from them is that an eight-time startup founder with an ex-VC/Harvard professor partner can get away with things that most people can't.

Oh, and personal relationships are often more important than anything else, including preparation and well thought-out ideas.

</comment><comment><USER3> My key takeaway: Steve Blank is an asshole.

<comment><USER4> If you ever meet him in person, you'll say different. Irreverent yes, but not an asshole.

<comment><USER5> I have met him in person and strongly concur.</comment></comment></comment>


Creating Your First Gem - <AUTHOR> http://rubysource.com/creating-your-first-gem/ <comment><USER2> try</comment>


Modernizing "less" - <AUTHOR> http://garrett.damore.org/2014/09/modernizing-less.html <comment><USER2> It seems to me that many core tools could use such updates. They're widely used yet most of them predate modern development techniques and tools such as widespread linter usage, unit tests, peer reviews before committing, appearance of various stable and portable libraries or even compilers, security scans.

I wonder what other nasty things would appear after a serious code review of the GNU and BSD core code bases.

I do agree that the code has been read probably hundreds of times and executed millions of time, but I doubt there have been many formal attempts at improvement and the overall methodoloy resembles brute forcing to me.

I could be wrong.

<comment><USER3> FreeBSD has always done peer reviews which cover the entire base system, and it's now mechanized a bit: [http://julipedia.meroh.net/2014/05/code-review- culture-meets...](http://julipedia.meroh.net/2014/05/code-review-culture- meets-freebsd.html). Automated testing (kyua) and CI (jenkins) are also in progress.

<comment><USER4> They do security scans, yes, but not really full-system code-quality review down to the level of every system utility (esp. not those developed primarily elsewhere). At least in the specific case of 'less', it's almost just a formality that it's even in the FreeBSD SVN tree, since the only activity is occasional re-imports of the upstream version: [https://svnweb.freebsd.org/base/head/contrib/less/](https://svnweb.freebsd.org/base/head/contrib/less/) Afaict, this Illumos initiative is the first attempt in years by anyone to review/clean up the internals.

</comment></comment></comment><comment><USER5> While we're talking less(1) features, one I stumbled across a few years ago when wishing really hard that less supported an interactive regex line filter, was its interactive regex line filter:

        &pattern

Which will: Display only lines which match the pattern; lines which do not match the pattern are not displayed. If pattern is empty (if you type & immediately followed by ENTER), any filtering is turned off, and all lines are displayed.

I'd prefer this followed a syntax closer to mutt's filters, and that the patterns were editable (e.g., typing '&' during a filter would show the _currently_ extant filter for modification), but it's handy.

<comment><USER6> > I'd prefer [...] that the patterns were editable (e.g., typing '&' during a > filter would show the currently extant filter for modification)

If you type '&' then the up arrow, you'll get the previously entered pattern(s), which you can then edit.

<comment><USER5> Bless you. I didn't know that.

Which is why I share tips like this -- it's almost always a win.

</comment></comment></comment><comment><USER7> > Make less use getopt() instead of its byzantine option parser (it needed > that for PC operating systems. We don't need or want this complexity on > POSIX.)

This is the kind of thing that always astonishes me to see in a codebase: why reinvent something rather than just finding and including a compatibility implementation? Just grab an appropriate getopt.c and compile it in if the platform doesn't have one, then let the rest of the code pretend every platform has one. (Preferably an implementation of getopt_long; a quick search turned up some licensed under 3-clause BSD.)

<comment><USER8> less was started (~ '83) before getopt() was made available to the 'general' public ('85).

My guess is nobody bothered to replace these parts, since options were only added gradually; if at all. Coincidentally i'm in the same predicament with a tool a coworker of mine (initially) wrote, convoluted option parsing to say the least; but I'm too busy with fixing other parts or adding proper functionality to it than to replace it.

Sometimes, 'less is more'.

<comment><USER9> You couldn't help it, could you? :)

<comment><USER5> Many moons ago I mentioned the story of "more" and "less" to our (female) DBA, who was unfamiliar with the commands, and the expression "less is more".

"It's right in the manpage, actually". "No." "Yes, I'll send it to you."

And so I did, with the subject line "man less".

She sat at a desk right in front of mine, and I detected a somewhat painful silence as the email arrived. And realized I'd just inadvertently commented on her social life (confirmed through later conversations).

</comment></comment></comment></comment><comment><USER4> Interesting! From what I'm reading so far, this seems not to be Illumos- specific (despite being motivated by Illumos's needs), but rather a cleanup that'd be applicable to any POSIX-like system. A fork of less that assumes POSIX-like functionality and cleans up a lot of things accordingly does seem like a worthwhile project. A bit more "unixy" design that uses the system versions of available functionality (like globbing and UTF-8!) should also reduce the risk of weird bugs & inconsistencies with how the rest of the system operates.

</comment><comment><USER10> I've switched from less to most* some time ago, no idea how it looks underneath, but it works great for me. It seems to be available for most (tee hee) distributions.

* [http://linux.die.net/man/1/most](http://linux.die.net/man/1/most)

<comment><USER11> I used 'most' a few years ago because of the windowing support (this is before 'screen' did get support for vertical split). Also I did love about 'most' that it used to colorize manpages, when other pagers didn't.

I stopped using it, like 4 years ago, when someone did told me on IRC that it was unmaintained and did have some bugs.

Note that I did never notice any 'bug' in my time as 'most' user, even if they may exist, and indeed, it's still available at least in all Debian versions.

It's curious that distributions are able to "maintain" a package (maybe even with custom patches) which is not maintained or updated upstream, for years.

It's encouraging to see actions like the one performed by this IllumOS developer. If a program is opensource, we can fork, improve and share. Or as users, we can take a look at the code when making choices, lots of people forget this in favor of search engine recommendations.

<comment><USER12> The level of love packages receive varies -- I'm a great fan of Debian, but in the case of "most" support appears to be less than stellar from the Debian side:

[https://bugs.debian.org/cgi- bin/pkgreport.cgi?which=maint&da...](https://bugs.debian.org/cgi- email@example.com&archive=no&raw=yes&bug- rev=yes&pend-exc=fixed&pend-exc=done#_1_4_5)

<comment><USER13> I think you mean [https://bugs.debian.org/cgi- bin/pkgreport.cgi?package=most](https://bugs.debian.org/cgi- bin/pkgreport.cgi?package=most) \- which doesn't look too bad.

<comment><USER12> Well, yes. In either of the links -- I was thinking about the two normal- priority forwarded bugs for "most" (files starting with dash, sigpipe) and their age...

</comment></comment></comment></comment></comment><comment><USER14> It's crazy to me that something as core as less has such bit rot. I'm aware GNU rebuilt a bunch of tools a while ago and added a slew of common features such as `-h` for human readable mode, and `--` long arguments. Does this rewrite have a name yet? and can it be brought into the core project at all? (or the GNU project?)

<comment><USER15> Being part of the GNU project doesn't mean it's going to be maintained. For example, bzr supposedly is a core GNU package, and it's dead.

Being a GNU package just means you agree to behave in a GNUly way. It's a very informal and easily-granted qualification.

</comment></comment><comment><USER16> A faster string search would be nice. I used to (and still sometimes do) use less to analyze large trace files. With a few hundred MB the searching becomes a real bottle neck.

Couldn't be that hard to do a boyer moore for non RE substrings.

<comment><USER17> Would using ag help? No longer maintained AFAIK, but fast for me.

<comment><USER18> where did you get that idea? last commit was 7 days ago, no mention of abandonment

<comment><USER17> From the status of the Ubuntu ppa, and (I thought) comments on his site. Thanks for pointing out that's not the case.

</comment></comment></comment></comment><comment><USER19> Nobody needs POSIX conformance in an interactive pager; that's just conformance for the sake of conformance. Or do they? What is the economic justification ("business case") for working on POSIX compliance in a "more" command?

You should never invoke "more" directly in a script anyway, but rather observe the PAGER environment variable, and fall back on a plain "more" only if that isn't set. (Speaking of which, PAGER _isn 't_ described in POSIX, oops!)

If the user wants the pager to exit when the last line is reached, the user can specify the necessary option in PAGER, if their pager supports it. PAGER just has to be properly expanded: treated as a command, not a command name.

</comment><comment><USER20> Some yaks look really good bald. Well done.

</comment><comment><USER21> Seems weird to hear about less being used "to meet POSIX" requirements, since I use it at least 10 times a day -- interesting read though.

</comment><comment><USER22> Cool, but terminfo and curses are another bunch of things I'd like to see go.. or at least delegated from the core of every fullscreen terminal application to a special compatibility layer (e.g. tmux or screen) for those using terminals which don't speak ANSI.

I've looked at it before, and I agree less is a mess.

</comment><comment><USER23> I got excited to click on this, imagining that someone was modernizing less. Which is true in a narrow sense, but am I the only one to feel a lingering disappointment that we run shells in xterms (or slightly modified equivalents) that emulate ancient terminals, then implement pagers to page through screen after screen?

Can anyone point to work that starts with the _combination_ of the two following propositions:

1\. User interface elements invented since the 1970s are a pretty neat thing.

2\. Text-based shells and the command line are also a pretty neat thing.

<comment><USER24> There was TermKit ([https://github.com/unconed/TermKit](https://github.com/unconed/TermKit)) but the author has stopped working on it.

<comment><USER23> Yes. His sentiments here [http://acko.net/blog/on- termkit/](http://acko.net/blog/on-termkit/) are very close to mine: "It makes me wonder, when sitting in front of a crisp, 2.3 million pixel display (i.e. a laptop) why I'm telling those pixels to draw me a computer terminal from the 80s".

I'm not crazy about every last aspect of his design there - but it's a start.

</comment></comment></comment><comment><USER25> I just use 'view'; its the same as running 'vim -R'.

<comment><USER4> I find 'view' fine for things like looking at a logfile, but not great for one of my more common use-cases for a pager, which is looking at something from stdin that's either large or slow-to-produce. You have to wait until vim reads in the entire stream before you can do anything with it. With 'less' you can immediately navigate/search/etc. while the stream is still coming in.

<comment><USER26> Also, the default action of the cursor keys is more useful for paging in less than in view. In view, cursor keys move the cursor; in less, they scroll the screen.

And less has built-in tailing which you can start and stop at any time. That's its killer feature for me.

On the other hand, vim/view can have some nice syntax highlighting for syslog format log files. I haven't found that enough to switch though.

</comment></comment></comment><comment><USER27> Modernizing less to me means using most: [http://www.jedsoft.org/most/](http://www.jedsoft.org/most/)

</comment><comment><USER16> Also it would be nice if the original author could put this work up as a tarball with standard make files somewhere so that other OS can benefit.

</comment><comment><USER28> Thank you for this effort. It is badly needed.

</comment><comment><USER29> These changes really need tk be upstreamed...

<comment><USER26> It's probably not that simple. The article indicates that the refactor removed support for a lot of old platforms which the project may very well prefer to keep.

</comment></comment><comment><USER30> Cool, but I was hoping he meant less the CSS extension :-)

<comment><USER5> Ambiguity is program / feature names is a constant (and growing) issue. Though less(1) _is_ the rather more established of these two instances.

<comment><USER30> Well, it's certainly _older_. It's not really so ambiguous since the CSS version is "LESS". Speaking as someone who cut his teeth on the command line, I clicked the article thinking that it was referring to LESS since the idea of modernizing less never occurred to me (even though it's a much older piece of technology; LESS is much more broken...)

</comment></comment></comment><comment><USER31> A lot of people are talking about revamping these old programs. I don't see what the problem is with less, cat, vim, etc...

I've never been using a program and wished for better functionality. Even when this was all new to me, it was never a problem figuring these out, using them, and I was always satisfied with them..

So...here's the question. I don't think these are broken, so what are you fixing?

<comment><USER32> > _So...here 's the question. I don't think these are broken, so what are you > fixing?_

First, it's not just about something not working. It's about creating tools that are extensible and understandable and hackable. Open Source is not just about "working", it's about being modifiable by the end user. All this cruft (a mess of 200 obsolete architectures, dead code and deprecated library support that nobody used since 1988) works against that goal.

Second, there are things that would be essential for some people, like international users (e.g proper multibyte support) that cannot be added due to dependancy of some custom methods of handling encodings. That's not some wishy washy magical unicorn feature request, it's essential for the main operation of what less does for those that have to deal with these encodings.

Third, there's nothing wrong in taking pride and crafting finely your tools. UNIX is supposed to be made of things that "do one thing and do it well". Less having its own utf-8 support breaks this division of responsibility. We have libaries for that. Same for getopts vs it's custom options parsing.

<comment><USER22> What's the library for UTF-8?

<comment><USER4> At least for programs written in C, most (all?) modern Unix-like platforms should include the functionality in the base install. On the language side, C89 requires support for wide and multibyte characters in a conforming libc implementation. And POSIX furthermore requires a locales/iconv system to specify and convert between encodings. Neither of those strictly require that UTF-8 be one of the supported encodings (C89 predates Unicode), but any reasonably modern implementation will include Unicode locales. And if it doesn't, I think at this point you can just consider that to be the system's problem: the current assumption for POSIXy programs is that they will use the system locales, not try to implement their own encoding machinery.

</comment></comment></comment></comment><comment><USER33> Note: this is not referring to the compile-to-CSS language named Less

\-----

Downvotes for clarifying an ambiguity, really?

<comment><USER34> What does it add to the discussion?

<comment><USER5> Clarity, without having to follow through to the article.

The lack of any context for HN posts (also reddit link shares) is a significant disadvantage of both sites. I've always been partial to Slashdot's link summaries, and wish that style were more widely used. See also Jakob Nielsen and microcontent.</comment></comment></comment>


Ask HN: What are you reading? - <AUTHOR> Curious what people are currently reading that they find interesting. I'm between books and looking for recommendations. <comment><USER2> 1\. The Problem of Pain by CS Lewis 2\. A Philosophy of Software Design [https://www.amazon.com/dp/1732102201/ref=cm_sw_r_cp_api_i_EK...](https://www.amazon.com/dp/1732102201/ref=cm_sw_r_cp_api_i_EKcbCbBZD4121) 3\. Haskell from First Principles [http://haskellbook.com](http://haskellbook.com) 4\. Les Miserables 5\. Continuous Delivery [https://continuousdelivery.com](https://continuousdelivery.com)

</comment><comment><USER3> Note sure if I'll be reading it in the future, but right now I am checking out The Book Of M [0].

[0] [https://books.google.com/books?id=EYEzDwAAQBAJ&pg=PT3&source...](https://books.google.com/books?id=EYEzDwAAQBAJ&pg=PT3&source=kp_read_button#v=onepage&q&f=false)

From time to time I like to revisit Clive Barker because his language is spectacular.

</comment><comment><USER4> Fiction : 'The Wind-Up Bird Chronicle'

Non-Fiction : 'The Art of Thinking Clearly'

</comment><comment><USER5> Seeing Like a State, James C. Scott

Grit, Angela Duckworth

SPQR: A History of Ancient Rome, Mary Beard

Deep Work, Cal Newport</comment>


Does Software Culture Reward Failure? - <AUTHOR> http://www.skorks.com/2009/09/does-software-development-have-a-culture-of-rewarding-failure/

<comment><USER2> I don't think that software culture per se rewards failure, but rather that emergent behavior in large groups, particularly corporate IT groups does reward _some_ failure.

If you, as a manager, can't point to _some_ failure, and the resulting heroics to get the system back up, then you, the manager, can't stand up in a meeting to receive pats on the back and "atta boys".

Of course, it's a narrow window. Too many failures, and you get in trouble. Too much smooth sailing, and you have too many people, and your empire gets shrunk forcibly.

</comment><comment><AUTHOR> This article explains a lot about a problematic programmer I've had the misfortune of working with. Although he presents the air of a "great programmer", it's actually because his architectural abilities are absent. Given a small project, he'll do a good job of it-- and very fast, since he doesn't care about things like unit testing. Given a large one, he'll make a mess that even he can barely sort out. I can see how, in some environments, he'd look like a hero for being able to tackle supposedly complex problems (although it's his terrible coding habits that make such problems seem so complicated).

I hate hate hate "rockstar" programmers (and, yes, the Kefka-style "hate hate hate" is appropriate).

I also think there's an inherent mismatch between management and technical people regarding how to present the difficulty of one's work. Managers want to present their jobs as easier than they are, because it makes them seem smooth and astute. At least some technology people have a habit of overstating the difficulty of their work, in order to make their efforts seem heroic.</comment>


Show HN: A middleweight CSS grid-able unframework - <AUTHOR> http://wail.es/opendaws/

<comment><AUTHOR> This came about out of a desire to build a semantically correct framework, without the heaviness of Foundation & Bootstrap etc, and with baseline aligned typography and forms. Demo available here: <http://wail.es/opendaws/demo.php>

Feedback hugely appreciated.</comment>


How Amazon's new tablet signals the start of next generation - <AUTHOR> http://www.geekwire.com/2011/amazons-entry-tablets-signals-start-generation

<comment><AUTHOR> I think the interesting thing in the looming Amazon/Apple battle is their approach to the app store. Apple considers themselves a hardware company, and sees the marketplace portion to be a loss-leader.

Amazon doesn't care about the hardware side of the business-- they see the device as a catalog-- perhaps a bigger gateway to commerce and intent than Google.com ever was. Making profit on hardware is like Google charging users to do searches-- there are much more elegant ways to make money with mobile devices than simply charging for hardware.

<comment><USER2> You're right, Amazon's Kindle line is a catalog device and much like print catalogs, they're sold at a subsidized loss with the hopes of generating core business sales, but the Kindles aren't core to their business in the same manner as the iOS devices are core to Apple's.

Their use cases and population sets are so disparate that anyone making a claim that Amazon has somehow entered a tablet war with Apple is either an AMZN investor or is someone hell-bent to get their name in print regardless of the accuracy of their assumptions or their tolerance for embarrassment. That's if there was a theoretical tablet war in the first place.

Please read: [http://www.asymco.com/2011/09/30/the-case-against-the- kindle...](http://www.asymco.com/2011/09/30/the-case-against-the-kindle-as-a- low-end-tablet-disruption/)</comment></comment>


Ask HN: I quit my job to start my own company. Now what? - <AUTHOR> For the last 5 years I've been the lead developer at a technology company in Nagoya that specializes in digital signage and custom internet solutions.
Over the last year and a half, I came to realize that I was not happy at my current job, and that I was depressed with the way that much of Japan handles developments in technology, specifically their reluctance to embrace such basic concepts as data-driven development and customer pattern analysis. (or even such simple things as being searchable on Google!)
For Japan to succeed in a global (and even domestic) market, that has to change. I want to help bring about that change, and I've come to realize that I can't do that at my current job.
So because of a dream to change Japan (and the constant prodings of Patio11) come August, I will no longer be employed at my current company, and frankly that scares the bejesus out of me.
I have contacts, and I can probably make it as a freelancer, but that's not the reason I quit (although being freed of salaryman hours is a nice benefit).
I have a dream, but don't know how to bring it about. It may be a stupid thing to post on a public forum, but it is what I believe in.
Are there any of you on HackerNews who have been in the same position? What helped you see your dream through? <comment><USER2> I quit my day job in May to work on an idea. It was a good job, but I simply had to do it so I quit within the week. Since then I've been working at home and it has been up and down--mostly ups :)

Looking at my journal* (personal work journal), it went like this: Tuesday: came up with idea. Wednesday: had dinner with previous startup CEO who I remained friend with. He expressed that it was a good idea and if I wanted to learn the pain of startup for myself, I should do it. Thursday: thinking... lots of thinking--then I came to a conclusion: it must happen NOW! Told my work people and they were very supportive. Friday: I left the company on good terms (the company told me to come back once I have my product developed, they'll be the first customer).

2 things I believe in: 1) you do it because you HAVE TO do it--you cannot live without it. 2) you're always about a few years late :P

With that being said: 1) I am married and my wife and I had some cash to sustain us for a few months so I do have a bit of a nest and health insurance is on the wife 2) My idea is very simple and I believe it can be accomplished within a short time. 3) I cannot live without doing it (living without passion is simply surviving)

If you truly believe in your vision, then you should have no problem laying your life down for your vision. If you are willing to put your life on the line, then like Scar Face "the world is yours"

Good luck, friend and always, fight like hell.

PS: *One condition the wife gave me when I quit was I have to keep a daily work journal. It's very helpful. My recommendation for you is to keep a journal--you will read back on this as perhaps the most enlightening self reflection. You don't have to write all thoughts, just what you did that day and the tasks will tell you what you were thinking.

<comment><USER3> With a wife like that how can you possibly fail! Good luck.

<comment><USER2> Thank you for the kind words. I will try my best and will update again on my project in a month or so :)

</comment></comment></comment><comment><USER4> It seems to me you need to figure out how to actually make/do something rather than keep calling it a dream. From what you've described, I don't really see something you can do based on what you've said. If you're going to start a company, it has to be based around something more actionable than simply a dream about how things should be. Figure out how you think you can get there and where you/your company fit in that process.

<comment><AUTHOR> I fully agree that I need to figure out how to make it actionable. I feel that there is an problem of education with regards to data-driven customer acquisition.

The first step is to start informing companies of the benefits that data analytics can bring, and how they're going to get tromped when companies that _are_ doing deep analytics come into their market-space. Especially foreign companies that have been doing it for years, and make it their number one priority. _cough cough_ Zynga _cough cough_

I think that is a perfectly actionable goal, but it involves mostly consulting. Consulting is something that I know I will need to do, but it's not something that can be sustainable forever.

</comment></comment><comment><USER5> What you need:

-a vision (MUST)

-a community of like-minded people who you can work with and be inspired with (MUST). You need people like these to figure out how to achieve your vision.

From where I stand, you best bet seems to be to offer a product that incorporates what you are trying to do and charge huge amounts of money from it (huge amounts of money because corporations don't trust anything that is cheap)

<comment><AUTHOR> Thanks for the solid advice.

I'm confident in my vision (and that is one of the reasons I'm leaving my current job -- their lack of a vision and a dearth of leadership).

The like-minded people... I have maybe 4 or 5 amazingly talented people in my community, a mix of ex-pats and Japanese who are just as fed up with the malaise of the current generation of Japanese as I am.

Bringing a product to the table is something that I know is going to be key to bringing Japan into a data-centric mindset for Saas. However, there are so many wonderful solutions currently available in the west, that I feel that reinventing the wheel will simply drain time away from my consulting evangelism.

Especially at first, I think that bringing a pre-made solution wrapped in a consulting service is a better use of my resources than re-creating mixpanel and crazy-egg for the Japanese market.

Thanks again for the great advice. You've really given me a lot to think about.

<comment><USER5> Excellent! Good luck!

</comment></comment></comment><comment><USER6> Hey man I live in Gifu and often go to Nagoya. Email me if you want to meet for coffee. (There is no contact info in your profile). I don't know if I can help but i am in a similar position.

</comment><comment><USER7> Sounds like you should start your own incubator or consulting firm on how you think things should be down. Do you have any money to help a few good startups?

<comment><AUTHOR> Nope. ;)

I'm a middle of the road Japanese salary-man, so I really don't have the means to start funding startups, especially when I don't know if I'll be able to feed myself and my family next month. ;)

I did get the offer of seed money from one of my current customers to start my own company, but I really don't feel that I'm at the point in my life where I want to be responsible for employees.

</comment></comment><comment><USER8> Freelance to keep the money flowing, while nurturing and slowly funding your goal (not only a dream) is the way to go.</comment>


When TDD Fails - <AUTHOR> http://bitroar.posterous.com/when-tdd-fails <comment><USER3> I got as far as: _Oh, and good luck mocking your database and HTTP request objects._ and just stopped. If you don't have any experience with TDD, then don't write about it. Mocking HTTP request objects is incredibly trivial and tools are written in every language to do just that.

I don't know why these articles keep getting written. No one's forcing you to write your tests first, and if you can't wrap your head around the benefits (which the author clearly can't) then don't do it. It's fine. I'll still continue to utilize TDD, and continue to pump out significantly more code (with significantly less bugs) than the code I produced without TDD. Yes, there's definitely code I write where I don't write the tests first. It happens, sometimes it's just easier to bang something out because you aren't sure what you're building. That doesn't mean TDD is a failure, it's a tool, like anything else. Use it where it's appropriate, because the benefits are massive.

<comment><USER4> You should have continued. His point is that while TDD is good for some things it misses huge areas and has very little ROI in most simplistic cases.

Yes, you can mock HTTP requests, but there are numerous bugs you wouldn't catch unless you went and hit your application with an actual browser. Similarly, you can mock the database, but you're not testing all the "magic" the database does and all the myriad combinations it could fail.

<comment><USER3> I have no intention of ever mocking the database, and I mock HTTP requests solely so I can work on my app without an internet connection. Look, a better approach is to use TDD for things it makes sense for. Spending a ton of time to mock out your database does nothing for you. Is mysql going to fail for you? Is the mysql driver that a million people are using going to fail for you? No? So, don't mock it out.

<comment><USER5> You don't mock the drivers.. you abstract the database layer to test for a particular data. For instance, you make getName() returns empty string, 1000 wide character string, strings with unicode, etc. It's not about MySQL; it's about what mysql returns.

<comment><USER3> That's done via fixtures, not mocking your database, and is significantly more trivial than HTTP request mocking.

<comment><USER4> Here's a trivial example:

Let's say you have a class that writes a string to the database. You abstract out the actual writing to the database of this string thinking it's always going to work, it's just dumping data after all. Your test passes, everything is good.

Now you optimize your database and add a restriction to make the string at most 50 characters. Your test still passes, but you now have a bug. OK, so you should've had a restriction in your BO. You add that restriction and move on.

Your DBA comes along and adds an integrity check or a trigger that makes the insertion fail if some weird condition is met. Your test passes, but you have a bug.

This can get even more interesting when you hit some basic database rule that you didn't even know it existed. You assume the insertion will work, but it won't. You now have a bug.

You've tested that 2 + 2 = 4, and it works, but when that code is linked with the actual database you realize that in some cases 2 + 2 doesn't equal 4.

I'm not saying don't have unit tests, but when it comes to bugs, the fast majority of these bugs, in my experience, come from the glue, from the assumption that the piece you're integrating with should work one way, but reality begs to differ.

<comment><USER6> Well this _could_ be solved with integration or acceptance tests.

Anyhow, TDD doesn't promise you bug free code.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I'm currently building a test framework for my graphics engine, and have run into the exact problems described in this post. A graphics engine, by design, must be able to do millions of different things that are created by the interaction between relatively few methods, none of which can go wrong at any time. One of my new features is probably buggy, but attempting to brute force test border conditions requires tens of thousands of tests because of all the interacting elements, any two of which could interact in just the wrong way to blow something up. It gets even more ridiculous when you have precision bugs, where only certain numbers in certain ranges in certain cases will explode. Testing that using inputs is impossible.

This occurs so often and with such regularity I am now convinced that everything I write is riddled with bugs that I will probably never find without beta-testing in real-world scenarios, plus many more bugs I will simply never find because they never come up.

A much better design would be a test platform that analyzes the assembly structure to pinpoint actual edge cases in the code itself, which could then be used as a guide for finding bugs instead of relying on hundreds of thousands of test cases.

<comment><AUTHOR> Depending on the language you're using, there might be some tools to help you.

For example, MS recently released a library for Design by Contract (aka Contract Programming) in .NET 4.0. It allows you to specify constraints on your methods, such as things you expect to be true before the method is called, after, and between _all_ method calls in a class. The library is capable of static verification, but it's partly an experimental feature and you need to pay for expensive version of VS. (Runtime checking is available for free.)

But, here is the cool part: MS also released an automatic test generator called PEX. It can do exactly what you've described - go into your code and automatically find edge cases, and generate tests that cover each of them. And it's free.

So, you can write contracts, run PEX, and if something goes wrong, you will see which inputs generated exceptions.

D also has DbC functionality. I don't think it runs any static verification on it yet, but you can use it to detect abnormalities during functional testing.

<comment><USER8> Genuine question: doesn't such thing as "design by contract" make for the same bloat as checked exceptions in java?

<comment><AUTHOR> DbC doesn't need to be dealt with at every level of the call chain if that's what you mean.

It may seem a bit verbose, but it usually expresses logic that would be in your program or in your tests anyway. Difference is, you will be doing it in a pretty terse and declarative manner. IMO, DbC is one of the coolest features of .NET 4.0.

</comment></comment></comment></comment><comment><USER9> While testing code is important (and I have tried to do better at writing proper tests for my code), the reason that I have not adopted TDD is because when I write a test and it fails, about half the time it's an actual bug in the code, and half the time it's a bug in the test. I view testing as more akin to going back and checking your work after solving a math problem - <USER2> as the definition of what your code is supposed to do, but as a verification that you did it right (and that it continues to work right in the future).

<comment><USER10> > when I write a test and it fails, about half the time it's an actual bug in > the code, and half the time it's a bug in the test.

Well yeah... You'd expect otherwise?

Do you mean when the test fails that it's some sort of not-bug like you changed your mind about what the method should do since writing the test?

</comment></comment><comment><USER11> I generally agree with the final sentence: "If you choose a methodology without comparing it against alternatives, if you claim that it works all the time without evaluating the results, than you're not doing engineering - you're practicing a religion."

I've definitely seen some negative effects when a team is forced to create a huge volume of low-level tests because they perceive that to be the only acceptable solution. They get bored with the work, and worse, think less about the larger integration issues.

I'm not arguing that TDD fails, but you'd better monitor the efficacy of whatever testing regimen you employ lest you suffer process and quality rot.

P.S. Dude needs to make friends with a spell checker... wow.

</comment><comment><USER12> IMHO, good testing is _hard_. I think that something that's probably as hard as writing programs in the first place shouldn't be commoditized into a methodology. I don't particularly dislike TDD, but I certainly don't like it either.

The best phase to write tests is when you've _locked down_ a part of your program. A part such as one distinct submodule or function or the _sort.c_ or _nodegraph.c_ of your latest project--a part that is relatively orthogonal to the rest of your code. That sort of ensures that the basic blocks, once finished, won't fail surprisingly. However, this can only be applied to basic building blocks.

Testing the bigger parts of your non-trivial medium-size program is likely to be so hard and complex that you have no chance at planning testing beforehand. I think that a good programmer or tester can come up with a relatively comprehensive testing suite that triggers execution paths up to 80-90% code coverage if given a sufficiently finished program, i.e. the program structure has mostly stabilized. Good programmer can also make changes to the same program without decreasing the quality of code. Bad programmers are as able to write good testing as modifying the code itself without letting entropy to the driver's seat.

<comment><USER13> _IMHO, good testing is hard. I think that something that's probably as hard as writing programs in the first place shouldn't be commoditized into a methodology. I don't particularly dislike TDD, but I certainly don't like it either._

Completely agree.

 _The best phase to write tests is when you've locked down a part of your program._

Completely disagree.

<comment><USER14> To elaborate, writing tests can very quickly make you aware of shortcomings or clumsy aspects of your APIs, since it should be the first time they're actually used.

</comment></comment></comment><comment><USER15> The author argues that TTD fails in code that's largely wiring. I think the opposite is true. I'm writing an application that's largely wiring, and for the first time in a long time, using TDD. It's refreshing.

Most of my tests are two-liners, like:

        it "should do x when y" do
            obj_under_test.should_receive(:consequence_method).with(some_args)
            obj_under_test.do_something
        end

There are a number of reasons why this has helped:

1\. It ensures I'm using dependency injection, etc to write testable, well- factored code. There's huge correlation between testability and maintainability. 2\. I don't have to boot the thing all the time to confirm that I didn't mess up in some obvious way. Covering the code paths prevents typos. 3\. My test suite runs in under three seconds. I can sanity check what I'm doing, without being tempted to browse HN/reddit/twitter/etc.

I like TDD _more_ in wiring-only code. If I'm writing wiring, I know what my test case will look like ahead of time, and I'll write it first. If I'm writing experimental algorithms, I have no idea what will happen, and I'd rather write code and poke it.

<comment><USER16> I know I'm pulling out raganwald's argument from one of his posts, but I'm honestly curious: is there anything other than anecdotal evidence that "there's huge correlation between testability and maintainability"? In particular, here we're talking about _unit_ testability. I don't agree or disagree—I've done both TDD and not, but I'm still not sure I've created more maintainable code when testing than when not.

<comment><USER5> Maintainability is not just about you changing your code later on; it's about someone else trying to understand what you were thinking when you write it.. and then change it. Tests make that process way easier. You can add your new feature _without wasting time to understand everything else_ and still make sure it's working. If it's your own project, meh, you know your stuff. You even know all the hack you did to gain time. I see tests as a documentation that shows me what's working. Reading tests (high level ones) is usually the first thing I do when starting on a new project. Comments change over time.. documents aren't updated.. people leave.. but tests remain. If the test passes, it doesn't mean everything is perfect, but at least you know that _these_ things work.

<comment><AUTHOR> Please note that the grandparent post specifically asks about unit testing and unit testability, while you speak in much broader terms.

Automated regression tests can be created in may ways, including UI-level tests that don't require any changes in coding practices at all.

</comment></comment></comment></comment><comment><USER17> I've actually come to this conclusion on several of my Rails projects. After struggling with mocking up yet another set of I/O objects I realized that it's not really doing anything useful. I agree that there should be testing, its just that TDD on MVC is very difficult to do properly. :/

</comment><comment><USER18> The real "problems" with TDD are

(a) in the "driven" part, not the "test" part. Tests are (in general) a good thing. However, using a series of tests to _drive your design_ (aka "TDD is not a testing method,it is a design method" idea) often gives you an illusion of progress as you hill climb using conformance to an increasing number of tests as a progress heuristic and end up on top of a local maximum (as for example in the TDD sudoku episode).

(b)in conflating TDD with one or more of (1) testing, (2) automated testing (3) automated regression test suites (4) developers adding more tests to the automated regression test suite as they develop more features, refactor, debug etc.

You can have (1) to (4) without either (5)writing tests _first_ (aka "don't write a line of code without having written a test covering it") or (6)driving your design with tests. The last two ideas are the real distinguishing features of TDD and are of debatable merit. None of (1) through (4) are novel ideas. (5) and (6) are where differences of opinion happen.

Even if you choose to use TDD, it is good to be aware it is just _one_ tool in your toolbox and not necessarily the default tool to reach for.

(c) in the zealotry of some of its evangelists who insist that TDD is some kind of moral imperative and is the only "correct" way of developing software and anyone who doesn't follow that path or make respectful obeisance to it is "unprofessional","dodgy" etc. This is often accompanied by conflating TDD with more generic notions like "automated tests" etc as above.

For example, Rich Hickey, the author of Clojure, said recently at the Strange Loop conference "We say, "I can make a change because I have tests." Who does that? Who drives their car around banging into the guard rails!?"

(and that is _all_ he said. One sentence in a keynote presentation)

For this Hickey was taken to task by a TDD advocate, Brian Marick, for not being "respectful" enough to TDD and for his "tone" in daring to mildly criticize it as a development practice. After some tweets complaining about Rich Hickey's tone driving away people from Clojure etc he wrote

<http://www.exampler.com/blog/2011/09/29/my-clojure-problem>

"The dodgy attitudes come from the Clojure core, especially Rich Hickey himself, I'm sad to say."

This kind of repeated whining and harassment over a few days made the normally unflappable Hickey (who asked for references to his "disrespect" etc, to the sound of crickets) lose his temper and say (on his twitter stream)

"If people get offended when their tools/methods are criticized as being inadequate for certain purposes, they need to relax.",

and "Testing is not a strawman. It's an activity, it has benefits, but is not a panacea. No 'community' should be threatened by that fact"

and later "Accusing people who merely disagree with you of being snarky, intolerant, dismissive etc is both wrong and destructive."

and much later after being subjected to a barrage of tweets criticizing his tone and 'lack of respect' for TDD, "If launching an ad hominem attack is the product of a lot of thought, it _is_ time for you to move on. Good riddance."

postscript: the best criticism of TDD I've seen is at [http://www.dalkescientific.com/writings/diary/archive/2009/1...](http://www.dalkescientific.com/writings/diary/archive/2009/12/29/problems_with_tdd.html) . The responses at [http://dalkescientific.blogspot.com/2009/12/problems-with- td...](http://dalkescientific.blogspot.com/2009/12/problems-with-tdd.html) are (mildly) interesting as well.

<comment><USER19> This comment should not be [dead] (if you don't want to give/dock me karma for irahul's comment, down-/upvote my reply to this comment):

irahul 7 hours ago | link [dead]

> For example, Rich Hickey, the author of Clojure, said recently at the > Strange Loop conference "We say, "I can make a change because I have tests." > Who does that? Who drives their car around banging into the guard rails!?"

Rich has spoken about it other time with an interview with Fogus:

<http://www.codequarterly.com/2011/rich-hickey/>

Hickey: I never spoke out 'against' TDD. What I have said is, life is short and there are only a finite number of hours in a day. So, we have to make choices about how we spend our time. If we spend it writing tests, that is time we are not spending doing something else. Each of us needs to assess how best to spend our time in order to maximize our results, both in quantity and quality. If people think that spending fifty percent of their time writing tests maximizes their results—okay for them. I'm sure that's not true for me—I'd rather spend that time thinking about my problem. I'm certain that, for me, this produces better solutions, with fewer defects, than any other use of my time. A bad design with a complete test suite is still a bad design.

He said something on the similar lines about development on CLR:

Fogus: Clojure was once in parallel development on both the JVM and the CLR, why did you eventually decide to focus in on the former? Hickey: I got tired of doing everything twice, and wanted instead to do twice as much.

His explanation on both fronts boil down to he doesn't find it(TDD and CLR/JVM parallel development) a worthy investment of time, given there are only so many hours in a day.

I don't understand why TDD advocates get all worked up when someone says TDD doesn't work from them. Well, if TDD is silver bullet of software development, they should be delighted that the ignorant singletons fail to see it and they have an edge over the fools.

These reactions remind of this:

"You are never dedicated to something you have complete confidence in. (No one is fanatically shouting that the sun is going to rise tomorrow. They know it's going to rise tomorrow.) When people are fanatically dedicated to political or religious faiths or any other kinds of dogmas or goals, it's always because these dogmas or goals are in doubt." ― Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance: An Inquiry Into Values

<comment><USER20> It looks like irahul was hell banned yesterday for the following comment, that's why his comments show up as dead:

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

</comment></comment></comment><comment><USER21> No one at my work place, including me, understand unit testing or TDD. I was recently asked to add a test suite to a service I wrote that is basically a simple wrapper that returns the result of a stored procedure call. The only test I could think of was to call it with all null parameters, in which case there should be no output. Other than that, the results depend on the state of the database. I'm familiar with the concept of dependency injection, but I couldn't add it to this very simple service in good conscience, since I knew that adding the necessary complexity would only increase the likelihood of a defect.

<comment><USER22> As shadowfiend notes, fixtures are a common approach here.

However, you could also use a mock. What you're _really_ testing here isn't the connection to the database or even that the database contains certain data, so you can rule that out of the equation. What you're testing is that some service (let's just say a 'method' for simplicity's sake) turns an input into an output in some particular way.

What you do, then, is mock the database connection for a particular test case so it returns a guaranteed result to whatever's doing the request in your method. You can then test that the method converts that input into the correct result. You've now unit tested the method rather than the entire service (in a nutshell - it can be more complex than that).

<comment> j-kidd I don't get it. Why would one mock the database connection when the thing to be tested here is a stored procedure?

<comment><USER22> It's hard to tell without asking the OP for specifics, but..

"I was recently asked to add a test suite to a service I wrote that is basically a simple wrapper that returns the result of a stored procedure call."

I interpreted this as meaning that the unit test would be for the 'service' and whatever it does with the stored procedure's result (and the arguments passed in the first place) rather than on the stored procedure itself. The reason for this interpretation was how he considered passing null values in order to exact a null response to be an acceptable test. Such a 'wrapper' might be a presenter system or simply convert data from the result to a different form, these things could be unit tested by mocking what the database returns.

If, however, he meant that the operation of the _stored procedure_ was to be tested, then my previous post was moot.

<comment><USER21> That's a great question. It wasn't specified to me either, so I don't even know. But even verifying that the stored procedure actually gets called is problematic. In practice, one of the problems that actually occurred with the service is that the service host somehow lost permission to exec the stored procedure. That's a server admin issue.

In my experience it feels like that case is pretty representative of most system defects, in that the majority of them seem to fall outside the space of defects that are feasible to test. I've always assumed I'm doing something wrong, given how many supporters unit testing has.

</comment></comment></comment></comment></comment><comment><USER6> The author is complaining that when requirements change that his tests need to be updated/rewritten.

Is he joking? I mean if the updated requirement changes the behavior of the code then the test better freaking fail and require the test to be updated, otherwise the test (if it even exists) is terrible.

</comment><comment><USER23> I very rarely use TDD, but I am a fan of it. First off, absolutes like "always write tests" are for people that are bad at programming but are still employed as programmers and can't be fired. They haven't developed the judgement for when to write a test or when not to, so in the interest of getting some reasonably useful test suite, you say "you must write a test for everything".

Secondly, I don't really agree that these action methods are untestable. Sure, "print hello world" is untestable, because it's so simple that you're not going to fuck it up, and because there's only one execution path that can possibly occur. But most methods are not like this; they need to reject invalid data or state, they need to craft database queries, and so on. In that case, you very well _can_ write good tests for this sort of thing.

Say I have some code that needs to accept an HTTP request that has a "foo" parameter:

        def do_something(self, context, foo=None):
            if foo is None:
                raise context.UserError( 400, 'You must supply foo.' )

            context.get_model('Something').apply_foo_to( user=context.current_user(), foo=foo)
            return context.get_view('Something').render()

This is easy and valuable to test:

        container = DependencyInjectionThingie()
        context = container.get_fake_context( current_user='jrockway' )
        controller = container.get_fake_controller( DoSomethingController )
        something  = container.get_fake_model( Something )

        # ensure that empty foo is rejected
        raises_ok( lambda: controller.do_something( context ), UserError )

        # ensure that something is mutated correctly
        controller.do_something( context, foo='OH HAI' )
        compare( something.applied_foo, '==', ('jrockway', 'OH HAI' )

(Who would have predicted the day where I started writing my HN examples in Python!)

In just a few lines of code, we get a little bit of extra security around our do_something action. We are sure that a UserError is thrown when foo is not provided (which our imaginary framework turns into a friendly error message for the person at the other end of the HTTP connection), and we're sure that the model is mutated correctly when foo is valid. In three lines of code.

I find that people that have the hardest time writing tests have poorly- architected applications that don't lend themselves to easy testing. The key point to remember is: if you don't pass something to an instance's constructor or to a method, don't touch it. Then everything is easy to test, because you can isolate your function (or class) from the rest of the application, and then test only what that function is supposed to do. (In this case, the fact that a UserError exception becomes an error screen is something you test in your framework's tests. Same goes for the fact that view.render() renders a web page; test that in your view tests.)

This style of development is also good for more than just testing. A few months ago, I wrote an application that monitored a network service. Not wanting to rewrite the service or mock it, I pointed my tests against a dev instance of this service. Everything was great until the service blew up on a Friday night and nobody was around to fix it. Faced with not being able to write any more code until Monday morning, I knew I had to fake that service somehow. 20 minutes later, I had a class with the same API as my "connect to that service" class. I changed one line of code in my dependency injection container (to create an instance of my connection-to-fake-in-memory-server instead of connection-to-networked-dev-server), and then I was back in business. That's the beauty of writing code to be flexible: you don't have to get everything right on the first day.

(People will argue that tests should never depend on external services, because they can blow up and then you're fucked. Yes they can, and yes you are! But while I didn't do everything right on the first day, my design allowed me to recover from this mistake without any code changes. And now I just run the test suite twice before a release; once against the fake connection and once against the real server, just to make sure that whatever assumptions I made in the mock server also hold when connected to a real server. I like releasing code that I know works in real life in addition to my fantasy mock world, but that's just me, I guess.)

Edit: and oh yeah, it's easy to mock databases and HTTP requests. We've seen the second one already; you let your framework translate between HTTP and method calls, and you write the tests for that when you write your framework. This frees up your application developers to Not Care about that sort of thing, allowing them to write great tests with minimal effort. The first one is also easy. You write code like:

        class UserModel(Model):
           def __init__(self, database_schema): ...
           def last_login(self, user):
               self.database_schema.get_resultset('User', user=user).related('LoginTime').order_by('time DESC').get_column('time').first()

Then when you're testing your controller, you pass in a fake UserModel that just defines last_login as something like:

        class FakeUserModel(Model):
            def __init__(self, database_schema): pass # don't care
            @memoize
            def last_login(self, user): return datetime.now()

The code to ensure that last_login generates the right sequence of operations on your ORM is somewhere else. The test that your ORM generates the right SQL AST is somewhere else. And the test that tests that ASTs are converted to correct SQLite SQL is somewhere else. You already wrote and tested that code. Assume it works!!!

Yes, sometimes you will write a few end-to-end tests to ensure that when an HTTP request that looks like foo arrives on the socket, you write a HTTP response that looks like bar to that socket and your database's baz table now contains a record for gorch. But that's not how you test every single tiny thing your application does; it takes too long, it's hard to get right, and it buys you nearly nothing.

So I guess I add: testing is hard if you write your tests wrong.

<comment><USER24> > I find that people that have the hardest time writing tests have poorly- > architected applications that don't lend themselves to easy testing.

It's generally good to start with some framework which provides capabilities to easily mock most of the objects. You sure can architecture your application as such, and have your dependency_injection_thingie to mock objects, but I don't think it's a worthy investment of time.

> (Who would have predicted the day where I started writing my HN examples in > Python!)

So why is that? Working on a Python application? While you are there, check out decorators and co-routines/generators. You already have checked out decorators(which are basically function composition - same in Perl other than the syntactical sugar) - I see your @memoize example.

Decorators along with Python introspection are super cool. I used decorators to implement a small contract system - <https://github.com/thoughtnirvana/augment>

I recommend this talk on co-routines <http://www.dabeaz.com/coroutines/>

EDIT: Perl has coro. But the language integration(generator expressions, convenient yield) makes it a bit more natural in Python(YMMV). And Python has gevent if you are looking for a threading equivalent.

</comment></comment><comment><USER25> Unit testing is not the only form of testing.

<comment><USER16> Which, of course, is part of the point of the article ("I'm not saying TDD is a bad thing, but there are more tests than unit tests, and there are more ways to verify software than testing.")

<comment><USER22> I think there's some confusion in the definitions which makes things a bit muddier.

TDD is traditionally based around unit tests, but nowadays can pragmatically include integration and functional testing practices. The former definition seems to be the one accepted by the article, but the latter definition somewhat solves most of the problems raised.

<comment><USER16> That's absolutely true. Are there any good articles/posts out there on doing test-first with something bigger like integration tests?

<comment><USER22> I don't have any mindblowing articles to hand but this might be a start: [http://programmers.stackexchange.com/questions/99735/tdd- is-...](http://programmers.stackexchange.com/questions/99735/tdd-is-it-just- about-unit-tests)

More specifically, the London school of TDD encourages thinking about things from an integration testing level, although you quickly progress to doing unit testing with a ton'o'mocks to flesh out the missing parts.

</comment></comment></comment></comment></comment><comment><USER26> I don't know, it's not that hard.

Write acceptance tests (with Cucumber or something), use a good unit test helper like Shoulda for your standard unit tests, and write unit tests for any complicated methods.

The acceptance tests will cover pretty much everything, and the unit tests will cover anything that's hard to test from a high-level point of view.

</comment><comment><USER27> This is a difficult topic. I've found that adhering to TDD is just not realistic in some cases.

For example, I'm following the Steve Blank approach of Customer Discovery, building my MVP. If I take the TDD approach (which takes more time to code a finished piece of functionality), and successfully iterate enough times during the Customer Discovery process, I throw out all of the tests that I built and am now moving onto something different that I've discovered a customer is actually willing to pay for.

</comment><comment><USER28> IMHO, there're two points here; 1\. Unit testing is not TDD 2\. TDD has nothing to do with software testing

TDD is good for developing rapid changing codebases with short development cycles with known requirements and a harsh time pressure, but it's a front loaded way as well.

By which I mean, you have to invest some hours beforehand to make sure you're not shipping crap because you didn't have time to see what would break or to make sure you didn't skipped the controller your GUI developer needed.

TDD tries to ensure one thing only: "Awareness". You accept the initial costs of TDD if awareness is a big issue for you. Otherwise, use something else which serves you to solve it.

If you're aware of what you will be implementing and if there's a mechanism you can check your code against, it'd be efficient, right? TDD uses unit tests for documenting that "Awareness", aiming to utilize the benefits of unit testing as well.

You're right, that it is not feasible trying to test every aspect of your solution via unit tests and that's why there are integration tests, systems tests and acceptance tests. So if you're planning to find defects via the unit tests you're writing for your TDD cycle, think again. Unit tests are good for checking "completeness" and a great tool helping with regressions. Nothing more and nothing less.

As a good engineering practice, we adopt the method of working, based on how we planned to work. If we find TDD fruitful to implement, we avoid putting any logic to controllers. We implement our business logic behind the controller, which also cleans it off of implementation specific crap. Besides us using a completely detached GUI layer helps us write controller unit tests running via HTTP.

We simplified our working environment and make it suitable for TDD, by ways we found to provide more capabilities to us. If we're not to use TDD, we employ other logics and structures, which would fit well with the method we'd use instead.

Long story short, TDD gives what TDD is intended for and as long as you cooperate. If you expect more than it can provide, you'd be disappointed. Regardless of your development method, you have to make sure your development/architecture models and your tool set complies with your method of choice. The rest relies in the question "What do you need your development model to solve for you?"

All the best

</comment><comment><USER29> "TDD is nearly useless when your code is the opposite of what I've described above: specific and mostly trivial, with complexity coming from the sheer amount of methods and their interactions. "

In other words, badly factored code is hard to test and maintain. Its just that with TDD its more obvious why badly factored code is bad.

<comment><USER30> More like wiring or integration code. Not everything is a framework. At some point you have to write code that works with and inside of the framework.

</comment></comment><comment><USER31> Using TDD everywhere is stupid. I think, tests are most useful between layers of abstraction, especially if you are the provider of abstraction. If you are merely a user of abstraction, it is stupid to unit test that code.

If you have an interface to the outside, then that should be unit tested.

</comment><comment><USER32> To the dev's who take the time to write tests, when I inherit your code base I feel like buying you a beer!

For the dev's who don't - no matter how 'clean' the code. FFFFUUUUUU

</comment><comment><USER33>
      > Okay, maybe I'm going abit overboard with fake qotes.

In other words, a straw man?

<comment><USER34> Why am I not surprised that there are a bunch of typos in this article?

<comment><USER35> No tests?

</comment></comment></comment><comment><USER36> This blog and some of the comments below are just crap. If you haven't TDDed before (for a non trivial project) you simply don't know what you are talking about, and it's apparent in your ignorant opinions.

Sorry if that's a bit harsh but I'm tired of seeing these posts by people who don't get it.

I don't get quantum physics, that doesn't mean I'm going to write an blog "when quantum physics fails"

If you don't understand something... Learn about it, practice it, then criticize its actual flaws.

Don't just get frustrated at something and claim its crap. Because its clear to those of us that do understand it, that you are talking crap</comment>


C++ for C programmers, part 1/2 (the non-OO features) - <AUTHOR> http://blog.brush.co.nz/2010/05/cpp-1/

<comment><USER2> Things that C programmers need to know about C++:

\- malloc() is broken. You need to cast the result.

\- Casting is broken. Even though C-style casting is available, you can't use it to reliably cast a void * as an object even when you know the type.

\- Pointers are broken. C++ introduces "references", a kind of non-nullable pointer which doesn't look like a pointer, makes a syntactic mess of what & means, and is used inconsistently wherever one could simply always use a pointer.

\- Exporting functions is broken. C++ functions can't be reliably exported as public APIs, unless you are absolutely sure your OS and compiler will never be updated. You must use #ifdefs to wrap the functions in 'extern "C"' declarations to have a stable plain-C API.

<comment><USER3> As a person who's worked with C programmers trying to be C++ programmers a couple times, the following gave me a hearty laugh:

> Pointers are broken. C++ introduces "references", a kind of non-nullable > pointer which doesn't look like a pointer, makes a syntactic mess of what & > means, and is used inconsistently wherever one could simply always use a > pointer.

I've heard argued "But but, its a Amp, it shouldn't mean that!"

</comment></comment><comment><USER4> The C++ STL's map (the associative array) is idiosyncratic in one important respect: while most associative arrays, like Perl and Ruby hash tables, C# dictionaries, and Java HashMaps are hash tables with O(1) performance, the C++ map is in fact sorted by key, yielding O(log n) performance. Unless you need your keys sorted for whatever reason I wouldn't recommend the STL map.</comment>


Wakari (in-browser analytics) out of beta - <AUTHOR> http://continuum.io/press/wakari-1-0-release

<comment><USER2> I work on wakari.io and I'm happy to answer any questions people might have. We are proud of this release.</comment>


Chamillionaire speaking about music and gamification. Surprisingly good - <AUTHOR> http://fora.tv/2012/06/21/Music_and_Gamification_Chamillionaires_Sweet_Success

<comment><USER2> That was quite insightful - thanks!</comment>


Lesson from OMGPOP shut-down: Don't get acquired by Zynga? - <AUTHOR> http://gingerbunnyme.wordpress.com/2013/06/05/lesson-from-omgpop-shut-down-dont-get-acquired-by-zynga/ <comment><USER2> While I think most people here agree that Zynga is a shitty and creatively bankrupt company for these and other reasons, OMGPOP actually got an amazing deal.

$180 million is more than 99.9999% of startups ever make. That's a good thing.

Hopefully the founders of OMGPOP got rewarded nicely and have the opportunity to work on whatever they want now.

</comment><comment><USER3> They probably have a lot more money to do OMGPOP2 now. Like how Google bought Dodgeball just to have the founder leave and create Foursquare.</comment>


Google To Shut Down Orkut September 30 - <AUTHOR> http://en.blog.orkut.com/

<comment><USER2> HAHAHAHHAHA I remember how cool people were during Orkut times. My name would have been J()#|\| $t3\/3

</comment><comment><USER3> Ragequitting the world cup has never been so stylish.</comment>