Why Perl Didn't Win - <AUTHOR> http://outspeaking.com/words-of-technology/why-perl-didnt-win.html <comment><USER2> I was a Perl scripter (I never rose to the level of JAPH) from around 1998 to 2002, with my final accomplishment being a two-way HRIS synchronization system between our installation of peoplesoft and our LDAP server (Netscape LDAP server, awesome product).

And then I met Python, and I never wrote another line of Perl, and have written some python code almost every week since then.

There were two _personal_ reasons why I left Perl.

First - I would write some code, it would do what I wanted, but then I would come back in a week (or even a few days) and have no idea _how_ it worked. This is code that _I_ wrote. Yes, I know this is a personal failing (I said these were _personal_ reasons) - but, on the flipside, I've never had anything I've written in Python that I didn't completely understand how it worked any time in the future. Perl just let me write code that was too complex for my brain to comprehend. I blame implicit variables. [edit - and perhaps an over reliance on regex.]

Second, If I hadn't used them for a month or so, I used to struggle with Arrays of Hashes and Hashes of Arrays. Once I eyeballed my template, it all came back, but the syntax imposed enough cognitive overhead that I struggled with that data structure (which is one that you use a lot).

On the flip side - the very _first_ day I was learning Python, I thought to myself, "What if I just drop an array (list) as an object in this hash (dict), or a dict in this list? Will this work?

And it did. Close to zero cognitive overhead.

So, that's why I left Perl - Readability and complexity of what should be bog simple data structures.

<comment><USER3> A consideration to you:

You spent 4 years of learning Perl, 4 years in which you likely also massively improved your skills as a programmer, regardless of the Perl angle. Then you went to Python, bringing in your programmer experience, probably started off with a good book and had a much happier time.

So, do challenge yourself and ponder how much of that come from having spent 4 years programming, and how much from actual differences in the languages?

<comment><USER2> It's an interesting perspective, but, seriously - for the life of me, I struggled every time I wanted to declare/parse/initialize an AoH or HoA on perl. And I'm not engaging in hyperbole when I said that my code was basically completely foreign to me a week after writing it.

Obviously developers (which I am not), and people with more discipline and structure, and write eminently readable and maintainable perl code - but as my day job was network engineering, I was just looking for the lowest cost path to get the job done.

I really did love CPAN though.

<comment><USER4> That's interesting, because defining an AoH or HoA in Perl is almost identical to how you would do it in Javascript, which is to say it looks a lot like JSON.

If it was the access and assignment semantics, the normal case is also fairly straightforward; use curly braces for hash/dict keys, square brackets for array indices.

E.g.

        my %data =  (
            foo => [
                { bar => 10, baz => 12 },
                { bar => 20, baz => 13 },
                { bar => 30, baz => 14 },
            ],
        );
        print $data{foo}[2]{bar}; # 30
        push $data{foo}, { bar => 40, baz => 15 };

Given, using array and hash references with the built-in push,pop,shift,unshift,keys,values and each used to require some annoying dereferencing that could be confusing.

Do you still find that confusing?

<comment><USER2> I'll admit to not having looked at it for about 12 years, and, of course, I'm not saying I couldn't figure out after 2-3 minutes over looking over the pattern, but it just never flowed the way it did with Python for me.

       data ={}
       data['foo']= [
          {'bar':10,'baz':12},
          {'bar':20,'baz':13},
          {'bar':30,'baz':14}
       ]
       print data['foo'][2]['bar']
       data['foo'].append({'bar':40,'baz':15})

       for x in data['foo']:
          print x['bar']

Maybe it had something to do with indices always being [] brackets and {} only being used to define the dict structure. Or maybe it got easier sometime in the last 12 years? Or, maybe you could onto something, and having come pre- primed with knowledge hashes/arrays, I just picked up python more quickly.

Anyways, it was just a personal story told as well as I could remember it.

</comment></comment></comment></comment></comment><comment><USER5> Maintenance. I say this as somebody who loves Perl, quirks and all (actually because of the quirks). It's actually a beautiful language to work in in the same way English is a beautiful language -- it's a beauty because it's a goddamn mess. But it's a rotten language to maintain.

Sure, it's perfectly possible to write highly maintainable code (I have a few 30-40k line Perl projects that I can open up and get right to work on without too much fuss) and you can create some coding standards and stick to them, and write perfectly maintainable code. But Perl is a bit like C++ in the sense that everybody has different standards and those standards change and "non- standard" bits of the language start leaking into your code and you spend as much time unmessing things as you do writing code.

I don't think Perl will ever really die, it's too convenient, but it's definitely never going to enjoy the dominance it once had. It'll fall back to a very good one-off system admin and log processing language with some extra bits, but it's simply a language that the rest of the world has surpassed and Perl 6 just isn't a realistic offering, after a _very_ loooong wait (nor does it fix the issues non-Perlers have with the language -- it's basically fan service).

<comment><USER6> I don't want the popularity we once had.

The same people who wrote unreadable, unmaintainable perl went on to do the same sort of damage in PHP, then python, then ruby/rails, and now node.js/go. They were never a net positive to the community, and I'm not sorry to see them causing problems for somebody else.

(and before somebody says "but that doesn't happen in X" ... yes, it does, even python lets you write code that looks superficially comprehensible but turns out to be so horribly illogical structurally that it's impossible to maintain - I quite like python but I've been there and I was kinda scared because at least wrong perl looks wrong to start with, whereas wrong python looks fine until you realise just how much of a crawling horror it is)

<comment><USER7> With python is not the same. Even if the developers is truly bad and do a mess, is a _decipherable_ mess. Requiere truly talent to do a hard-to- understand mess in python, and in that case, is very likely the code was made by a good developer ;)

<comment><USER8> > Requiere truly talent to do a hard-to-understand mess in python, and in that > case, is very likely the code was made by a good developer ;)

Last I checked, the whole "if it was hard for me to write, it should be hard for others to understand" was still a mockery, not a seriously-interpreted excuse. It ignores the fact that the programmer's future self will eventually need to maintain that code. The developer might have skill, but one who writes unmaintainable messes as anything other than a Perl-golf-style mental exercise probably lacks wisdom. :)

</comment></comment></comment></comment><comment><USER9> Articles which critique Perl as a whole by focusing on Perl 6 always strike me as a bit strange. As someone who works professionally with Perl every day, and starts several new projects using Moose-centric modern Perl techniques every year, the amount of time I or any of my colleagues spend thinking about Perl 6 is negligible.

The modern Perl movement, as far as I can tell, arose in part from Perl hackers who started to treat the wandering Perl 6 project — rife with neat ideas, if not with release engineering — as a skunkworks for Perl 5 extensions. In the gap between the middle-aughts and 2014 that this writer waves away with "is anyone still paying attention?" due to no Perl 6 release, the active Perl world adopted Moose, and many Perl-based Moose-driven technologies — Catalyst, DBIC, and so on.

These technologies, and the communities around them, have thrived on their own ever since. Nowadays when I think about Perl 6, it is often because I am at a Perl conference and Larry Wall is literally at the podium talking about it and I am like "Well. You go, Larry Wall."

Perl really has reinvented itself in the last handful of years, at least in the eyes of those who make a living inventing new things with it. I can't call this writer wrong — their perspective is their own. I suppose I can only learn to appreciate the notion that, to hackerly folks who aren't as ensconced within the modern Perl community as I, the language is this thing from the 1990s that kicked the bucket through one bad decision in the summer of 2000, leaving behind acres of legacy code that's still being scraped away.

To be fair: this indeed describes a lot of what I am hired to do. It's just that I replace it all with newer and better Perl…

</comment><comment><USER10> Perl is sort of like trying to read someone else's brain (in this case Larry Wall's). You get themes and kind of the gist of where it's going, but it never quite adds up to some sort of coherent whole.

The defense has always been that Perl is designed more like natural language than programming language, ok, but: natural languages are a LOT harder to learn than programming languages. Put me in a room with Haskell and I'll learn it in a month. Give me a month of training in french and I'll maybe be able to not make an entire ass of myself if I try to get from point A to point B. Human languages are hard. Design wise -- I'm not sure that's what you want to aim for.

Almost everything you learn is... surprising. Like flattening lists. Useful in a context, maybe, but is that the kind of thing anyone would ever expect? And why is "list" (@) part of the variable name in the first place? It's like "dynamically typed, kind of, except your variable name has to say if it's one thing or many things or many things referenced with keys". What the fuck? I'd rather the python way of "it's a name that points to a thing, whatever that thing is". GOT IT. Simple.

I program in C++ for a living, probably the biggest clusterF of a language ever devised (outside of perl), and the thought of reading Perl still terrifies me.

<comment><USER11> > Put me in a room with Haskell and I'll learn it in a month. Give me a month > of training in french and I'll maybe be able to not make an entire ass of > myself if I try to get from point A to point B. Human languages are hard.

To be fair, I don't think this is actually because human languages are all that hard to become competent (note: not fluent) in. It's just that with computer languages you have an endlessly patient practice partner to work with. In particular, I think the complexity of competent Haskell is definitely higher than most spoken languages.

</comment></comment><comment><USER12> The same things could be argued as for why, why C didn't win, or C++ didn't win, or even really PASCAL/Smalltalk/Lisp didn't win. "Winning" is temporary and not the end goal of any language and is best left to be declared by Charlie Sheen like pundits trying to demonstrate their language bigotry.

Is Perl the first tool that some of us think of when solving a problem? It might not be for you but it is frequently for me. Ruby might be your first choice, and really that's fine.

You're not a lesser or better programmer than anyone else if you choose something besides Perl either. Honestly, if you can solve the problems that you need to solve and you can work with your team, that's the only thing that matters. Not that you're using some language that isn't "winning".

As for Perl not having support for recent things like Stripe, that's just silly to argue (the author really should have searched the CPAN). Perl has many new modules, Dancer, Catalyst, Moose, Plack, Starman, Net::Stripe (maintained by me), and full support of AWS's offerings. And, yes modules written in 1999 do get used today, just look at all of LWP.

"Winning" isn't everything. Admittedly, Perl 6 isn't out or even moving forward visibly but doesn't mean that the language is irrelevant. Just watch [https://metacpan.org/recent](https://metacpan.org/recent) to see the pulse of the community and the new modules released and updated daily.

<comment><USER13> If this article had been written about natural languages, it might be called "Why French didn't win". It may not be the world's most popular language, but it's extremely useful to a lot of people.

Winning isn't everything. :)

</comment></comment><comment><USER14> > You need large absolute numbers of users to grow a library. That's why > library ecosystems like that of Python, Ruby, and Node.js have grown large > in recent years.

Thats where the author missed an important point. None of those library archives have the culture of PAUSE+CPAN to constrain a minimal code quality when it comes to configuration, documentation, regression test and installation. This minimal code quality is constrained by CPAN testers, when a module hits PAUSE, before the module is seen by the unwashed masses who access CPAN.

I've seen many library archives of other languages, but they are all full of junk, undocumented junk, untested junk, and junk that does not configure or install everywhere. The worst example was the LuaRocks system. The quality of the libraries in the Rocks archive had been so bad, that the church decided to remove the module keyword from Lua language, to get rid of this junk. But the code I see for Ruby/Rails, NPM/Node, or PyPy/Python is junk compared to even those Perl modules, that barely managed to convince CPAN testers.

You not only need the absolute numbers, but important you need a core group starting the ecosystem who constrain a coding culture. Raw numbers are not enough. A million apes wont write a Shakespeare novel.

<comment><USER15> I have been so very burned by CPAN module quality in the past. Claims to CPAN 'minimal code quality' ring hollow with me. Apache's collection of Java code is MUCH higher quality on average.

</comment></comment><comment><USER16> I suspect that all the languages that are "winning" right now will have "lost" 10-20 years from now too.

What's the longest lived language out there right now that's actually still in heavy use? I'd say C. But C has clearly fallen from its position of complete dominance when _every_ new project was written in C (because it was much easier than writing assembly).

C++ had its day as well and lives on in many places, but again, it's no longer the go to language for projects where C isn't the right choice.

How about Java? It was hot stuff in the 90s and it's still huge today, but it clearly didn't "win".

PHP? We'll be living with legacy PHP code bases for at least 10-20 years but does anyone honestly think this will be the language that the startups of 2025 use?

Programming is both incredibly faddish and incredibly fast paced. Today's new hotness is tomorrow's "dead" language.

Give it 5-10 years and I expect to read "Why Python Didn't Win". I expect we'll see a "Why Ruby Didn't Win" in 10-15 years too.

<comment><USER17> So maybe winning is more like winning for a time period. PERL did win. It won up until early 2000s, then lost. I am guessing it is not getting picked much for new, greenfield projects. I think that is a cut-off metric. One way get there is to find a niche. Maybe it isn't the new use-for-everything language. But at least can become the "ok, use for this one area" language.

C -- still winning in that respect. It is used in many places just because of hardware or time constraints -- drivers, micro-controllers, optimized fast parses, low level socket handling code. It just got specialized. Not used probably for business or back-end systems.

I don't think PERL can claim that same. It seems to me its role has been replaced by Python, maybe Ruby, Java (for web server back-ends).

C++ still winning. None of the current languages including the new contenders like Rust and Go can eat its lunch (as they say) when it comes to performance. Things like games or signal processing. Anything requiring low latency responses will still see C++ being picked. And with C++11 and C++14 it is getting a new breath of fresh air. Whoever is going to contend with, will have a steep hill to climb.

Java? Java still winning. Now if you think of Java as JVM it is winning even more. Java itself if just a very average language that is also fairly performant, explicit, IDE friendly. If you had a lot of money and could hire potentially lots of average or below average programmers to throw at a problem (which I think often is the wrong approach, but if you did), Java is your language. And Android. Don't forget Android. If anything it is winning just because of that.

> Give it 5-10 years and I expect to read "Why Python Didn't Win". I expect > we'll see a "Why Ruby Didn't Win" in 10-15 years too.

I think it replaced PERL by in large and but now it is feeling the heat in a lot of areas where it was being used. Scientific community has Julia as a new kid. Server back-ends have Go and Javascript. Not one big threat but little paper cuts here and there.

Ruby, I am not familiar with it much, from my outside perspective it looks like a one-trick-pony = Rails. If something replaces or obsoletes Rails, I don't see Ruby rising and finding a niche. I could be wrong, so anyone please correct me here.

<comment><USER18> I think the definition of 'winning' people use around here is, if start ups think its a trendy technology to use. So you will see all these new companies stop using a particular language, and then when some conference happens you will see talks around the older technologies have dried out, while people are giving talks on the newer set of technologies.

Its then when you see articles/rants/blog posts on the lines 'Whatever happened to X which was famous $current_years - 5 years back?'

Please note all the focus is around the new technology. Some one is writing a new library around this new DB technology some one is using and is writing about it. Some one just gave a talk on how some scalability problem was solved by a specific feature in the language. Some one just talked about how testing got easier, some one writes about how maintenance efforts got reduced because of a new way in which language deals with type declarations, Or some programming forum is full of questions and the Google auto suggests can tell you your question as you are typing it.

Meanwhile some where in a MegaCorp, your maven can't see beyond the company in house repo. And using a different library takes 3 months of permission cycles. People sitting in there don't get interview calls and hear about people saying that the old technology isn't hip any more.

Only thing that is buying Java some time is the large quantities of enterprise code, which no one has the money to replace.

<comment><USER19> Can you fix the bug in "$current_years - 5 years back", please - it's bothering me. If you're going to talk in code, at least get it right ;-)

<comment><USER19> Oh, come on downvoter - I put a ";-)" at the end of that. There's literally zero tolerance for anything lighthearted here, isn't there?

</comment></comment></comment></comment></comment><comment><USER20> I gave up on perl when I saw the following code:

$x = $src[$src];

I was confused as hell until I realized that arrays and scalars had different namespaces. That, along with the fact that "or" and || had different precedences were what ended Perl for me. I'm not saying that wonderful code can't be written by Perl, it just wasn't the right language for me in that I hate memorizing one-off rules, which Perl seemed to have plenty of, instead of a language that was more internally consistent.

<comment><USER6> If you only want a single namespace for everything, I recommend sticking to only scheme (note: I really love scheme for that property, I'm not being sarcastic).

Once you learn -enough- perl, there's a sort of overall consistency that's actually really nice, but there's a gap ... simple perl is very simple, but mid-level perl is generally a mess until you get to the expert level, and then its awesome again.

There's probably an analogy to text editors here.

<comment><USER21> I couldn't agree more, and that's why I hate perl.

That gap in the middle makes it really hard to hire perl developers unless they are experts. It's hard to find experts because they think perl code is a mess before they get there.

It's probably the main failing of perl.

</comment></comment></comment><comment><USER22> Perl lost because PHP took its place on the web development front.

Perl lost because Python/Ruby took its place on admin front.

Perl lost because the new version took forever to get ready and broke compatibility with the old code.

<comment><USER23> 1\. True

2\. Linux Admin? maybe. UNIX admin? I'd say Perl still on, as it's installed by default (yeah not popular anymore, but a LOT of legacy system still run)

3\. cannot comment, as never used new Perl, since UNIX still shipped with old- ish Perl

maybe, just maybe it's not just winning & losing :D every language will find it's place eventually.

<comment><USER24> On 2: Still 193 unique files in /usr/bin on my system containing the string '/usr/bin/perl'. Only 51 containing '/usr/bin/python'.

<comment><USER21> are you saying python is more efficient? :P

</comment></comment></comment></comment><comment><USER25> I have two programming tattoos: a Perl camel and a Ruby ruby. That basically tells the story of why Perl didn't win for me: As soon as I started learning Ruby, I thought, "Oh, a cleaned-up Perl" and never really wrote any Perl code again.

I love Perl's personality, its quirkiness, and its massive amount of libraries. Perl was _massively_ influential on me as a young programmer. But I'm pretty sure that I won't be writing any Perl ever again.

<comment><USER26> Exactly. Perl 6 was forever delayed, and along came Ruby. Or rather, out from the shadows came Ruby, which was already there before the Perl 6 debacle, and just needed promotion. The Pragmatic Programmer books were pretty good at pointing to this cool replacement for Perl that you never knew was already there (as well as all the buzz from the RoR folks for those of us who weren't in on the beginning)

I don't really think that the people who left perl all went to PHP.

Now if only there was a "Ruby lite" that ran more like Perl 5 (skipping the GC for reference counting and a few other performance shortcuts)

<comment><USER27> I'm wondering if Swift will fill that role, eventually.

<comment><USER26> I hope so. That is, I hope there is a version of Swift outside of Apple-land (Clang compiler for LLVM extension???). What little bit I have seen so far looks promising, and it has a significant sponsor to get the language going.

</comment></comment></comment></comment><comment><USER18> I got introduced to Perl in 2006, at a time when trolls were screaming 'Perl is dead' from top of the buildings. Perl was revolutionary to some one like me who had only done C and assembly language programming. And it turned to be a great tool for the job back then(Processing massive unstructured text files). Its still unbeatable in that area.

Back then I saw that people who worked around enterprise projects that used some kind of a relational database used a lot of Java. People who were jumping to the Web 2.0 Bandwagon, used stuff like Python and Ruby largely because of the frameworks. Thereby what's really apparent is tools that are best suited for the job get traction.

Perl is still unmatched for many things. Unixy things like dealing with large quantities of text. Gluing things together, getting stuff done quickly etc etc.

Perl's every day use cases were going way, as database and web heavy things ruled the business scenarios. Perl largely occupied a niche and ruled it. So is Python today(Web frameworks), and ruby. Also Perl reached a very high peak in the 90's. And reaching that kind of level again isn't possible unless Perl does some very new and paradigm changing.

Perl 6 is kind off believed will do that eventually some day. But from what I last heard a few day back in this very forum, there are not close to anything serious even in another 2 years from now.

</comment><comment><USER28> Articles like this make me sad. Perl is a mature, well supported language with a thriving community. It is not in maintenance mode, a new version has come out every year for the last 4 or five years, all with new features, many more planned. Plus the perl conference attendance has been up every year for the last few years. [http://www.yapcna.org](http://www.yapcna.org)

You say I should use something more modern? Are not all languages based off of methodologies from 1950?

And which one of these modern languages do I choose? Rust, Go, Python, Ruby, Java, JavaScript, node.js, coffee, dart, swift, C#, F#, Scala...

Probably many more that I missed but my head already spins. If anyone says they know more than 2 of those languages, then they only know them poorly.

I get tired of some new language coming out every year, along with a new community of trolls to bash everything and tell me I need to drop everything I already know to learn their new mess.

I must say, none of these languages that are in the news impress me. Yet there are many perl modules that do impress me.

I enjoy perl and its community. I like that it is not coupled with any huge corporate sponsorship. It is the bazaar in "The Cathedral and the Bazaar" and that I like.

</comment><comment><USER29> The final section, which I was anticipating for the whole article, was essentially this:

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

What killed Perl? An imaginary Perl did.

<comment><USER13> >> What Killed Perl?

The article is entitled "Why Perl Didn't Win", not "Why Perl is Dead". Perl hasn't been killed.

<comment><USER15> It's dead to me.

</comment></comment></comment><comment><USER30> I think there's some good points in this article - and I relate to it, 'cause this is _exactly_ how I learned Perl.

The one other item that I'll add is that some of the characteristics that make Perl awesome for sysadmins, like extremely flexible syntax and the ability to freely access data sturctures in a variety of contexts, can make it more difficult to build proper software development projects.

Maybe it's just my limited experience, but it seems like Perl organizations spend a lot more time on mandating coding styles and debating best practices compared with more structured languages like Ruby or Python.

<comment><USER31> But as was mentioned in another comment, what you mention as a key appeal for sysadmins is _exactly_ why I can't stand perl. In particular "extremely flexible syntax" makes taking over the sysadmin job from another person, or joining a team, a ridiculous amount of effort. I can't begin to tally the number of hours I've spent with perl code open in one window, and a web browser open to various different perl guides, the documentation, etc. trying to figure out what tricks some script is using that makes it completely incomprehensible to me.

Is it fun? Sometimes, except never when a key service is down and you have users breathing down your neck. Or your website is down. Or really, trying to do any kind of maintenance work. And guess what happens? More crazy patches, probably written in an entirely different style! So now there are $n+1$ different styles in that script, and my successor is going to be even more frustrated with me than I am with my predecessors.

On the flip side, it's been a great education on the difference between maintaining code for your own use and code in an organization...

</comment></comment><comment><USER32> _How does a language win? By being compelling enough to be used for new things. It 's not solely a technical concern; it's a concern of the language community and ecosystem._

One of the most valuable 4 sentence paragraphs I've read from an HN post in awhile. (Perhaps 3, but the semicolon really separates 2 sentences.)

<comment><USER33> The semicolon separates two independent clauses, but they constitute a single sentence.

When we're thinking about language, clauses are probably a better atomic unit than sentences; clauses are a semantic unit, and sentences are really just a syntactic packaging format for some number of clauses. Just like we should be counting expressions (or something) rather than lines of code.

<comment><USER32> I'll take that comment as a parody?

<comment><USER33> Sure, whatever you like.

<comment><USER32> Well played!

</comment></comment></comment></comment></comment><comment><USER34> As a Perl and Modern/PBP fan, I have to suggest that CPAN has become a poorer resource over time:

> _In the olden days, you could expect to find a Perl module for most anything > you wanted to do_

but also:

 _Having 57 modules all called Sort will not make life easy for anyone (though having 23 called Sort::Quick is only marginally better_

and it seems that every time I look for a useful module on CPAN I find myself in a _twisty little maze of packages, all different._

TIMTOWTDI, yes, but which one (or several) of the available modules will have a usable combination of convenient utility and mutual compatibility? Over time, CPAN has started to feel like the house of someone who rescues animals, but cannot let go of any of them.

<comment><USER35> There are a few things to consider when trying to pick a good/the best module for a problem.

\- ask in irc.perl.org. it is very likely to get pointers from very experienced people.

\- use metacpan.org and pay attention to the votes/likes it got. and read the reviews.

\- each and every CPAN module is automatically tested. look at the stats to weed out problematic modules.

\- check out the release frequency and when the last release occurred.

\- read the Changes file

\- take a look at the tests for the module, is it well tested? are there alot of tests?

If you are past a certain point in your life as a Perl programmer this comes very natural and does not take alot of time.

<comment><USER36> I agree, but naive new Perl users might benefit from some prominent showcasing of well-known good modules or maybe comparison charts between modules in the same functional niche... Maybe that is a subject better left to Perl bloggers rather than to the neutral CPAN, but first contact with Perl is sometimes an embarrassment of riches.

Anyway, I love the CPAN - whatever I imagine myself wanting to do, five people have done it already !

<comment><USER37> Well, MetaCPAN has a leaderboard of modules, but it could be a bit more prominent: [https://metacpan.org/favorite/leaderboard](https://metacpan.org/favorite/leaderboard)

</comment></comment></comment></comment><comment><USER38> I recently spent 4.5 years at a big bank developing identity-management tools. They were written in Perl. The first thing I did was screw up in production: [http://www.schmonz.com/2014/06/01/tdd-in- context-1-keeping-m...](http://www.schmonz.com/2014/06/01/tdd-in- context-1-keeping-my-job)

So I started carefully making the code testable, then gradually adding tests and refactoring under them, and gradually adopting and taking advantage of Moose, shipping every month all the while. There was never a second screwup.

(Will big banks keep choosing Perl for new projects? Yes, for a long time. It's firmly entrenched. It didn't win, but it'll probably never lose either.)

Would I choose Perl for a new project? That depends. For programmers with taste, discernment, and discipline, Perl-the-language + Perl-the-CPAN can be incredibly and sustainably productive. For other programmers, it's enough rope to quickly cut off bloodflow to your foot, which you can then use Perl to amputate.

In other words, Perl is at the high end of the risk/reward curve. If I could mitigate the risk -- say, by convincing myself that I'll always be in a position to hire great programmers or nobody -- then I'd absolutely want the reward of developing a new system in Perl.

</comment><comment><USER39> I think the article is a little bit harsh on Perl. Ruby (1995) and Python (1993) wouldn't probably exist without Perl (1987). Hence IMHO it's just a sort of evolution, nothing more. The other two languages _learned_ from Perl's mistakes and were _better designed_.

</comment><comment><USER40> At the end of the article, he/she says "the Swift programming language has been public for less than a week and already has more users than Perl 6, and _Swift is entirely built on technologies which have been invented since the Perl 6 announcement_ ".

That's simply false; anyone who's been in the programming languages field for a while knows that...

<comment><USER41> I interpreted that as 'Perl 6 dates back to 2000, while LLVM (upon which Swift is built) dates back to slightly later in the year in 2000.' (although, to be fair, the LLVM website first appeared in 2002.)

</comment></comment><comment><USER42> I always check on indeed.com to confirm the popularity of things. It looks like Python just broke past Perl on absolute job posting numbers.

[http://www.indeed.com/jobtrends?q=+perl+developer%2Cpython+d...](http://www.indeed.com/jobtrends?q=+perl+developer%2Cpython+developer&l=)

</comment><comment><USER43> The domain outspeaking.com is owned by chromatic's company.

Afaict chromatic was the first to promote the article with a tweet shortly after it was published and shortly before it appeared here on HN and reddit.

When someone noted this connection on reddit and said they thought chromatic wrote it his response was "I'm not the only person with access to the server. Anonymous wrote that article."

[http://www.reddit.com/r/perl/comments/27o6h5/why_perl_didnt_...](http://www.reddit.com/r/perl/comments/27o6h5/why_perl_didnt_win/ci32gof)

Even if it's not chromatic (I think it is), is it not obvious that the OP article is designed to garner inbound links/views (and sell books) rather than provide a balanced picture? Consider the juxtaposition of the deceitful title and well written content. Do you see what the author did there?

<comment><USER4> My understanding is that chromatic is not the only person at that company that knows Perl, not that has had experience with Perl 6 and/or Parrot. I think it's appropriate to judge the article on it's merits and how well it covers the issue, not the specific views of people that may be associated with it.

Truth be told, I was thinking while reading it that it sounded quite a bit like chromatic but with tones down criticism, and said as much to a friend I fowarded it to. I wrote this "Sounds a lot like chromatic when he was disillusioned, but not yet bitter. Which is to say harsh, but definitely constructive." That it's from the company he's involved in doesn't surprise me. If he wrote it and wants to keep it as aonymous, I think that's perfectly acceptable. If someone else there wrote it, that wouldn't surprise me either; I doubt all of his thoughts and opinions happen in a vacuum.

</comment></comment><comment><USER44> if ain't php ,think will stick to perl.. first web base language learn..

<comment><USER44> why down vote,since it my first web base language in 2001. By that time,php is new and .net is version 1. When i got visual studio dvd,my pc run slow. So i moved to php and stick till now.

</comment></comment><comment><USER45> I never understand the apparent glee with which people perform premature post- mortems on Perl.

You never really see people declaring any other language moribund, and then kicking it a couple of times for fun.

I don't see the point?

</comment><comment><USER15> No language syntax causes me higher cognitive dissonance than perl. I just find it fugly.

</comment><comment><USER46> Another perspective: Perl lost because the culture of internet software development moved away from hackers who grokked humor and cleverness towards team-driven business application developers who preferred synergistic framework solutions.

</comment><comment><USER47> Whenever i read perl code, i feel somebody is cursing me through the source code

</comment><comment><USER48> Write once, read never.

<comment><USER26> Speak for yourself! (or maybe, for annoying coworkers???)

It's certainly possible to write functions (subs) with comments about what they do, and use meaningful variable names. The built-in syntax/operators do require some study, though.

For the "Enterprise!" developer pool, there's Java. The 500 line methods are still hard to slog through, though. Too many never got the note about a "business logic layer" and abstraction, and just shove all the details in- line. In which case, the language of mandate doesn't matter much.

<comment><USER49> > For the "Enterprise!" developer pool, there's Java. The 500 line methods are > still hard to slog through, though.

Great straw-man there. I didn't realise that javac required 500 line methods before compilation.

> In which case, the language of mandate doesn't matter much.

It's a lot easier to pass two collections to a method in Java than to a sub in Perl.

<comment><USER26> \--- Java ---

List <Integer> aList = Arrays.asList( new int [] { 1, 3, 5 }); // probably missing some more type stuff in <>

Map <String, String> aMap = new HashMap <String, String> ();

aMap.put( "name", "Joe");

aMap.put( "ID", "42"); // I need to check if Java 8 has map literals a la Groovy...

doSomething( aList, aMap);

...

void doSomething( List <Integer> aList, Map <String, String> aMap) {

System.out.println( "First: " \+ aList.get( 0) + ", Name: " \+ aMap.get( "name") );

}

\--- Perl ---

&do_something( [ 1, 3, 5 ], { 'name' => 'Joe', 'ID' => '42 });

...

sub do_something {

my( $list_ref, $hash_ref) = @_;

printf "First: %d, Name: %s\n", ${ $list_ref }[ 0 ], ${ $hash_ref }{ 'name' };

}

\</comment></comment></comment></comment><comment>

I'm not seeing _that_ much of a difference in parameter passing, other than the explicit reference/dereference syntax.

Of course Java doesn't _require_ 500 line methods. But the bondage and discipline imposed is independent of whether or not readable code will be produced.

I actually _like_ strongly typed languages for larger programs, but prefer something more fast and loose for smaller ones. TMTOWTDI!

<comment><USER49> > List <Integer> aList = Arrays.asList( new int [] { 1, 3, 5 });

You can drop the inner array, asList takes variable number of arguments.

> // I need to check if Java 8 has map literals a la Groovy...

Sadly not, IIRC they've backed off from literals towards a Guava style static factory methods, which I'm not thrilled about.

> I'm not seeing that much of a difference in parameter passing, other than > the explicit reference/dereference syntax.

So let's say I'm a newbie Perl developer just exploring subs.

      sub stuff {
          my ($a, $b) = @_;
          print "$a and $b\n";
      }

      my $a = 1;
      my $b = 2;

      stuff($a, $b);

It works! Hurrah. Feeling clever, I move onto collections.

      sub stuff {
          my (@a, %b) = @_;
          print "$a[0] and $b{A}\n";
      }

      my @a = (1);
      my %b = (A => 2);

      stuff(@a, %b);

And it doesn't work at all. @a has some additional values, and %b is undef.

So yes, let's use references.

      sub stuff {
          my ($a, $b) = @_;
          print "${$a}[0] and ${$b}{A}\n";
      }

      my @a = (1);
      my %b = (A => 2);

      stuff(\@a, \%b);

Except now, I have two ways of working with Perl's collections, two separate sets of sigils, and all because I wanted to pass two collections into a function and Perl treats function arguments as a collection, and Perl implicitly flattens collections.

The difference _I_ see, as a Perl newbie only working with it out of necessity, is that having (because you need it because of earlier design choices) more than one way of operating on data structures, violates the principle of least surprise.

<comment><USER50> > Except now, I have two ways of working with Perl's collections, two separate > sets of sigils, and all because I wanted to pass two collections into a > function and Perl treats function arguments as a collection, and Perl > implicitly flattens collections.

It's not really two sets of sigils, it's two concepts: "collection", and "pointer to collection". I guess coming from C that didn't bother me too much—once it sunk that references were just (safe) pointers, using them works almost exactly the same:

        int a = 1, *b=&a, **c=&b, ***d=&c;
        printf("%d %d %d %d\n", a, *b, **c, ***d);

        my $a = 1; my $b=\$a; my $c=\$b; my $d=\$c;
        printf("%d %d %d %d\n", $a, $$b, $$$c, $$$$d);

Perl even stole C's pointer syntax to make working with collections nice:

        my $a = [1,2,3];
        printf("%d\n", $a->[0]);

<comment><USER49> > it's two concepts: "collection", and "pointer to collection". I guess coming > from C that didn't bother me too much

Fair point. I guess what bugs me is that you can use collections merrily without references until you want to pass more than one collection to a function - or create a collection that isn't flattened - at which point you have no choice.

</comment></comment></comment></comment><comment><USER51> In one of the WWDC sessions an Apple engineer was adamant one should never choose terseness over clarity, because every line of code is written once by one person, but read many times by many people.

And funny enough Objective-C is taking this quite seriously, being a very verbose language (the new Swift language also keep the verbose method names, enums and properties).

While Perl is exactly the opposite. There's a reason people jokingly call it a write-only language.

It has real implication on its usage. You use Perl for one-off scripts you intend to forget and maybe delete after you run them a few times.

While CPAN happened, I wonder how much Perl was an obstacle in multiple people joining to work on a single library (versus multiple people just downloading it and using it, big difference).

<comment><USER6> Most of the modern perl ecosystem is libraries built by substantial teams - it's a lot different now than a decade or so ago.

The Modern Perl dialect is basically what came out of the new wave of CPAN (Enlightened Perl) movement which is all about using perl's flexibility in a way that scales to larger teams.

Sadly, every attempt to explain this to people not already writing it results in a deluge of 'write-only' jokes and nobody bothering to actually look at the code, so while the technical capacity is there, the pop culture nature of programming language choice means people generally never realise.

<comment><USER51> Perl's brand is damaged. No amount of explaining fixes a broken brand.

The best that can probably be done is to create a new language which is, say, a clean subset of Perl 6 and call it something new, focusing the message on how readable and intuitive it is.

</comment></comment></comment><comment><USER52> There are so many snarky things to say, but my mother taught me to never speak ill of the dead.</comment>


Theranos Gets $100M in Funding in Dec. 2017 - <AUTHOR> https://liesandstartuppr.blogspot.com/2017/12/theranos-gets-100-million-funding-is-it.html <comment><USER2> It's a loan by a firm that invests in distressed assets contingent on meeting performance goals with the kicker to be able to buy 4% or equity. Sounds like a killer deal for the investors. They get something be it patents, interest payments. I think they're all but guaranteed to make out like bandits.</comment>


Google Inbox spoofing vulnerability - <AUTHOR> https://eligrey.com/blog/google-inbox-spoofing-vulnerability/ <comment><USER2> sure reads like google is looking to drop Inbox without wasting any more developer productivity on its maintenance</comment>


Over $700k selling a premium mobile game - <AUTHOR> https://www.reddit.com/r/startups/comments/4f74dv/quit_my_full_time_corporate_job_built_an_ios_game/ <comment><USER2> Despite getting very close to the best possible case for an iOS game (#1 on app store for a more than 0 days), am I the only one that is pretty dissapointed at how he was compensated? He didn't actually make $700k -- after Apple took theirs, and the gov't took theirs, he was left with ~$150K in his most successful year...

I guess the freedom to do nothing while your app just rakes in money is great, but it seems like the probability of hitting this case is very low, and a stable job (though he would have possibly not liked the monotony) would have made him much more money.

All this said, I'm about to strike out on my own with a one man LLC, so as others have said, this information is golden.

[EDIT] - Many have pointed out that I missed the ~$280K that he gave to his partner (the content creator) -- so in his most successful year, he stood to make (had he been truly solo) ~$430K, which actually is pretty substantial, for a one time effort... But what is the probability of someone's iPhone game getting to #1 on the app store?

<comment><USER3> He implies that this happened organically, without paid installs. And his price point is $.99 at the time of this writing. And he doesn't use IAP.

Those are choices he's made that drastically limit the upside he could earn. I respect the hell out of those choices, to be clear. But they are choices.

It's well understood that the way to _actually_ strike gold in mobile gaming these days is to get to a point where you're arbitraging paid installs. You've got IAP hooks up and running, you've got quasi-addictive mechanics dialed in, and your blended CAC is less than your LTV on converted installs. You spend a boatload on installs every week, which are recouped by the revenue you earn from your casuals and especially your whales. Now you're in the shitty IAP/P2W business, alongside everyone else. Now your game kinda sucks. But now you're minting money.

That's pretty much the BigPublisher playbook. Indies can run it, too, albeit only to a point, and with a lot of soul sacrifice.

All of that said and done, I am impressed and inspired by what the author has been able to accomplish organically. And, while his earnings may seem depressing from an outside perspective, they are respectable, and to be respected. If he wants to build a larger business from here, again, he'll have to make some Faustian choices as outlined above. Or he'll need to raise his price points and/or adopt a high/low versioning approach.

This is the way the world is going to work until Apple and Google decide to put the smackdown on paid installs. Which they won't, because their big publishers make them so much money, and their big publishers have optimized a formula reliant on paid installs and drowning out the small guy. (Theoretically, feature placements are supposed to counteract this phenomenon -- but, as the author points out, they accrue most readily to the big publishers, who can afford to invest millions in production values, and whose games are big enough to be itemized on the App Store's monthly earnings statements.)

<comment><USER4> > I respect the hell out of those choices

Why? What's noble about leaving money on the table?

<comment><USER3> I don't begrudge people who are in it for the art, or for the love of the game. Some of them are naive, sure. But plenty others make that choice intentionally. For reasons of game design, or reasons of personal ethics. And good for them.

I have several very close friends who graduated cum laude from fantastic schools and chose to become high school teachers instead of lawyers or bankers. Should I begrudge them that choice, as well?

</comment></comment></comment></comment><comment><USER5> Truly a great writeup - I don't think I've ever seen a breakdown in greater detail than this regarding someone's experience building an app.

For me personally, this was the most inspiring piece:

 _Publishers are not created equal. It 's something I learned very quickly when trying to understand the App Store feature mechanics. If you are Warner Brothers, SquareEnix, Kim Kardashian, King, etc, you get a red carpet to getting featured. You can release whatever trash or shoddy port you want, and you'll get featured. So you have two options, accept this and play by the rules I'm about to lay out, or don't participate._

<comment><USER6> Same goes for Apple's 30% take. You either pay it, or you don't ship an iOS app

<comment><USER7> Does anyone want to bet on how many years it will take for Apple App Store to attract antitrust attention from the government? Eventually they will get pressured on this fee.

<comment><USER6> I don't know. For one, iOS doesn't control the market. Recent stats show iOS at 13.9% share [0]. Second, Google (and presumably others) take the same 30% [1]. As a part time developer that recently dealt with this 30% issue, I hate the fact they require it, but I understand why. Distributing the apps to millions of phones isn't free.

0 - [http://www.idc.com/prodserv/smartphone-os-market- share.jsp](http://www.idc.com/prodserv/smartphone-os-market-share.jsp) 1 - [https://support.google.com/googleplay/android- developer/answ...](https://support.google.com/googleplay/android- developer/answer/112622?hl=en)

</comment></comment></comment></comment><comment><USER8> Extremely helpful post: insightful and inspiring. This author's comment also underlines the modern situation of the self employed:

"I'm a single person LLC with practically zero expenses (I paid a whopping $3k for my MacBook and made $700k), so Uncle Sam is going to get his money. I save a bit based on marginal tax rates, but pretty much I'm SOL because the tax system doesn't understand how a single guy can make so much."

<comment><USER9> He could have done an S Corp or something to keep more of the profits in the business and avoid paying personal income taxes on all of it, no? Depends on long term play I guess.

<comment><USER10> When you want to draw the profits as salary you'd be taxed on it anyway?

<comment><USER11> He can do things with it before giving himself a salary, things that can be taxed less.

<comment><USER10> Such as?

<comment><USER12> Pay people to create art / music / assets for his next game?

<comment><USER10> Are you not allowed to subcontract services and deduct as an expense as a sole trader?

<comment><USER12> I'm not at all an expert on this subject, but if you pay income taxes on your 2015 income, that's less money you have to spend on expenses in 2016. If it stayed in the corporation you might not take as big of a hit.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> only tangentially related, but I think it's screwed up that apple can take a 30% cut of absolutely all the money moving through the ios platform and not have an antitrust suite brought against them

if microsoft can get screwed by the FTC for bundling IE with windows, why can't apple get screwed for only allowing app store apps on their devices?

<comment><USER14> Apple, Google and Microsoft all charge 30%.

And before Apple came along, to get your app published (J2ME days), you had to get a publisher who would take 70 to 80%.

<comment><USER15> Another similarity is ThemeForest. In their example calculation, a non exclusive author gets $36 when selling an item for $100.

[http://themeforest.net/become-an-author](http://themeforest.net/become-an- author)

<comment><USER16> Even if you are an exclusive author - you are only getting 50% when you start, then it grows up to 70% once I reach 75k in sales. On top of that you HAVE to provide support for all your items which nobody pays for

</comment></comment></comment></comment><comment><USER17> Even the lucky few who get outsized returns find it unsustainable...

<comment><USER18> Exactly this. The writeup is excellent, but also shows exactly how hit-driven the app market is. The dev made one game (based on already-successful IP) that generated a lot of revenue, and then the subsequent games are only modestly successful.

I think one of the big "do's" from the article is very good advice: don't spend huge amounts of time working on an app and expect it to provide a return. The dev says 2 months of part-time work should be a target, and that seems about right to me as well. Beyond that you're just asking for negative returns if you value your time highly.

<comment><USER19> > _The dev made one game (based on already-successful IP) that generated a lot > of revenue, and then the subsequent games are only modestly successful._

And now is going write a book and probably go on to become an "expert" and do consultation on how to successfully repeat a process that they themselves couldn't repeat in practice.

The transparency and information in the post is awesome, but I don't see any systematic path to success here, in what is the crap-shoot of the App Store. One-hit-wonders are everywhere.

</comment></comment></comment><comment><USER20> For comparison, the most popular game creator makes over 10 million per day over 4 games, with over 4 billion in revenue per year. This creator is supercell, with Clash Royale, Clash of Clans, Boom Beach and Hay Day

Edit - They made 2.5 billion last year with nearly a billion in profit, so they may reach 10 million a day this year.

<comment><USER21> Comparison to the other side, the guy on the bottom end is lucky if he's making any amount and could very well be far into the red every month.

More interesting I think is to look at the average, where I very much doubt that the average developer makes anything more than a handful.

</comment></comment><comment><USER22> Really insightful post, thanks for sharing. It's been a while since I've seen this kind of success stories from indie developers. I feel like there's a trend right now that is focused more on telling how bad the App store is and how screwed you are if you're developing mobile apps/games.

</comment><comment><USER23> 45% tax?

In Poland I would pay 19% linear tax + $50/month for medical and social insurance in first 2 years, $160/month after 2 years. Nothing more.

<comment><USER24> daveguy below goes through why the 45% tax claim is bogus.

</comment></comment><comment><USER25> Congratulations on a very nice and innovative piece of work.

Articles like these are encouraging but skews the full picture.

For a game like this there are hundreds pieces of work with equal cost and complexity that get absolute no downloads in the app store.

</comment><comment><USER26> Wait, you need to ask Apple to have your app featured?

This is a really insightful post, but at the same time, I don't even want to bother with all the Do's and Don'ts. See, I don't develop games. I have a total niche app product and Apple does exactly zero things for me and still wants 30%. I even drive the people to the app store through my website. Exposure? No. Payment handling? Could do this myself. New users? Not really.

Luckily, my web app makes 10x more money than the stupid app.

<comment><USER27> > ... Apple does exactly zero things for me and still wants 30% ...

I'll bite. The Romans, err I mean Apple have done nothing, except at least these:

* Maintains a user database including authentication, plus all the support costs (lost password support is very high)

* Payment handling (you dismiss it, but no one does it for free) including keeping up with tax authorities and legal systems in much of the world

* Almost unlimited (re)downloads for users to a reasonable number of devices. Bandwidth is cheap but not free.

* Backup and restore for application data. (You may not use it, but that functionality is available to apps without extra fees.)

* A curated walled garden including a review process. I'm sure your app is fine, but Apple keeping the dregs out and avoiding the place turning into a cesspool means users can be more confident about the apps and that halo effect helps all apps in the store.

* Mechanisms to extend your app such as IAP, and an advertising solution etc

* Access to a large user base, with reasonably fair rules that everyone has play by

* They make all the above work together

The case can be made that the benefits used vary by app, but in aggregate it isn't an unreasonable amount for them to charge. It is worth noting that competitors haven't done anything substantially different.

<comment><USER26> Yes, you're right _generally speaking_. But I'm just pointing out that _for me_ (!) with a niche app(!) it doesn't work out and I need nothing of the stuff you mentioned. Payments? PayPal and Stripe are reasonably priced and compete with each other. This makes prices reasonable.

Maybe I can make my point more clear by saying what I expect from Apple: Let me publish an app and don't tell me how to run my business. I want to put up an app in store that uses external payments. Apple doesn't want this. Well, kind of, sort of. The App Store Guidelines section 11 are pretty clear on what Apple expects:

 _Don 't charge people outside of the App Store, because we want a share of that pie. And if you do, we ain't gonna like it. We might approve your app, we might not. We might change our mind, too. Depends on how explicit you're selling your stuff._

And for a long time, it was simply not possible to offer apps that are paid for outside the App Store. And now, it's still very vague. You have to offer an app that also works without requiring a paid account.

Anyways, thanks for the input. I take this discussion to reconsider my position and think of a way how I can make this work. I must admit that Apple changed the rules over the recent months a bit. It's maybe a bit more flexible now.

<comment><USER27> Their payment approach may seem to be a bit overreaching, but it does make sense. Remember they still provide all the services I listed for apps. If you provide your app for free then Apple makes nothing as well, while still providing those services. It isn't unreasonable to then say that if you make money, Apple gets some too.

It also isn't a bad idea from an incentives point of view. Apple make more money if their developers make more money. And the benefits accrue just over double to the developer than they do to Apple. Similarly developers being less successful also hurts Apple. At least the 30% cut means Apple have to keep earning it.

Remember that as a developer you can walk away, and support other platforms instead. You can avoid stores completely and do everything yourself. With rare exceptions, you are very unlikely to do as well.

<comment><USER26> > At least the 30% cut means Apple have to keep earning it.

I think this is exactly the point that gives me the bad feeling: If Apple really provided "the best service", people would _buy_ their services from them and the price would be dictated by demand and competition (ironically, just like the price of apps in the App Store, which tends to go down over time).

But this is not how it works. People aren't free to choose which services they want to buy from Apple and whether they want to buy from Apple at all (if they want to be in the iOS playground). Apple forces their services on everybody. There is only a single package: Take it or leave it.

> Remember that as a developer you can walk away, and support other platforms > instead.

Theoretically it's true, but ultimately, the customer decides. Although I put a lot of effort into a very nice mobile-first web design, which will hopefully render the app unnecessary in the long run. Together with the "always online" trend and increasingly better mobile internet connections, this might work out.

Thanks for your thoughts, I appreciate them. I don't want to sound as if I'm only arguing my position here. I'll think about the stuff you said.

<comment><USER27> Developers are not Apple's customers - the people who buy the devices are. Those people have freely chosen Apple and continue to do so.

There is another way to look at Apple's cut, even when you as a developer consider it unfair. For the end users it establishes a certain amount of credibility. Apple places certain hoops developers have to go through as well as taking some money. An end user is going to find a solution that can do all that far more credible than one that can't.

It is different now, but a few decades ago one of the functions of advertising was credibility. If a product was advertised, it meant there was an aura of success about it (the money to advertise has to come from somewhere and someone has to stand behind it) and that success was sufficiently great to spend some of the revenue on ads. The bigger the ad spend, the more credible/success there is perceived to be. Everyone will be a lot more skeptical about something that can't even afford to advertise, or does so "cheaply".

The same thing is happening with university education. Someone attending one, spending real money and persevering is more credible than someone taking a few online courses, even though the actual education they could get is similar.

Circling back to Apple, the app store is already saturated, and I suspect Apple will be more than happy to raise the bar some more. The most credible apps are what they and the users will want. Imagine they added a section for folks like you "these apps use none of our services and we take no cut from them". That section would smell like failure, not success.

<comment><USER26> That's a very interesting perspective. Haven't considered that before.

</comment></comment></comment></comment></comment></comment></comment><comment><USER28> The problem is the odds of such success are slim. There are too may apps, too many developers, not enough eyeballs. But good for him though, and very inspiring and informative.

I think easier money can be made with buying deep in the money call options on 3x versions of the S&P 500 and the bond market, which is what I and my dad have been doing for awhile with success. Don't need coding skills or luck to make money with the S& 500

<comment><USER29> this sounds interesting - can you provide some more details?

</comment></comment><comment><USER30> Thanks to the author for sharing this info. That said, the app's downloads peaked in 2014, which was a different App Store.

</comment><comment><USER31> All that tax...

<comment><USER32> Obscene, isn't it? He could have sent a kid to college for the amount of tax he paid.

<comment><USER33> Well, he paid for roads, schools, national defense, politicians... Taxes aren't just a black hole that go nowhere, you know.

<comment><USER34> That's the theory, in reality it goes to both. One part ges to roads/schools/etc and another part goes to a pile of corrupted politicians or unnecessary middlemen or completely useless endeavors.

The black hole in America is a pretty big one, is just that the taxes pie is big enough and there is enough for both the black hole and the good projects, but the pie is shrinking and people is starting to get angry and to make stupid decisions...

</comment></comment></comment></comment><comment><USER35> I am dumbfounded. This guy grossed 700Gs from a take on Cave ([https://en.wikipedia.org/wiki/Colossal_Cave_Adventure](https://en.wikipedia.org/wiki/Colossal_Cave_Adventure))?

</comment><comment><USER36> I make a Saas web application and I still got something from this. I'm going to commit some $$$ and buy some other Saas apps to see what they do right.

</comment><comment><USER37> Caveat: The game capitalizes on existing IP. He ported a well-liked browser game into iOS. The games he created himself are not doing as well.

<comment><USER38> According to this: [http://www.newyorker.com/tech/elements/a-dark-room-the- best-...](http://www.newyorker.com/tech/elements/a-dark-room-the-best-selling- game-that-no-one-can-explain)

He worked on this together with the original creator.

<comment><USER39> And split the revenue.

</comment></comment></comment><comment><USER40> Any idea why the OP chopped a clean 33% from gross income to account for income tax? This doesn't make any sense to me whatsoever.

<comment><USER41> I was about to post on this. Either he is misrepresenting his taxes to make for a good story or he had a terrible accountant that had him pay too much in taxes.

Contrary to popular (conservative) belief, when you go up to a higher tax bracket you are not taxed on your entire income at that rate. It is only the amount in that bracket that is taxed at the higher rate. His taxes should be $48,663 not $91,245. If he was already making above $183,250 from other income then, yes it would be taxed at that higher rate. Although you can't distinguish between the income that was taxed at a higher or lower rate, so it sounds like he is misrepresenting his tax burden either way.

He does mention for the second year that he is "still at 33%" because of other contract work, so it looks like he just wants to over represent the taxes of someone pulling in a certain amount from an app.

EDIT: Oh, later in the reddit thread he does mention he "saved a bit based on marginal tax rates". A bit, my ass. He paid about half the 33% he claimed -- $42,000 LESS than the $91,245 claimed based on that income. Saying the other income is the income on which he saved the marginal tax and that he had to pay a full 33% on the app income is just disingenuous.

<comment><USER42> Yeah, the original post should be edited to reflect actual tax paid.

</comment></comment></comment><comment><USER43> He has a pretty good playbook for ios games. Are there other playbooks out there?

Like "How to start a startup" by YC</comment>


I Can't Wait for NoSQL to Die - <AUTHOR> http://teddziuba.com/2010/03/i-cant-wait-for-nosql-to-die.html

<comment><USER2> _NoSQL will never die, but it will eventually get marginalized, like how Rails was marginalized by NoSQL._

Is it just me, or does this statement make absolutely no sense whatsoever?

<comment><USER3> I don't know if this is what he was trying to say, but it makes a little more sense if you change it to

 _NoSQL's hype will never die, but it will eventually get marginalized, like how Rails' hype was marginalized by NoSQL's hype._

</comment></comment><comment><USER4> AdWords implemented on top of MySQL? Perhaps the CRM portion of AdWords (i.e., where the advertisers submit their ads and publishers view their balances) is -- it's fairly easy to partition by functionality and doesn't have extremely tight latency bounds. This isn't where real time auctions (what really distinguishes AdWords from what came before) happen.

You can be _sure_ , however that the data used for real time ad auctions is extracted out of MySQL and into a _highly_ customized data store (likely, a pure in memory one). It's all about using a right tool for the job. You can also be sure that you'll never see a paper on that data store, as that's their competitive edge. If you could duplicate it with off the shelf components (whether MySQL _or_ Cassandra), Google would be toast.

Likewise, I am sure Amazon uses Oracle for their billing system and catalog submission interface, but they use specialized systems for search, shopping cart and recommendations.

For a business app that only needs to scale to the amount of _paying_ customers (i.e., advertisers, account managers and customer support) and has no real time constraints -- but on the other hand involves complex and frequently changing business logic (e.g., where altering tables may be required) an RDBMS is the right tool for the job.

Where latency matters, data grows much faster than Moore's law (in relational to main memory size), Amdahl's law starts to matter in regards to computation (computation work load needs to be partitioned to take advantage of parallelism), and traditional caching strategies simply don't work, something else is. That situation is starting to become more and more common across web companies. You can also be sure that places like Wallmart and the like employ plenty of non-relational technologies (my personal bet would be is that they're likely using Coherence or Terracotta): usually, however, they're expensive and are built/configured by field-engineers to be custom tailored for their workloads. When you employ a world-class engineering team, "build" starts to make more sense than buy when you're solving a very specific and constrained problem (e.g., fault tolerant shopping cart system).

You don't need to be of Google's size to be at that stage. Talking about scalability and performance without taking the workloads into account (e.g., "Google Facebook or Amazon" as if e-commerce, search and social networking were compatible) is also an anti-pattern: I am sure engineers at Google would laugh when you compare Facebook's scale to theirs; likewise Facebook's engineers would laugh when you compare the real time aggregation that happens on their site to what happens at Amazon; Amazon's engineers would likely tell you holiday season pager duty horror stories that would scare Facebook _or_ Google engineers.

<comment><USER5> > a highly customized data store (likely, a pure in memory one)

That's when we stop calling it a data _store_ , and start calling it a data _structure_. Data stores are where data goes when it's not part of the working set. With that definition, it's perfectly sensible for AdWords to use MySQL as its data store.

<comment><USER4> (Edit: this is a longer reply than I intended, no longer really intended as a direct reply to the parent; this is more a reflection on systems architecture of data-intensive applications).

That's a good point, but a pure in memory data structure is:

a) Not persistent to disk _at all_. Judging from my own experience with similar low-latency systems used in ad serving (where we called these "data servers") and other similar systems, the data is likely to be persisted to local disk and the deltas replayed to it from a MySQL db to avoid long restart times.

b) Lives within the ad server process. This is likely not true, as the ad server process will need to compose a "working set" for particular ad auctions from multiple data sources (bid price for each ad, keywords, budget/delivery/campaign specifications for each ad, keyword relevance of ad/ad campaign). Each of these data sources is likely represented by a different data structure (red-black tree for one, hash table for another, trie for yet another, graphs, B-Trees, etc...), has very different characteristics in terms of cache-locality, rate of change, size, density and comes from multiple places (some from RDBMS, others from Map/Reduce)

(Interesting side note: earlier I also wanted to say that neither the data structures are usually not partitioned in how they're store, now is computation done on them partitioned. However, with the age of parallel computing this is simply not true: there are now parallel data structures and algorithms).

One compromise is perhaps we can call these systems "data servers" or "data structure servers" (afaik Redis does the latter). MySQL (or any other RDBMS) merely _feeds_ these systems through some form of message oriented middleware. In this case RDBMS (and this is an over simplification which doesn't cover all the corner cases) is merely acting as tape: changes are played forward and not randomly accessed. RDBMS that is the source of truth for ad-serving is _never_ queried real time and can easily be taken down for maintenance while ad serving continues. It doesn't even need to be highly available (if advertisers can't submit ads it would certainly be a _huge_ and costly outage, but much less costly than if users see ads!).

Note, such a system is also necessarily eventually consistent (in the truest meaning of the word: customer receives an SLA which corresponds with a point where the serving component is consistent with the DBMS).

There still needs to be an efficient OLAP component to back the CRM/ERP functionality of this system, for which an RDBMS is still a good bet (combined with an off-line system e.g., Map/Reduce for more complex reporting and optimization). However, had an end-to-end ad-serving system been written from scratch _now_ , would the RDBMS component serve as primary source of truth (rather than _just_ as the backend for the publisher/advertiser/support UI component).

In addition, this ("write to RDBMS, serve from elsewhere") design is also very specific: writes to the "ad submission database" are rare and don't always require high availability. Consistency (between the RDBMS and serving component) can be _much more_ eventual than would be in a Dynamo based system (where the weak "can't read my writes" eventual consistency is only a failure condition).

Now suppose you _also_ want highly available, low-latency writes (even if not at the same frequency as reads) and you'd want to be able to read-your-writes in normal situations. This makes the "write to RDBMS, serve from something else" (effectively what popular memcache+MySQL deployments are) scenario more brittle. You now have much harder questions to answer (do I want a system that's always in a consistent state e.g., to avoid having to do quorum reads/writes? am I okay with eventual consistency as a failure scenario? etc...) but with many workloads this becomes a necessity.

Despite speaking at NoSQL events, I am not a big fan of the NoSQL name. Not only do these systems _not_ intend to completely displace SQL based RDBMS systems (and as with ad server example can exist side-by-side with them), additionally these systems provide functionality that _can't_ be provided by RDBMS systems (and _not_ just due to scalability concerns).

</comment></comment></comment><comment><USER6> There are a rash of these articles popping up. While there are usually valid points in urging people to avoid the hype of the "next big thing", a lot of these guys seem to be bitching that they might have to learn a new skill set.

I have been in this business long enough to remember Clipper and FoxPro devs bitching about SQL when it was on the rise. This sounds about the same to me.

<comment><USER7> These articles are just link-bait with no content. The 'NoSQL' buzzword is as distasteful to me as, say, 'cloud', but that doesn't mean that articles discussing them don't have value.

The flurry of 'NoSQL' articles often cover the different approaches to data stores, their implementation, their interfaces, their management, performance, scalability, etc. That interests me, but doesn't mean I'm going to go to work on Monday and kill all the non-NoSQL dbs we have running.

Hate-against-hype articles are waaaaay overrated.

</comment></comment><comment><USER8> Ted's point may be valid for BigTable-like databases. (I'm not saying it is, but I don't know enough about those to say so.) Those are designed for scalability and if you don't need the scalability you probably _should_ use a RDBMS instead.

But there are other advantages of SQL-less databases that don't deal with scale. I deployed my first MongoDB app a couple weeks ago. Even though it was a small (~1 developer month) project, and neither myself nor the other developer had used MongoDB before, I still think we finished faster than if we'd used MySQL. Just like Cassandra is a premature optimization if you just need an RDBMS, an RDBMS is a premature optimization if you only need an object store.

<comment><USER9> I got downvoted awfully last night for trying to say this, but I'll say it again to back you up:

Developing with mongodb is _lightning fast_ and holds up very very well. If you end up with problems, switch to SQL later!

I don't think a lot of these people hating on the nosql projects have actually tried building something with them.

<comment><USER10> Why is it faster?

<comment><USER8> It doesn't force you to fit non-tabular (eg. hierarchical) data into a table structure.

Also, no schema means the data structure is more malleable. With the right ORM, this fits in well nicely with polymorphism: I can store objects with some common features in the same collection, but when I retrieve them from the database I get different types of objects which inherit the same base object. mongoengine is one ORM that does this.

<comment><USER11> Nice. But I have a difficult time seeing how storing "malleable" data like that, opaque to the storage engine, is going to be performant for querying.

Must be nice to have requirements that never change once you've decided on a data representation...

<comment><USER8> The database is still aware of the fields, so MongoDB can build indices on certain fields if you wish. Admittedly I haven't deployed Mongo in an environment that really tested its performance, but we've been serving about 20k pageviews per day with no issues. Granted, this was a fairly basic application.

As for changing requirements, mongo handled those well too.

It's certainly not a silver bullet, but when I just need a basic object store the query performance trade-off is worth it.

</comment></comment></comment></comment></comment></comment><comment><USER12> It occurs to me that MySQL started off as a thin SQL wrapper on a NoSQL database: here, have a SELECT and WHERE, but you'd best not JOIN, and forget about transactions or referential integrity.

Then, over time, they tacked on a few more relational features, but they had yet to solve the hard problems of relational databases.

Meanwhile, the people who were originally drawn to MySQL as a dumb-and-quick datastore got frustrated with this line of development and christened the NoSQL movement. It's not so much a departure from relational databases (they were never really there), but a return to _MySQL_ basics, w/out the SQL.

</comment><comment><USER13> "Did you know that Cassandra requires a restart when you change the column family definition? Yeah, the MySQL developers actually had to think out how ALTER TABLE works, but according to Cassandra, that's a hard problem that has very little business value. Right."

Really did the MySQL people think about it? because it takes ages to do an ALTER. Even when you are doing something like _dropping_ an index it can lock up for hours, where no one can do any inserts. In contrast restarting a service is no big deal.

<comment><USER14> > In contrast restarting a service is no big deal.

Yikes, restarting a service that's so essential to everything else in web infrastructure is certainly a big deal. Where I work (large 30+ million users/month site), we have batches that do all sorts of processing and DB crashes (basically equivalent to a restart) can be a major pain because it can be difficult to figure out exactly what failed and when and how to best recover. You might say, "oh just re-schedule all the batches to allow downtime", but once you have 30 developers with a hundred or so batches, that can be damn near impossible to orchestrate.

A simple stateless web-app can probably tolerate a DB restart, but Cassandra was built to scale - not to host a to-do app.

ALTER takes ages to do because of the ACID constraints of MySQL. If you want, you can sacrifice the ACID constraints by just cloning the table with the proper modifications and then dropping the table, but I'm venturing into DBA- land for which I am in no way qualified to profess knowledge.

<comment><USER12> > ALTER takes ages to do because of the ACID constraints of MySQL.

No, I don't think it has much to with ACID. Rather, they made a simple single implementation of ALTER TABLE that copies the whole table out on any change whatsoever. Add a column? Recreate the table. Add a table comment? Recreate the table. Drop an index? Recreate the table.

They _could_ have identified cases where in principle the table & metadata could be modified in-place, but that would be a lot harder than a simple copy. It would probably necessitate changes to the legacy architecture, which in turn would require a host of other changes.

</comment></comment></comment><comment><USER15> I can't believe some of what is said by people on both sides of the NoSQL arguments. Discounting use of RDF data stores, almost all of my recent work involves PostgreSQL and MongoDB. I think that it is blatantly obvious which to use in specific circumstances. I have not had to do this yet, but using Datamapper.setup, you can integrate the use of both in the same application by storing some model data in a relational database and some in MongoDB, as it makes sense to do so.

<comment><USER15> Here is an article on mixing Datamapper + MongoDB + MySQL: [http://lunarlogicpolska.com/blog/2010/02/15/mysql-and- mongod...](http://lunarlogicpolska.com/blog/2010/02/15/mysql-and-mongodb- working-together-in-kanbanery)

</comment></comment><comment><AUTHOR> As is to be expected from this author, this is definitely on the flame-bait side of things. I submit it because I believe there is an important point here: for the vast majority of startups, going with a relatively unproven "NoSQL" database is a premature optimization and an unneeded technical risk. I disagree with the author that these databases are a flash in the pan, but their over-application is.

<comment><USER16> I dunno, I see the opposite: RDBMS's are a premature optimization. In my experience, it's /much/ easier to hack together a quick webapp in MongoDB, because you don't have to worry about relations, migrating schema, etc. Sure, it might be slower than Postgres on a billion-row table, but wait until you have a million rows before you shackle yourself to the relational constraints.

<comment><USER17> Absolutely right.

He has it backwards. You use NoSQL to 'get shit done'. When you have a billion rows, then worry about schemas. By that point you will have a much better idea, a - what said schema should look like, b - what the architecture of the Postgres, or mysql, or Oracle should look like, and c - how much money you will have to solve the problem.

<comment><USER18> I once worked in a Notes shop. Notes has no schema for documents and nothing to enforce migrating data from older documents to the current format. After a few years of customers manipulating data with various versions of the code, they had documents in such bizzare combinations of states that it was no longer possible for anyone on our dev team to inspect them and say which behavior would be right for the workflow.

Schemaless data should only be a summary of data properly maintained elsewhere, which you can regenerate at need. If your _authoritative_ data has no schema, it will decay to garbage.

<comment><USER17> That's because you waited years to address the problem. Not only that, you also rewrote the code, as I advise. But you did not take the opportunity to address the structural data issues you were having, contrary to my advice.

My strategy is to rewrite the code, if needed, but with an eye towards addressing structural data issues. After a few months use of a web app you have a good idea of any surprising usage patterns that may appear. Readjust at that point when you are 'talking with data'.

This advice is for small startups of the HN variety, where 'customers' are a lot more important than 'authoritative' data stores initially. NoSQL systems are useful tools for mitigating the danger of doing too much engineering upfront. Many tech entrepreneurs fall victim to doing too much upfront engineering in the hopes of their data store not 'decaying to garbage', only to find that no one wants to use their product. NoSQL makes it easy to go back and migrate off the data you want to store 'on the move'. When you have a better idea of how much of it there is, and how it is used.

<comment><USER18> If you are not doing data migration, after n revisions to the data management code, each record can be in any of 2^n states, depending on which code revisions did or did not modify it. How many revisions can you make before your code can no longer handle some of your older data? I'd say days' worth, not months, because you're trying to iterate a lot faster than we did. And the odds of a complete rewrite understanding all your old data are even worse.

If you are doing data migration, you necessarily have an old and new schema in your head. At that point you're just refusing to write it down and let the tools tell you whether the code agrees with you.

</comment></comment></comment></comment></comment></comment><comment><USER5> No one has ever explained this to me: why are we partitioning this space? Why can't a single database management system:

* have individual tables, indeces and views that are _either_ relational _or_ document-oriented, _or_ graph- or object-based while we're at it, on a case-by-case basis,

* manage them all in a single, well-known distributed pool,

* and present a unified API to access all of them (e.g. a Structured Query Language of some sort)

* that allows tables of disjoint types to be joined in queries, with appropriate warnings when it creates non-optimized query plans?

In other words, why can't I say that my reports table should use the "relation" backend, while my messages table should use the "document" backend, and be done with it?

It's as if, when you went to a car dealership, they asked you whether you wanted to see the "cars with cigarette lighters" or "cars with automatic windows" section. Why can't my car do both?

<comment><USER19> _have individual tables, indeces and views that are either relational or document-oriented, or graph- or object-based while we're at it, on a case-by- case basis_

This is already the case. Nowadays, almost all relational databases (except, of course, MySQL) support XML columns. PostgreSQL supports them rudimentary, and DB2 and MSSQL have even special storage strategies and index structures for XML, i.e. for generic tree structures, data-oriented as well as document- oriented ones.

Also, abstract data types ("encapsulation", the base of OO) are implemented in these databases, too (except, of course, in MySQL), as well as other OO features such as table inheritation and some kinds of polymorphism.

<comment><USER5> I'd love to see a comparison between using these XML engines for queries and NoSQL, then. I'm betting they'd be competitive at least to the point that, if you already had one of the supporting DBMSes set up, there would be little point in training your DBA on NoSQL as well.

</comment></comment></comment><comment><USER20> NoSQL might be hype. Let's get specific. Cassandra eliminates the SQL database single point of failure and hard to replace masters via a lose sync, "eventually consistent" protocol.

Is there some startup offering a web service that doesn't need that?

And have you ever tried to deploy an SQL database capable of thousands of miles apart syncing?

Eventually consistent is quite a different model than ACID. If you accept that, and accept that you can't rely on networks to always be up, you'll live comfortably and cost effectively.

<comment><USER21> I wonder how long will it take for the simple "if you need ACID, go SQL, if you don't, you'll be fine with NoSQL" truth to sink in.

NoSQL databases have been in use since before I was born. Is anybody doing airline reservations on DB2?

</comment></comment><comment><USER22> I recorded a list of issues that may prevent you from using Cassandra as a general purpose website storage right now.

<http://www.codexon.com/posts/is-cassandra-ready-yet>

It appears as though Ted's complaint about needing to restart Cassandra to modify ColumnFamilies (tables) is nearly obselete. A patch for the last remaining subtask has been submitted.

</comment><comment><USER23> I can't wait for these types of articles to die.

</comment><comment><USER24> I'm getting tired of both sides of this argument, I'll be happy when the whole back and forth dies :). Rarely do you see a balanced opinion. Sometimes it's people that are fanatical about the new-ish NoSQL idea. Other times, like this, it's someone so stuck in their ways they think that everything but what they like is a fad and nothing will ever change.

One of the key things I look for when I interview developers is that they can recognize the right tool for the job. Potentials that get married to a technology or language are shown the door pretty quickly.

Also, as others have pointed out, this particular article seems to not quite understand the decisions involved, to the point of getting some things backwards.

</comment><comment><USER25> I myself am not actually sold on the noSQL movement, at least not on the idea of ditching SQL entirely. It has its place, but may not be the best solution for every problem.

That said, on the authors complaint about having to restart cassandra when doing the equivalent of an alter table: lately every time we do an alter table in MySQL (which takes hours on large tables, during which time you can do nothing with them), when the alter finally finishes, MySQL mysteriously crashes. MySQL may have given more thought to the problem, but their solution obviously has problems too.

</comment><comment><USER26> Macs are better than Pc, C# is better than Java, Unix is better than Windows, RDBMS are better than NoSQL databases...

Why can't people just use the best tool for the job and move on...

From a personal stand-point we've switched from MySQL to Google AppEngine (and BigTable). Although I find there are some major drawbacks (e.g. joining tables) not having to worry about database servers and scalability is a major advantage. That said, if MySQL becomes the best tool for a particular feature, then let it be...

</comment><comment><USER27> The scalability aspect of "NoSQL" is interesting, but I think possibly the more interesting part is the wide diversity of data models (key value, schema- less tables, document databases, etc)

True, some of these models are more restrictive than traditional RDBMSs to provide scalability, but I think some of them will often be useful even if scalability isn't initially a concern.

In fact the term "NoSQL" itself is more relevant to the data models than the scalability.

</comment><comment><USER28> The author makes some very valid points, but I will retort that RDBMS are overused as well.

Sometimes you just want to store data on the disk in a safe and language agnostic way.

You don't care about relations.

In that case, many "NoSQL" engines are really great.

<comment><USER29> "Sometimes you just want to store data on the disk in a safe and language agnostic way."

You mean, kind of like a file?

<comment><USER8> Well, since you need a _safe_ way, you'll need a locking mechanism, too. And since it needs to be language agnostic, you can't just dump the internal representation of your object to disk, so you need some sort of serialization.

At that point, it's probably easier to go with an already existent object or document store.

<comment><USER7> Ladies and gentlemen, we have a winner!

If you start using the filesystem as a datastore that requires concurrent access you open up a whole new can of worms. You need a locking mechanism - which you'll probably implement using (wrapped) native syscalls. Not only does that break cross-platform operation, you'll also have to work on and fix (but find first, of course) bugs in the locking implementation. As you spend more and more time on this and your app starts growing, you'll find yourself spending more and more time working with the limitations of the filesystem you're using (file size limits, directory size limits, access times for files in large directories). You can hack your way around all that but then you have to face other critical tasks. Say .. backup and restore procedures. Can you do partial backup/restore operations? No? Well, get ready to write code for that too. And you preferably want to be able to do those live. Remember those locking issues you solved when you started down this road to hell? Yeah, they're back with a vengeance now.

How about a full restore? Maybe you should have implemented a replay-able log system to get that full restore up to speed with the state of the db since the time of the last backup.

Or maybe this isn't exactly the right point at which to re-invent the wheel :)

</comment></comment></comment></comment><comment><USER30> +1 for the Batman rollerblader. But that's about it. Use what works, some apps do justify nosql off the bat. Many don't.

<comment><USER31> He's a fixture of Seattle's big Solstice parade: <http://www.flickr.com/photos/daffodilious/3646480480/>

Keep digging through that photoset and you'll probably see pix of the naked bikers, too.

</comment></comment><comment><USER32> I found the comparison with 'Real Businesses' particularly funny, given Wal- mart have have 2.1 million employees worldwide and Twitter has 75 million users...their scaling requirements are different by a factor of 35.

<comment><USER33> You're comparing two completely different businesses on disparate metrics.

How many 'users' does WalMart have worldwide? I'd say at least 500 million on whom they keep a purchase record. Then there's products, credit card numbers, suppliers, etc.

<comment><USER32> But in terms of their 'real business' it is not the number of customers they have but the number of they have but only their employees who will be using their systems. The purchase records, products and credit card numbers are closer to Tweets than users.

<comment><USER33> I don't think the number of people doing data entry or accessing a system matters nearly as much as how much data one has to be tracked. WalMart's data needs exceed that of Twitter, they exceed the needs of Facebook. I don't know if they meet or exceed Google, but I'd imagine it's up there.

</comment></comment></comment></comment><comment><USER34> Thank goodness - someone finally said it.</comment>


Blockchain could be the key to revolutionizing our energy grid - <AUTHOR> https://www.technologyreview.com/s/609077/how-blockchain-could-give-us-a-smarter-energy-grid/ <comment><USER2> Blockchain could be the key to doubling our energy requirements.</comment>


Stanford Prof. Sues Team of Scientists for Debunking 100% Renewables - <AUTHOR> http://environmentalprogress.org/big-news/2017/11/1/stanford-university-professor-mark-z-jacobson-sues-prestigious-team-of-scientists-for-debunking-100-renewables <comment><USER2> Flagged because the website appears to be an anti-solar campaign to promote nuclear.

"Renewables like solar and wind require vastly larger amounts of land and mining in order to produce power that is unreliable. Under the guise of protecting the environment, renewables destroy the environment."

<comment><USER2> I think that these new 501c educational non-profits which obviously promote a corporate agenda are one of the most dangerous threats to rational discourse in our day.

<comment><AUTHOR> I was hoping it would prompt a good discussion. By putting it up and talking about it here, what is the nature of the threat you're worried about? Isn't it worse to not talk about these kinds of things at all?

<comment><USER2> The threat is that companies can create fake "educational non-profits" and lie to people and even get their lies into classrooms, presented in the pseudo- objective light of educational material.

I do not know which nuclear company funds this "non-profit" but its bias and bad faith is obvious.

When I was a student teacher, I was put into a program, at the time funded apparently by Visa, who's sole purpose was to deliver anti-regulation propaganda to 4th graders. The program seems to have since expanded its list of sponsors to many other large financial institutions [1].

The material I was teaching included demonstrably false claims, including the claim that WTO promoted free trade included sufficient environmental protections. Along with cartoonist pictures of jumping dolphins and people smiling an planting trees. When the reality of WTO mandated free trade looks like this [2].

[1] [https://www.juniorachievement.org/web/ja-usa/financial- repor...](https://www.juniorachievement.org/web/ja-usa/financial-reports)

[2] [https://blog.positiveluxury.com/sys/uploads/2015/01/slashbur...](https://blog.positiveluxury.com/sys/uploads/2015/01/slashburnmain.png)

</comment></comment></comment></comment><comment><USER3> Instead of stating the assumption the be flawed, they've termed it as a lie. While I disagree with the lawsuit, accusations of lying seem a little outlandish.

No journal should encourage publication of accusations of lying

<comment><USER4> That's because this site is a bunch of nutters. Have a browse through the site. Perhaps they actually have a point, but it's difficult to take seriously when it's a crazy person trying to make it.

Anyone have a reputable link to the story?

</comment></comment><comment><USER5> The paper:

[http://www.pnas.org/content/114/26/6722.full](http://www.pnas.org/content/114/26/6722.full)</comment>


Using [MySQL | PostgreSQL] on Amazon S3/EC2 - <AUTHOR> http://www.elastra.com/

<comment><USER2> Anyone have experiences with this service to share?</comment>


We made a terrible song then bought Spotify streams for it as proof - <AUTHOR> https://noisey.vice.com/en_uk/article/j5dqdx/streamify-spotify-buying-streams-cl1ckba1t-digital-music?utm_source=nt <comment><USER2> That's some hot fire.</comment>


Startup Quote: James Cash Penney, co-founder, J.C. Penney - <AUTHOR> http://startupquote.com/post/2763442372

<comment><AUTHOR> Success cannot come from standstill men. Methods change and men must change with them.

\- James Cash Penney

<http://startupquote.com/post/2763442372></comment>


Your Startup Is Not The Enemy, It's Your Dance Partner - <AUTHOR> http://prtipsforstartups.com/entrepreneurship-war-dance/

<comment><USER2> Title is ambiguous, it is either referring to startup, or enemy.. "Your startup is not the enemy, it's your dance partner...that is the enemy"

Personally, I find that hilarious, an villain of a dance partner.

At any rate, I don't really like the idea of humanizing something as cold and unfeeling as a 'startup'. Dance is art, beauty, skill, self expression, but it really fails to connotate the risk and danger of failure that war as a metaphor does.

</comment><comment><USER3> I like the metaphor, and I'll extend it by saying you want to assemble the best dance crew you can find!

<comment><AUTHOR> Thanks, Hong! These guys definitely get it done as a dance crew: [http://www.jbwkz.com/](http://www.jbwkz.com/)

</comment></comment><comment><USER4> I love the name! Congrats! :)

<comment><AUTHOR> Thanks, Deyson.</comment></comment>


So LinkedIn is a giant Rolodex, eh? - <AUTHOR> http://stilgherrian.com/internet/so-linkedin-is-a-giant-rolodex-eh/

<comment><AUTHOR> A follow up blog post to the one discussed here:

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


Honk: mind blowing Speech-to-Meaning engine show impressive speed and accuracy - <AUTHOR> https://www.youtube.com/watch?v=M1ONXea0mXg

<comment><USER2> This is what I call a mother-of-demos !

All stuff no fluff!</comment>