We have bought followers fo $5 and discovered 15M botnet on Twitter - <AUTHOR> http://sadbottrue.com/article/15/ <comment><USER2> 15M is nearly 5% of Twitter's active users, or all the growth they've had in 2015. Assuming these bots are "active".

<comment><USER3> If it's true, I wonder what effect it will have on the value of Twitter(I do assume this isn't the only one).

If it turns out half the use base is made out of bots or non-active registered users that is.

</comment></comment><comment><USER4> Besides these 'obvious' bots, there are more that have humans in control, but which the humans never read tweets, they just post them. I would bet, though have no data, that there is a large percentage of these 'post-only' accounts. Not sure if they should be called bots or not...

</comment><comment><USER5> $1M from 15M fake accounts is rather low.

6.67 cents per account.

Isn't it easier and much more profitable to fake click ads at such scales?

Also getting 15M fake accounts means getting 15M fake emails, which isn't cheap:

[https://buyaccs.com/en/](https://buyaccs.com/en/)

<comment><USER6> >Also getting 15M fake accounts means getting 15M fake emails, which isn't cheap

Unless you create them yourself, which seems rather logical if you're in the account creation business anyway.

</comment></comment><comment><USER7> So you spent $40,000 to reveal those bots? All to write a short blog post?

Am I missing something?

<comment><USER3> I think that's how much it would cost or the full amount. I do think they spent $400 though. Very weirdly written article.</comment></comment>


Ask HN: How will it impact my webapp if it is written in Python instead of PHP. - <AUTHOR> Folks, I have seen too many HN posts on the fact that PHP is not a good language to develop a robust web application, despite of the fact few of the biggest web sites are running on PHP. We(my team and me) started debating on the issue of choice of the technology for the next project. I am still in some ways not convinced that python may be a better approach.
PHP and Python
* Both have good framework web.py | codeigniter
* Both have good helpful community and support
* Both large set of plugins
How will it impact my webapp if it is written in Python and not PHP <comment><USER2> It will probably negatively impact your project if all of your team know PHP better and are more comfortable with it. Pick whichever language works best for your team. If some of your team love Python and are able to convince the rest of you as to why its better, then go for it. However, a bunch of strangers on HN probably aren't going to offer much of value. If you are really curious, I suggest diving into Python yourself (no play on words intended!) by reading a book on it, writing some code examples, and then maybe a small project of around 500-1000 lines, trying to use the idioms of the language that you are less familiar with. And if you're not curious, more power to you! In the end, it's the product and the team developing it that are most important.

</comment><comment><USER3> Python will probably be easier to write and almost certainly be easier to maintain.

It's possible to write good code with PHP, but a great deal of the example code you'll find online is not good. On top of that, the language itself tends to encourage bad design (see "broken window theory").

Python has a strong culture of having one obvious and good way to do things. In some situations, that can feel restrictive, but it tends to make dealing with code other people wrote easier.

<comment><USER4> How do you relate "broken window theory" with the grammar of PHP?

<comment><USER3> Broken window theory, as it applies to code essentially says that sloppy code begets sloppy code. PHP itself has sloppy design, such as inconsistent argument order and naming conventions for built-in functions.

Most of the complaints I can think of about PHP that are objectively demonstrable are outdated. The language now has namespaces, closures and the like. Most of the complaints I have left have to do with the feel of the language, and some remaining cultural elements; it _feels_ like a ghetto, even though it seems to have modern infrastructure now.

<comment><USER5> And thus Zak withstood the zackattack...

</comment></comment></comment></comment><comment><USER6> Python will allow for easier modularity, wheras PHP will make it easier to pollute the global namespace. Likewise, all standard python components are made available in namespaced modules, are consistently named and well documented. You can certainly write PHP without creating a global mess, but novice developers will be tempted to introduce globals and the standard library is in the global namespace, setting a bad example.

Perhaps more importantly, many skilled developers favor Python and will avoid PHP. When you seek to grow your team, you will likely draw from a better talent pool if your application is written in Python.

</comment><comment><USER7> I'm happy that I'm developing my web apps with Python. I have used almost all Python web frameworks out there. So let me explain my experience.

Django - Until 1.2 Django was a total headache but with 1.2 it really is a great tool to develop web applications. No reason not to use it unless you feel something's missing. Django has an amazing community with very helpful people.

web2py - web2py lets you create apps very fast, it doesn't push you hard and you can build something in a very short time. However when things get complicated, you will want to quit web2py. I don't like its form helpers, I don't like its validation as the validation is unfortunately not per object but the input data and url routing is headache with web2py. Web2py also has a great community. All your questions will be answered in a short time.

turbogears - turbogears is a subset of pylons with sqlalchemy as orm and genshi as templating system. i don't like the @expose decorator. it's just not for me. provides many other tools by the way. TurboGears has a small but helpful community. SourceForge is using TurboGears.

werkzeug - now this is the framework of my choice. the endless freedom. it is only a skeleton which lets you dress your application onto it very easily. you can choose anything as your orm and templating system. provides a strong url routing mechanism. supports sessions, secure cookies and any other thing you may need. however i am not using werkzeug anymore as i don't like the way people act in #pocoo on freenode. this is the only reason i am not using werkzeug. they are ignorant and i don't like it.

Pylons - My favourite Python framework of all times. Flexible as much as it can be. Provides you the freedom you need for anything. I strongly recommend using Pylons. I am currently using Pylons and I'm very happy with it. Pylons is also used at some very popular web sites such as bittorrent.com, reddit.com, etc. It has a helpful community whenever you need.

Frameworks aside, how will using Python will help you? * Very clean and beautiful code. * Easy updating and maintaining the code. * Easiness and laziness. * Great set of libraries. * Python for your mental health.

And I'd like to thank justin_vanw for the great sum. :)

<comment><USER8> "however i am not using werkzeug anymore as i don't like the way people act in #pocoo on freenode. this is the only reason i am not using werkzeug. they are ignorant and i don't like it."

Would be nice to know if this is a general thing or if we did something in particular wrong. Because if that is what you remember of this channel we should really improve our behaviour then. So it would be nice if you could elaborate on that.

<comment><USER7> i'm sorry, it's my wrong choice of word. it's not ignorant but smart ass. i don't like that. nobody is pushing anyone for answering questions. if you don't feel like you're doing something you're happy with, then don't do it. i'm also sorry for making a generalization as i know some people on pocoo very helpful and friendly. i remember you, and daslch answering my questions that way.

and let me note that werkzeug is a framework that i'd like to see at the top and people know its value.

</comment></comment></comment><comment><USER9> Some perspective if you're using Python: I've mostly done desktop apps (ObjC + Cocoa and C++ + Qt). Some time ago I decided to learn web programming. I'd been programming Python for quite some time so, unsurprisingly, I started learning Django. I never felt at home with the framework. This might just be me, but Django has _too much_ magic -- which can be disconcerting if you like to know exactly what your framework is doing behind the scenes.

A month ago I started dabbling in Pylons. It's the best framework I've ever used. The Pylons Book is great, if a bit outdated. The official docs are nice (they _seem_ nice to me; I've been burned by Apple's shitty documentation). The entire framework basically consists of glue code to tie together best-of- breed Python libraries: Mako, SQLAlchemy, Beaker, WebOb, PythonPaste, FormEncode, HTMLFill, Routes. Oh, and it's all WSGI. WSGI is the best thing to ever happen to Python web development. You should at least skim the WSGI PEP (PEP 333) if you're serious about Python web development.

Next, I'm planning to check out Werkzeug. It's an even tinier set of libraries that allow you to, in effect, build your own framework. If you're building a simple REST-based service, Werkzeug is what you need.

I also know some people who swear by Web2Py. I haven't tried it myself, but I hear it's great for quick and dirty webapps.

</comment><comment><USER10> It really doesn't matter.

What matters is having great coders, great ideas for your app and executing them effectively and efficiently which is possible with both PHP and Python.

You can write horrible code with both languages, it might be horrible in a different way but it'd still be horrible. :D

That said, if you're the only one having doubts about Python but the rest of your team wants to write the app in Python and they do have experience working in Python - why don't you trust your team's judgement?

As it doesn't matter, it would be the sensible decision to pick the language your team would like to code in, imho. :)

</comment><comment><USER11> The two framework examples you give are not at all on the same level. CodeIgniter has a lot of stuff to structure your application, but many experienced PHP developers wouldn't bother with it (and I, personally, don't think it's worth all the extra code you're importing); web.py, on the other hand, merely gets you partway to where PHP starts, with regard to writing your application. If those were your only alternatives, then I'd say you probably want to use web.py, but if using web.py is one of the choices, then you might just as well use PHP without a framework at all, which is one less piece of third-party software to go wrong.

One thing I've really liked about PHP is that (using Apache) if the webserver is up, PHP is up. When I developed most of the applications in Python, it seemed as though I was constantly worrying about the application process failing, even though this happened very rarely.

PHP really is an ugly language, but you eventually get used to it. :(

</comment><comment><USER12> A friend of mine always says "it just doesn't matter" in his startup, meaning just chose a language instead of constantly debating over which is better, which will scale better, which sounds more awesome...

It's probably more important to just getting something done in the first place. You can probably rewrite when you get some revenue.

</comment><comment><USER13> If you have to ask this question, you're out of your technical depth.

The best thing you can do is promote the guy who's clamoring the loudest to steer clear of PHP to technical lead, and defer all future technical decisions to him.

The language is just a tool. Consider car racing. If you have a poor driver in the fastest car, it won't make a difference. No matter how fast the car is that he's driving, he's going to lose. And if you have a great driver in a slow car, no matter how good he is, he's going to be limited by the speed of his car.

If you have a poor technical lead, it won't matter what language you choose. You can give him a great language, but he will not understand and take advantage of its best features. If you have a good technical lead, but you choose a bad language, the quality and pace of his development will be forever limited by the language.

(And in the context of a team, the abilities of the team to make good technical decisions are limited by the technical direction your technical lead sets -- which is why you need the most talented guy in the position of technical lead.)

The guy on your team who is the most against using PHP is likely the one who best understands the ways in which PHP will limit your team. You do not have the deep technical understanding to make these judgments, and for that reason (without taking months of hard work to gain such understanding) you should defer to him.

Yes, some of the largest websites are written in PHP. But you do not have the same level of resources to throw at the problem that they have.

You're also starting your development at least 5 years later than any of the largest websites that you refer too. Frameworks/plugins/communities evolve quickly. There were more reasons 5-10 years ago to choose PHP then there are today. Companies that have already written millions of lines of code in PHP will find it very hard to switch to another language -- but you do not have to deal with the weight of such legacy issues.

As a small team, you need to look for every advantage you can get. Choosing a programming language that makes your developers more productive is an important part of that.

If you care about framework, community and plugins, Ruby is also a better language than PHP, and Rails provides these three things in spades. Assuming you don't have a good system administrator on your team, companies like Engine Yard and Heroku provide scalable managed Ruby on Rails hosting -- so you can outsource combating issues like down-time and data loss.

<comment><USER14> "The guy on your team who is the most against using PHP is likely the one who best understands the ways in which PHP will limit your team. You do not have the deep technical understanding to make these judgments, and for that reason (without taking months of hard work to gain such understanding) you should defer to him."

sorry, what? the guy on his team who is most against using PHP could equally well be an idiot who is simply repeating stuff he has heard on the web by rote, using regurgitated puff to hide his complete lack of understanding of both the issues and the languages themselves.

Your willingness to entirely overlook that possibility and to make the kind of sweeping statements you have made in your post in the absence of any data causes me to doubt that you have the kind of experience and technical expertise that is required to make that kind of statement.

<comment><USER13> Of course he could be.

I don't envy the position of any non-technical person that has to make key technical decisions on a technical project.

Ultimately it takes a good developer to spot a good developer, so a non- technical person seeking to build a "robust web application" starts at a huge disadvantage.

Without understanding the pros and cons of each language choice, all he can do is gamble on finding a smarter person than himself that he can trust. I'm advocating he choose the anti-PHP guy, slightly tongue-in-cheek, because given the limited amount of information presented, that choice gives him the best odds.

Being in the position of having to make such a bet is less than desirable, but given his lack of technical knowledge, what else would you have him do?

<comment><USER14> Im not clear what makes you think the OP is a non-technical person? The question he phrased was the _exact_ question that he should have asked, what is unfortunate (but unsurprising, given the complexity of the answer) is that nobody seems to be answering it clearly.

He asked: "How will it impact my webapp if it is written in Python and not PHP"

That is a _fantastic_ question, and it deserves better responses than the 'language x sucks' ones it is mostly getting.

The simple fact that he asked the correct question gives me a great deal of faith that he is in fact technically inclined, technically able and has some development experience. The way in which it was phrased makes me believe that english is not his habitually spoken language.

He clearly _does_ lack experience in using Python, and is (quite reasonably) hesitant about plunging into a different language without attempting to find out more about it.

"I'm advocating he choose the anti-PHP guy, slightly tongue-in-cheek, because given the limited amount of information presented, that choice gives him the best odds."

it really doesn't. some quite ridiculously stupid people are anti-PHP.

Given the information available, I would advocate that he use the language that the majority of people on his team are most familiar with. Nothing like having a team learn an entirely new language and associated design skills to bog down a project.

<comment><USER13> "gives me a great deal of faith that he is in fact technically inclined, technically able and has some development experience."

I'm sure he has development experience. But too limited an amount.

It is a valid question, but I don't think any response provided here can properly demonstrate to him the value of a language like Python over a language like PHP. No more than someone could teach him to fly a plane in the span of a post like this. It's not a simple subject, by any means.

The best anyone can do is point him to resources that he could study and learn over a period of time -- or advise him to listen to someone talented that he trusts.

I'd be very careful listening to anyone advocating PHP for a project starting from a blank slate. Yes, there are talent developers that prefer PHP. And there are many more poor developers that prefer PHP as is the most popular default choice for those that lack experience, are not comfortable with their own technical judgement, or believe that all languages are more or less equal.

Many on HN would argue that a top-tier developer would not choose PHP, period. But you may not be able to get hold of a top-tier developer -- and in that case a team of solid PHP developers may be the best available choice, if not the best possible choice, particularly if you've worked with them before, and the project is technically simple and limited in scope.

<comment><USER14> "I don't think any response provided here can properly demonstrate to him the value of a language like Python over a language like PHP. "

Oh, I entirely agree. The practical differences between them in a web application just aren't that important.

</comment></comment></comment></comment></comment></comment><comment><USER15> I have been writing serious, database backed, large dataset, etc etc web applications using Python for about 4 years. Although it may seem like bragging, I probably know the ins and outs and what-have-yous of the python web programming landscape as well as anyone.

State of web programming in python:

The frameworks:

Django: More powerful? No. Faster, more seductive. In the long run you'll outgrow it, if you are any good. It gets you from zero to twenty five percent almost instantly, then gets in your way. The ORM is a terrible mess. The template language is _easily the worst_ (slowest by 10x, slow enough that common templates take 300ms to render, insanely unusable 500 line tracebacks), of any of the common python templating languages. Once you swap out the ORM and the templates, you suddenly realize what is left is also a piece of crap. Django middleware are horrid. I remember trying to write a database session middleware and an error-reporting middleware in django, only to determine it is literally impossible (there are edge cases where any middleware can be skipped and never see the request). When having to deal with it, I use it's oddball WSGI adapter and park WSGI middleware in front if it. I can not say enough bad things about django, it is rotten through and through compared to the alternatives. The admin interface is neat, but is basically a toy once you run into real complexity or data volume. I might use django if I were making a content based application on contract, since the admin interface would be a huge piece of free functionality, or a very simple web app, like a hotel website or something.

Pylons: WSGI based, thank the lord. This means you can write real, flexible, efficient, predictable middleware. I was a huge Pylons fan from around the beginning of 07 until I discovered Werkzeug near the end of 08. I still lurk in #pylons quite a bit, and it was at my urging that the Banquet library (a common interface to all template systems) was discarded (although it may have been on it's way out anyway). Pylons uses great libraries under the hood (webob, beaker, etc), and I would recommend it without hesitation. The __call__ method of the BaseController class used to be a complete mess, I would guess that it still is. Luckily you only run afoul of it very occasionally. the __before__ and __after__ methods are handy. When I stopped using it they were still recommending AuthKit officially, but the mood of #pylons seemed to be (and I agree) that AuthKit is a horrifying abortion that should never be used. The canonical stack with Pylons is Pylons-SQLAlchemy- Mako. I would swap Mako with Jinja2, although who use Mako tend to be loyal to it, and there aren't too many huge warts (the way it does template inheritance makes my head hurt though). TLDR-Pylons good.

Werkzeug/Flask: My personal favorite. You are building a web application, you should have all the moving parts where you can adjust them as necessary without bolting on bizarre hacks, and Werkzeug lets you do that. It may be a bit of a jump for a beginner. Flask is an attempt to make a 'framework' out of Werkzeug, and it seems to be getting some momentum. If you know what you are doing, I believe Werkzeug is the best thing out there for Python web programming.

Tornado/Twisted: Either is great. Due to the pain of dealing with them (you need special event driven db adapters, etc) I would only use them for long- polling applications or the long polling portions of a general application.

Also rans: Turbogears: crap, web.py: crap. Also also rans: Zope (if you don't know what it is already, you probably don't want it).

How to deploy:

mod_wsgi for Apache is the _one true way_ to deploy python web applications. Anything else (fastcgi, reverse proxy, etc etc) is a hard to maintain, unreliable, mess. I would put mod_wsgi on each webserver, and have a machine running nginx or varnish or pound as a load balancer. Varnish is the best if you want to do sophisticated caching or edge side includes, nginx is easy and fine also. Everybody seems to want to argue for something besides mod_wsgi, since Apache is so unfashionable. Part of me wants to encourage everyone to do so, because it makes it drop dead easy for me to walk in and 'fix' your apps reliability problems in about a half a day, and look like a genius in the process. You can deploy python applications to run multiple threads per instance, but realistically due to technical limitations of the interpreter you don't want to run many threads. I suspect less than 10 is the optimal amount. Luckily you can have mod_wsgi spin up multiple processes as well. I would have it recycle the processes after around every 25000 requests, even if you don't have any memory leaks in your app.

Database: I recommend SQLAlchemy. There isn't really anything else worth mentioning. Even if you hate ORMs (there is a strong argument for and against), the sql expression language SQLAlchemy gives you is basically the most amazing thing there is. It takes quite a bit of time to master. If you use SQLAlchemy, use the defaults for the Session until you understand it, or you will end up spending a lot of time and trouble mucking with it.

Nosql: I don't trust it. I suppose I might be becoming a dinosaur, but I also haven't had a major use case where I really needed it.

Other: These don't really have to do with python specifically, but I'll throw them in at the end here: I recommend Redis over Memcached. I strongly recommend Postgresql over Mysql (unless you don't understand what a join is). If you have lots of images (say over 2000), put them in S3 from day one. Some stopgap solution is more painful to fix later than earlier.

<comment><USER16> I'd have to disagree with you here. In fact, my experience is almost exactly the opposite.

Django is incredibly easy to get going, and you can rewrite bits of it as you need to. It's reasonably easy to switch out the templating language if you need to, and I haven't had any problems like you describe with the ORM or admin app. For prototyping apps I wouldn't use anything else. I'm currently running with nginx/FastCGI and haven't seen any problems.

Pylons and SQLAlchemy, on the other hand, I found _hideous_ \- lots and lots of boilerplate, particularly when setting up models, weird tracebacks that had no relation to the original problem, poorly integrated bits - I basically couldn't populate databases from a unit test, then run a controller, then check the results, since SQLAlchemy would lose the connection after the controller.

<comment><USER15> > I basically couldn't populate databases from a unit test, then run a > controller, then check the results, since SQLAlchemy would lose the > connection after the controller.

What you say makes no sense. SQLAlchemy just uses the usual adapter for whatever database you are using. What does "loses the connection" mean to you? SQLAlchemy, by default, uses a pool of connections. I suspect you tried it for an hour and gave up without really understanding what you were doing.

<comment><USER16> From memory, committing to the database involves both saving and closing the connection. So when you get back to the unit test, there's no database connection.

Maybe there's a way to do it properly within SQLAlchemy, but if so it's completely non-obvious from a few days of searching the web, Pylons documentation, Pylons book, mailing list, etc.. I wasn't trying to do anything fancy, just set up a very basic unit test.

Here's one of my old comments with some more detail: <http://news.ycombinator.com/item?id=1176948> "Instance <Foo at 0x103779f90> is not bound to a Session" was the error that I was getting.

<comment><USER15> [http://www.sqlalchemy.org/docs/session.html?highlight=expung...](http://www.sqlalchemy.org/docs/session.html?highlight=expunge#quickie- intro-to-object-states)

The following is more of a screed than a personal response to your post, so please don't take it personally.

This is something I run into quite a bit more than you might expect. Partly it is because I used to spend a lot of time in #sqlalchemy, #pylons, #pocoo, #python, and #postgresql on freenode (I'm 'ltbarcly' on freenode, feel free to msg me HNers!). For some reason it is common to believe that you can sit down and write applications that use an ORM and relational database without knowing both the ORM and relational databases.

If you are going to use relational databases, you should be prepared to become an expert in SQL, Database drivers, unicode (and why utf-8 or any other encoding isn't the same as _unicode_ , in the same way that jpg or gif isn't the same as _image data_ ), indexing, data types, normalization tradeoffs, transaction isolation levels, locking semantics, ACID tradeoffs, how to read and understand query planner output, and much more. This is a lot to know, but if it were a college class it would be less than a semester long.

If you are going to use an ORM you have to know _everything_ you would need when you use a relational database, and in addition how and when the ORM performs queries, how it maps to the database, what queries it will produce and when for any given action or attribute access, how db transactions map into the orm operations, how to perform common SQL operations via the orm (rather than loading more data than you need and filtering or joining via the application).

</comment></comment></comment></comment></comment><comment><USER17> I do not know what you mean by a "robust" web application, but in my experience Python libraries (for example feedparser) are of higher all-around quality. Less pitfalls, means fewer bugs and faster development.

<comment><AUTHOR> What I mean by 'robust' is scalable and usable.

<comment><USER18> And what do you mean by scalable and usable? :) Scalable in what sense? Usable by who?

</comment></comment></comment><comment><USER19> With PHP it will be much much easier to outsource parts of your project compared to python. There are more PHP developers and they are much cheaper.

<comment><USER16> The downside of that is that it's much harder to find good PHP developers. There are an awful lot of awful developers who use PHP; less so with Python and other 'niche' languages.

</comment></comment><comment><USER20> The only way to get useful answers (vs just answers) to these questions is to get a feel for web-app development with Python yourself.

Work through a Python tutorial (I suggest "Dive Into Python") first and then set up Django and work through the Django tutorial. Build a small app of your own with Django.

If you are a decent programmer all the above should take you a weekend at most.

And then you'll have some first hand experience about difficulty of transition etc.

Fwiw, I prefer Django to PHP. But then I am biased so use appropriate amounts of salt. I'd kill myself if I had to work for very long in PHP.

</comment><comment><USER21> If you want a more "guided" approach to Python webdev, try looking into Django. There's a large community that has built up around it contributing tons of plugins.

I say this as someone who is working on a Pylons site. You can do anything with Pylons that is possible with Python, you just have to figure it out yourself or twist someone else's library to make it work. Sometimes you don't need that much freedom and the guided approach will do 90% of what you need. Do a bit of research and see which approach best suits your needs.

<comment><USER22> I'd also recommend a look at Flask: <http://flask.pocoo.org/>. It's quite new but more polished and easier to learn than Pylons, and comes with excellent documentation and handy extensions.

As you say, however, Django is a good place to start for a beginner - it has a larger community and ecosystem of apps for doing just about anything web- related (although the apps are of variable quality). It's also quite mature (5 years now) and has more job opportunities.

</comment></comment><comment><USER23> How about choosing one that your team knows better? Your startup's app is not a good place to learn new technology, as proven by Reddit and Twitter, among others.

<comment><USER15> Yea, Reddit and Twitter are great examples of places that failed because they were afraid to learn new technology? Wait. That failed because they tried to learn and implement things in unfamiliar technologies? Oh, wait, what?

<comment><USER23> No, they tried to build the app with a technology they wanted to learn {Reddit : Lisp, Twitter: Rails} and then had to rewrite it (mostly) from scratch when that didn't work out {Reddit: Python, Twitter: Scala}.

Neither failed, because they were smart enough to know when to ditch. God knows how many startups failed because they didn't know that.

<comment><USER24> For Twitter, Rails _was_ the technology they knew. They decided it wasn't the right tool for their needs. Scala is the tech they learned (and continue to learn) on the job. They even have a group blog detailing this process (<http://gracelessfailures.com>).

</comment></comment></comment></comment><comment><USER25> Maybe debating about it is not the right approach. If you have experience in PHP and you can afford some (inherent) delays in the next project you should try Python and see for yourself. You will be hit by reality faster and better than any debating would. Then you'll have an educated opinion for the next (second) project.

I'm biased towards Python.

</comment><comment><USER26> I've been creating sites for a number of years now and have used php since the days of putting perl scripts in your cgi-bin. I'm just now starting to learn python. Here's mho.

If you use php, check out symfony. Codeignighter is crap once you get to know you way around symfony. Php is something I feel comfortable using and know my way around. I use it for all my web sites.

The reason I am learning python is to use the app engine. It looks like a cleaner language then php and seems to be slightly more powerful.

I think it would come down to 1) does your developer know php, python, or both? Let him develop in whatever language they choose. 2) where are you gonna do with it? I think there's a time and place to use php and to use python.

</comment><comment><USER27> From my Quora post on PHP[1]:

"PHP is just like every other language: it allows you to write horrible, insecure, stupid code. It also allows you to write clean code."

Really, the language doesn't matter. Find people who write good code and give them the tools and atmosphere to do so, and your code will be good. Both are mature languages with plenty of time put into plugins, security, and documentation. Both can obviously scale well, and both have the same set of capabilities barring some specific edge cases.

[1] - [http://www.quora.com/What-are-PHP-s-main-flaws-(and-good- par...](http://www.quora.com/What-are-PHP-s-main-flaws-\(and-good- parts\)?__snids__=1360846#answer_55743)

<comment><USER28> _Really, the language doesn't matter._

I disagree.

Python, by design, makes it hard to write bad code. PHP, by design, encourages bad code.

<comment><USER14> but a good developer can write good, clean code in either one.

Every language/IDE combination encourages a 'default' coding approach, I agree that the PHP 'default' coding approach tends to be to create a hopeless muddle of assorted, random crap. OTOH, which would you rather have...a coder who is currently being 'forced' to write marginally better code in Python than he would in PHP because of the language constructs, or a coder who understands good code design and knows how to apply it?

A good coder will be a good coder in any language, the fact that a crappy coder can be made to look marginally better if they are forced to use Python just doesn't feel like much of a win to me.

<comment><USER13> BS. Can PHP do this? <http://www.joelonsoftware.com/items/2006/08/01.html>

(In fact the latest version of PHP (5.3) can, but for years PHP has been lacking this, so the point stands.)

No amount of "good code design" can work around core features that are missing from a language.

The argument that all languages are more or less equal is as nonsensical as saying all cars are more or less equal, or all guns are more or less equal -- it ignores the tremendous advantage that using good tools can provide.

<comment><USER14> "Can PHP do this?"

well, as you've pointed out yourself, yes it can.

"for years PHP has been lacking this, so the point stands."

Im sorry? I must be missing the point. How does the presence (or absence) of a particular language feature prove or disprove the point that bkrausz made originally?

"..<snip>...it ignores the tremendous advantage that using good tools can provide."

not really. well, kind of.

so the thing is that if I take the things that (in my experience) work to make a project successful, and I squash them all up into a big ball, and then I take that ball and I split it up into two heaps....one heap consisting of the things that the developers brought to the project and one heap consisting of things that the language brought to the project...and I look closely at the relative sizes of those two heaps....then almost always the heap of things that the developers brings is a _lot_ larger; so much larger in fact that in general the effect of the programming language can be ignored.

That is a pretty general statement, and there are clear cases where it is simply not true, but in general it is true, and I would particularly claim that in the case of a web application and choosing between PHP or Python, it absolutely is true. In the hands of good developers either will solve the problem well, both will provide a good, readable and maintainable code base. In the hands of an idiot, neither will be any good.

<comment><USER13> "Im sorry? I must be missing the point. How does the presence (or absence) of a particular language feature prove or disprove the point that bkrausz made originally?"

Yes, you are missing the point. I refer to closures, the feature at the core of functional programming, not just any "particular language feature". Functional programming is an extremely powerful tool to wield, and has been absent from PHP since its inception until very recently.

A great developer with a functional programming tool in hand is able to well outperform a great developer who must work around its absence.

Here's a paper that surfaced to the front page of HN recently on the importance of functional programming: <http://news.ycombinator.com/item?id=1482797>.

This is just one example, but a very potent one, of why language selection matters.

<comment><USER14> yeah, closures are good.

we really do appear to be having two different discussions, Im neither claiming that PHP is 'better' than Python nor am I arguing against functional programming.

I am simply arguing that the most important thing in a project is the quality of the developers, not the language they chose; and that given a good developer and a choice between PHP and Python I would almost certainly find the relative language features so entirely unimportant that I would choose the language based on stupid things like what language the existing codebase is in, what language the developer preferred and had most experience in and how recently I had been frustrated by the languages in question.

OTOH, I am _always_ willing to debate the relative importance of language features, so by all means lets go there.....

Closures in particular are a very powerful tool in async/multi-threaded environments, but in the stateless/sync environment of a web application environment, they collapse down to syntactical sugar, and solve nothing that cannot be solved in other ways.

The software industry has, by and large, been working around the absence of closures for years....I certainly wont argue that it is better because of it, but to claim that PHP has been seriously crippled by the absence of closures over the years is to entirely overlook and understate the multitude of other problems its users have had to overcome.

<comment><USER13> "I am simply arguing that the most important thing in a project is the quality of the developers, not the language they chose"

I agree with the first part, but I think the language choice is integral to just how good those good developers can be.

I don't believe for a minute that a great developer can develop in PHP without being seriously crippled by it.

Functional programming has a tremendous amount of value outside of async/multi-threaded environments that cannot simply be replaced by other means. There are real limits to the amount of modularity one can achieve without functional programming, and modularity is key to great programming. I'd point you again to this paper: <http://news.ycombinator.com/item?id=1482797>

The state and history of the software industry at large only demonstrates that the majority of software developers in key technical positions within the industry are and have been less than great.

But if your argument is that PHP is "good enough" given a bunch of average developers... well then, yes, probably. Certainly plenty of good software has been written in PHP. I'd just argue that with the right developers it's far less than optimal, and that the choice of language could easily be the difference between the success and failure of a complex project.

<comment><USER14> "Functional programming has a tremendous amount of value outside of async/multi-threaded environments that cannot simply be replaced by other means."

Functional programming, or closures? I said: "Closures in particular are a very powerful tool in async/multi-threaded environments, but in the stateless/sync environment of a web application environment, they collapse down to syntactical sugar, and solve nothing that cannot be solved in other ways."

I made absolutely no statement regarding functional programming in general, and the label 'functional programming' applies to a much broader set of topics than just closures, so I am entirely at a loss as to why you think it makes sense to 'rebut' my statement about closures with something about functional programming?

"There are real limits to the amount of modularity one can achieve without functional programming, and modularity is key to great programming."

I entirely agree, modularity is good.

"The state and history of the software industry at large only demonstrates that the majority of software developers in key technical positions within the industry are and have been less than great."

indeed.

"But if your argument is that PHP is "good enough" given a bunch of average developers..."

LOL.

It _really_ wasn't.

Im glad you like functional languages and closures, you really should check out Scheme - its even MORE functional than Python.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> Repeat after me: it does NOT matter. It does NOT matter. It does NOT matter. Choose the one you are most comfortable with.

<comment><USER29> it does NOT matter. It does NOT matter. It does NOT matter.

</comment></comment><comment><USER30> If you know PHP and CodeIgniter well, and don't know Python very well, then it will take it longer to write in Python.

If you move to something like Tornado (python), Twisted (python) or node.js (javascript) then you might be able to get more performance out of your app, but really only if think moving to that level of complexity is necessary for you app.

In general, it's best to go with what you know. Yahoo! uses a lot of PHP as does Facebook. Since you mentioned CodeIgniter specifically, you're already well down the path of using a framework that allows you to write modular and reusable code with PHP.

</comment><comment><USER31> Just use what your team knows better. Period.

There are enough implementations of both languages in the real world (YouTube - Python, Yahoo/Facebook - PHP)

</comment><comment><USER32> It entirely comes down to who knows it (so when you hire, what type of people you get).

PHP has a lower skilled mean programmer who does it. This is not necessarily a bad thing if cheaper programmer is better than better programmer for your company.

PHP is easier to get going, python has more compelling libraries once you do. Python libraries are often better maintained than their PHP brethren, and the debugging stack for python is much more compelling.

</comment><comment><USER33> Python for more modular code.

Python for maintainable code.

Python for better libraries.

Python for Google App Engine and .NET

Python because of a cleaner grammar and better syntax.

Python for you.

</comment><comment><USER34> Use what you're good at. If you're good at neither, it's time to find another day job.

</comment><comment><USER35> Use Python + Django hosted on Google App engine It will remove all your worries of paying any thing unless you get million hits per month!

<comment><USER36> I concur. Also you will be disciplined into writing scalable code and will not have to deal with operating system issues, setting up servers, configuring db's etc., so you can focus on programming.

(If you want an invite to Fosdev for trying out GAE quickly, let me know.)</comment></comment>


Rust in production at Figma - <AUTHOR> https://blog.figma.com/rust-in-production-at-figma-e10a0ec31929 <comment><USER2> On the topic of Rust in production, game studio Chucklefish (makers of Starbound) are developing a cross-platform (including Xbox/PS4/Switch) game in Rust, and recently released a whitepaper: [https://www.rust- lang.org/pdfs/Rust-Chucklefish-Whitepaper.p...](https://www.rust- lang.org/pdfs/Rust-Chucklefish-Whitepaper.pdf) , and last year did an AMA with more technical details: [https://www.reddit.com/r/rust/comments/78bowa/hey_this_is_ky...](https://www.reddit.com/r/rust/comments/78bowa/hey_this_is_kyren_from_chucklefish_we_make_and/)

EDIT: Quote from the OP:

 _> One of them is called `error-chain` and another one is called `failure`. We didn't realize these existed and we aren't sure if there's a standard approach._

`error-chain` is in maintenance mode these days; `failure` is its spiritual successor and seems that it's on the path to becoming a community standard eventually.

<comment><USER3> That looks more like a very short pdf with a white background than a 'whitepaper'.

<comment><USER4> I'm not sure what you mean - this looks like a very conventional whitepaper to me.

Wikipedia says

> In business, a white paper is closer [than the government meaning of a > policy document] to a form of marketing presentation, a tool meant to > persuade customers and partners and promote a product or viewpoint.

<comment><USER5> Much of what I've done professionally over the past decade was to produce white papers in the following sense:

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

</comment></comment></comment></comment><comment><USER6> Tangentially related, but if any of you work with designers or are yourselves designers, please give Figma a try. It is identical to Sketch in so many ways, better in some others (particularly editing vectors and dealing with nested "symbols" or other components), and only falls behind in a few areas. If any of you have had to deal with the nightmare of keeping your design files in sync between designers forgetting to push changes to dropbox or InVision, or multiple designers working together and having their changes fall out of sync, the ability to edit and view the same document together cannot be overstated.

<comment><USER7> Are you related to the company?

<comment><USER6> No relation, I just really like it.

</comment></comment></comment><comment><USER8> _> We chose Rust for this rewrite because it combines best-in-class speed with low resource usage while still offering the safety of standard server languages. Low resource usage was particularly important to us because some of the performance issues with the old server were caused by the garbage collector._

Reading between the lines here, they didn't go with a more mature language like Java because they were worried GC tuning would be a problem?

Given all the other issues they noted with using a less mature language like Rust in production, that's a pretty heavy load to take on in exchange for not having to tune GC. Isn't GC tuning a fairly well understood problem? Is there something about encoding large documents that makes it a _significantly_ greater obstacle?

Or are there other unstated considerations at play here? For example, I mean this completely earnestly and not cynically, but there is a lot more PR and recruitment value in blogging about a hot new cutting-edge language than "how we rewrote our TypeScript server in Java".

<comment><USER9> Language maturity is not a one-dimensional problem and it's also not equal to the age of the language.

To name just two ways in which I consider Rust more mature than Java:

* It has a lot of fundamentals that are based on more academic languages which have explored some specific PLT space for a long time and let it mature. The fruits of that are now in Rust (many aspects of its type system for example).

* Rust's community has an almost absurd ability (contrasted with most other languages) to focus on specific core libraries and tooling. For example serde[1], _the_ Rust serialization library, is well-understood, simple, mature and supported in basically every Rust library out there.

The second point is extremely impressive when contrasted with the state of things in Java-land, where you often have many different solutions for the same problems. Sometimes even the well-known and used ones are of _very_ questionable quality[2].

[1]: [https://serde.rs/](https://serde.rs/) [2]: [https://github.com/FasterXML/jackson- databind/pull/1423](https://github.com/FasterXML/jackson-databind/pull/1423)

<comment><USER10> Jackson's status as the de facto Java standard for reading and writing JSON really reflects poorly on the Java community. Too often the biggest, hairiest solutions get anointed as the safe "best practices" choice for all new development when really they should only be used if you know specific reasons why they will pull their weight relative to simpler solutions. Jackson is an 800lb gorilla with an impressive arsenal of features, but there's no way in hell it should be the default choice for a simple greenfield CRUD application.

<comment><USER8> Without turning this into a long tangent subthread.. could you point to some support for this? The comparisons I've seen are more nuanced.[1]

[1] [https://blog.takipi.com/the-ultimate-json-library-json- simpl...](https://blog.takipi.com/the-ultimate-json-library-json-simple-vs- gson-vs-jackson-vs-json/)

<comment><USER10> That's a performance comparison that ignores all other aspects such as simplicity, readability, and ease of maintenance. It also shows Jackson coming in last for parsing small files.

</comment></comment></comment></comment></comment><comment><USER11> Interesting:

"Instead of going all-in on Rust, we decided to keep the network handling in node.js for now. The node.js process creates a separate Rust child process per document and communicates with it using a message-based protocol over stdin and stdout. All network traffic is passed between processes using these messages."

<comment><USER12> Yeah, waiting for Rust's async/await to mature is probably a good idea. But I'm not sure why they didn't just use threaded I/O instead.

<comment><USER11> Sounds like they use processes for fault isolation.

</comment></comment></comment><comment><USER13> I'm curious to know if they ever looked at [https://github.com/Microsoft/napajs](https://github.com/Microsoft/napajs) from Microsoft or any other in-nodejs solutions to deal with the need for multithreading vs launching multiple processes...

</comment><comment><USER14> That's a really good review of rust. Especially of async side.

</comment><comment><USER15> I look forward to using rust, but will probably wait a few more years for the language to mature. Interested in seeing what it will become!

</comment><comment><USER16> Man, is that "cons" section ever terrifying.

<comment><USER17> Honestly, it's pretty encouraging. All of the problems they listed are things I see as being very nearly solved.

For example, I ran into the futures issues. Now I use nightly's async/await, and it's a massive improvement while still being early days.

I also use the Non Lexical Lifetimes feature, and see a lot of ergonomic wins there.

The other stuff is being worked through as well - Failure is coming along, and I hear good things. Libraries are always improving.

I would be a lot more terrified if these issues were surprising, or not being dealt with, or were extremely hard to fix without breaking the language, etc. Instead, it's a list of things I've run into and can even solve today with a few features.

</comment></comment><comment><USER18> What were the reasons you decided to go with a child_process model instead of wrapping you Rust in a Node native module?

</comment><comment><USER19> " each document lives exclusively on one specific worker"

Would decoupling the workers and the documents they work on not solve this problem? Granted this might be non trivial, but it might have solved the fundamental issue thats arguably more interesting.

<comment><USER20> Somebody has to be responsible for reconciling multiple workers' changes to a document and arriving at a consistent state. Sounds like they're probably doing it in memory within an application worker. You could imagine a solution where they move this to the storage layer and have multiple workers acquire locks to mutate it, but I'm not sure how that wouldn't just move the problem.

<comment><USER19> The part I did not get is why a worker was holding on to other files when it was working on a single doc. "Throwing more hardware at the problem wouldn't have solved this issue because a single slow operation would still lock up the worker for all files associated with that worker"

Admittedly, the blog is light on details here and I am unfamiliar with the product. With the re-write, they also just moved the problem to rust. So I think that your suggestion to move the problem to the storage layer could have been another viable solution.

<comment><USER20> They didn't do this before because the memory overhead of having a separate worker for each document would have made the infrastructure costs exorbitant, presumably (since you'd have to pay for whatever fixed overhead costs Node has). But the lower overhead of using a Rust process per doc instead of a JS process per doc has allowed them to move to that model.

<comment><USER19> There can be an M:N mapping - An update queue can be consumed by a fixed pool of workers that can lock a file and commit the update. This is crude but wont explode the number of workers.. if you have a hashing scheme for the worker pool and implement linear probing, you can achieve some degree of preference for the same worker. If their system was such that a worker maintains state for a bunch of docs, and persists them at checkpoints, while also being doing compute intensive tasks per document on a single threaded node instance, I would ask why it was designed like that in the first place.</comment></comment></comment></comment></comment>


The Brydge Pro+ keyboard adds a trackpad to your iPad Pro - <AUTHOR> https://appleinsider.com/articles/20/01/02/the-brydge-pro-keyboard-adds-a-trackpad-to-your-ipad-pro <comment><AUTHOR> I don't get it. The iPad Pro _is_ a touch device. I use an old Magic Keyboard with an iPad Pro 10.5 (2017) because the "smart" cover keyboard I got from Logitech with that "magic" connector is flimsy and doesn't always work right (fails to power-on frequently). For touch interaction, the iPad screen is close enough that a touchpad seems both redundant and only marginally faster than just touching the screen. I use the protection case and stand from the Logitech keyboard case, but it's much nicer to have the keyboard and display separate so that they can be adjusted and setup individually depending on position: sitting, lying, standing, etc.</comment>


Show HN: Joomla Framework - <AUTHOR> http://framework.joomla.org/

<comment><USER2> Joomla always felt extremely backwards to me and this is no exception. Just look at the sample app:

The router tells me nothing about what routes exist [https://github.com/dbhurley/framework- app/blob/master/App/Ro...](https://github.com/dbhurley/framework- app/blob/master/App/Router/AppRouter.php)

This controller tells me nothing about what actions exist or what they do - and what sane invocation point would call an `updateDatabase()` method on a controller? [https://github.com/dbhurley/framework- app/blob/master/App/Co...](https://github.com/dbhurley/framework- app/blob/master/App/Controller/DashboardController.php)

This doesn't actually show me any markup [https://github.com/dbhurley/framework- app/blob/master/App/Vi...](https://github.com/dbhurley/framework- app/blob/master/App/View/Dashboard/DashboardHtmlView.php)

And so on. There's just pervasive implementation noise everywhere and nothing in the code that tells me anything about the business logic.</comment>


Google Gives $5 Million to Drone Program That Will Track Poachers - <AUTHOR> http://www.theatlantic.com/technology/archive/2012/12/google-gives-5-million-to-drone-program-that-will-track-poachers/266133/

<comment><USER2> This is old news, already heavily discussed ~2 months ago here:

<https://news.ycombinator.com/item?id=4935623>

<comment><USER3> It was the featured article in Reddit Today I Learned subreddit: <http://www.reddit.com/r/todayilearned/>

Probably the author just got the idea from there and shared it here.

</comment></comment><comment><USER4> There is one worry that I have: In this age, where hacking is so dominant, and not even the most secure places are completely secure. I don't reckon that these drones would have same level of cyber security, as military drones have, and even those were vulnerable (remember how Iran got one). So, if the poachers hire a exploit of this system, the animals would not be able to exercise their natural defense, i.e currently, poachers depend on a lot of tracking maneuvers, but still they don't know where the animal is actually.

If by chance, they get someone skilled to hack the drone system's communication system only, (and they can afford it, given how big this whole thing is) , they can poach with point-blank accuracy :(

I hope, google would provide them not just a secure system, but, also one that they can't profitably exploit through a hacker.

</comment><comment><USER5> again?

</comment><comment><USER6> Good idea! Lets make the Africans who manually track poachers jobless!

<comment><USER7> Have you been to the kruger park? Do you have any idea how big it is? It's impossible to cover such areas on foot and poachers can move even by helicopters. Also if it continues like that, we'll be out of rhinos at some point soon, so no guards at all (and no tourists either)

<comment><USER6> So use helicopters aswell?</comment></comment></comment>


Multiple issue and pull request templates - <AUTHOR> https://github.com/blog/2495-multiple-issue-and-pull-request-templates <comment><USER2> interesting to see GitHub catching up to features in GitLab...

[https://gitlab.com/help/user/project/description_templates.m...](https://gitlab.com/help/user/project/description_templates.md)

;)

</comment><comment><USER3> They should definitely consider an extra <select> field for the generic one, with the names of the issue types on then. And one pre-selected when going from a specific one.

How to change from bug issue template to normal issue template or for feature request? Changing the URL manually is not going to cut it, and the interface looks like the generic one for issues so users would expect going back to issues => new is going to be the same.

IMHO this could have been so good and useful, but they messed up the implementation details...

Note/Edit: I didn't look at Gitlab's implementation before comenting this, but now that I saw it that is _exactly_ what I imagined/described here!

<comment><AUTHOR> A switcher is under consideration but we're focused on some other (what we believe are) more important aspects right now and wanted to get this part out the door quickly for people to start using.

I wouldn't consider a switcher implementation details as much as another user flow.

Since you bring it up I wonder how often users find that switcher and "do the right thing" in GitLab. I would expect that number is pretty low and instead users submit with the template they arrived on. As in I would assume the feature is likely useful for advanced users to more easily switch (certainly good there) but I'm skeptical that new users would look to use this. What do you think?

</comment></comment><comment><USER4> Great! It'd be useful to automatically apply a label (e.g "bug") for a certain issue template.

</comment><comment><USER5> +1

Default: /ISSUE_TEMPLATE.md

/ISSUE_TEMPLATE/<name>.md

Default: /PULL_REQUEST_TEMPLATE.md

/PULL_REQUEST_TEMPLATE/<name>.md

<comment><AUTHOR> You can leave the last S for off (for savings) if you want /ISSUE_TEMPLATE(S)/ or /PULL_REQUEST_TEMPLATE(S)/

<comment><USER5> Good call. I've updated the post.</comment></comment></comment>


Research Team Engineers a Better Plastic-Degrading Enzyme - <AUTHOR> https://www.nrel.gov/news/press/2018/research-team-engineers-a-better-plastic-degrading-enzyme.html <comment><USER2> I'm a little uncomfortable with the use of the word 'evolved' in connection with the enzyme. Its an expression of something else's DNA, the other thing evolved, to express this enzyme, which because it had selective advantage, made it a functional evolutionary path. The way its used in the article, its like the enzyme did it, by itself. I don't think thats quite it for me.

Also, I like these kinds of articles, but I always find myself thinking about every other time somebody had a breakthrough and how rarely we get told about the dead-ends. We need to be reminded of the negative result outcomes.</comment>


An Ode to a 'Poor Black Kid' I Never Knew: How Forbes Gets Poverty Wrong - <AUTHOR> http://www.good.is/post/an-ode-to-a-poor-black-kid-i-never-knew-how-forbes-gets-it-wrong/ <comment><USER2> Having started at the (US) 99th percentile and having luckily risen to the 2nd percentile, I'll say that the most difficult part was learning 'the language' of the middle class. By language, I mean all the nuanced understandings, cultural concepts, non-verbal stuff that is impossible to gain without being in it. And, as an adult I'm still learning.

One example that I've recently become frighteningly aware of is that I have a vastly different understanding of what 'property' means than those who came from middle class US cultures. It's taken many years for me to understand this because in fact I know and understand the English definition of property as well as my counterparts. But, there are subtle differences in meaning that fundamentally filter my perspective. For instance, I never understood why my college friends became upset when I borrowed things and never returned them, nor why they thought it bizzare that I'd tell them, of my stuff, to just keep it.

There are countless other examples. The article particularly makes me think of my adult friends and their relationships, in and out, rarely 'settling down' from an outsider view. But, just because they get divorced a lot and re- married, or cheat a lot, etc. It doesn't mean that their social conventions are any less valid than those of the middle class America. There are strong social consistencies and social language, unfortunately reinforcing.

My models are very different still, the semantics don't align right with my current environment, and today I have difficulty teaching my son the middle class way.

<comment><USER3> In the interest of learning the middle, and upper middle class's vocabulary I respectfully make the correction that you probably meant that you went from the 1st percentile, to the 98th (of income, I believe you imply).

I've seen my parents make a climb in socioeconomic "position" similar to yours, and I've found that much as you found one of the fundamental things that separate the "classes" is awareness of taboos, and even more importantly, when taboos can be violated! My observations seem to indicate that the level of "taboo observance" is distributed in a bell curve over the incomes.

<comment><USER2> Thanks for the correction. I used that twist of view to allude to and separate out the so-called '1%', of which appears to me to have a separate 'language' in itself.

</comment></comment></comment><comment><USER4> This article alludes to the "bee sting" theory of poverty (see [http://www.boston.com/bostonglobe/ideas/articles/2008/03/30/...](http://www.boston.com/bostonglobe/ideas/articles/2008/03/30/the_sting_of_poverty/?page=full) ).

That brings up an interesting question: in historical terms, the subject of this story is quite well-off; he's not always physically at risk, he has ready access to probably non-toxic food, he has shelter, etc. Over a long enough timeline, his life is pretty good. Even his home situation--mom is a prostitute, but he can't tell anyone lest the authorities separate them--is in all likelihood less common than it might have been centuries ago.

So if these conditions are so awful that we can't possibly expect people to improve without fixing said conditions, how do we explain historical economic growth. We're descended from people who had _really_ miserable lives: sleep in a cave, hope you can hunt or gather enough food to stay alive, go to sleep hungry more often than not, risk death by infection every time you get a cut that's more than skin deep, and reproduce through what any modern person would call serial rape. Beings that were physiologically human (basically us, but probably lactose intolerant) had to deal with all of those circumstances, and managed to bequeath to the next generation some slightly less miserable circumstances.

It comes back to the anthropic principle: if misery is a strong disincentive for progress, how did we progress to the point that we have leisure time to discuss this?

(I've asked the same question on Quora here: [http://www.quora.com/How-do- adherents-to-the-bee-sting-theor...](http://www.quora.com/How-do-adherents-to- the-bee-sting-theory-of-poverty-explain-historical-economic-growth) . I am very interested in the answers.)

<comment><USER5> _We're descended from people who had really miserable lives: sleep in a cave, hope you can hunt or gather enough food to stay alive, go to sleep hungry more often than not_

This is pure conjecture.

 _risk death by infection every time you get a cut that's more than skin deep_

Reasonable point, but nothing to hang your hat on - it's the same for many poor people today that have poor access to medicine

 _and reproduce through what any modern person would call serial rape._

And we're back to just making stuff up again to make it sound like people in poverty have it easy.

The poor black kid in the story doesn't have access to self-sufficiency that your hunter-gatherers had. Where are the animals he can hunt? Where is the food he can simply gather? He has markedly different restrictions on his life, but you're ignoring all that to try and paint him as wealthy compared to "ye olde ignorant savage"

<comment><USER6> I believe his point was that it should be possible for <hardship-experiencing- people> to gradually improve their living conditions even despite their hardships.

<comment><USER7> I think he(and maybe you) underestimate how bad it is. Just because your shitty situation gradually improves, it doesn't make it a good situation, it makes it a slightly better shitty situation.

<comment><USER6> Yes, but the gradual improvement might have been happening over a long period already, and as a result, the situation wouldn't be bad anymore.

<comment><USER7> again, underestimating how shitty things are. going from property to turning tricks is a huge step up.

</comment></comment></comment></comment></comment></comment><comment><USER8> Fantastic read.

Being an aspiring entrepreneur, I tend to look to others that have made it, and see what I can learn from them. I became fascinated with biographies autobiographies of everyone from Richard Branson and Steve Jobs to Lance Armstrong to Anthony Kedis (red hot chili peppers). The single best one of them I've read is "From Pieces to Weight" by 50 cent. It written so well that you don't just understand why he made the decisions he did (becoming a drug dealer) you understand that you would have very likely make the same decisions, should you have been in his shoes. It really opens up another perspective on an individuals behavior, and has made me that much less quick to judge.

</comment><comment><USER9> Although I agree that the original post was naive, I do not think that the misleading vividness and hasty generalization employed by Jefferson addresses the issue to which the OP was referring. There is massive hardship across all low income families but the use an outlier scenario does not negate the valid argument that having goals and knowing that there is a prize to win at the end of the race, is a strong motivator.

I inferred that a lack of hope and knowledge of an achievable future, is one of the primary causes of lower performing low income students.

<comment><USER10> > misleading vividness

what?

> hasty generalization

there are no generalizations here. the article says that the author of the forbes article (as well as you), as a person or privilege, does not understand poverty and thus has no idea how to solve the problem. if anyone is making "hasty generalizations", its the author of the forbes article, who thinks that poor kids simply aren't trying hard enough.

> the use an outlier scenario

how do you know this is an outlier scenario?

> having goals and knowing that there is a prize to win at the end of the > race, is a strong motivator

i doubt anyone would disagree with this statement, but it's irrelevant.

the original forbes article suggests that having goals and determination are sufficient for escaping poverty. this article makes the argument that even with goals and determination, escaping poverty is still extremely difficult; furthermore, the very condition of poverty undermines the ability to develop goals and determination.

<comment><USER11> I think it is pretty safe to say that _"acts out in school to get suspensions to stop your mother from being a prostitute"_ is an outlier.

I acted out in primary school. I did it because I was an asshole who didn't respect education. I suspect my peers were the same.

<comment><USER12> Just for reference, since you're now directly comparing two schools (yours and the one in the linked article) here, how would you characterize the similarities or differences between your school and one described as

"a primarily low-income, high-minority middle school serving sixth- through eighth-graders"?

<comment><USER11> Yeah, that sounds about like my school.

However, I find it very hard to believe that _any_ school in the world can attribute most of it's student unruliness to children trying to get kicked out so that their mothers cannot be prostitutes.

</comment></comment></comment></comment></comment><comment><USER13> My mother and grandmother have devoted their lives to outreach to the low- income community. From what they have told me, "poverty" is not at the heart of this issue. Most of these parents have self-destructive habits which will persist regardless of the degree of social engineering thrown at the problem. The only thing that will save children like the one in the article is one-on- one support from caring individuals around him.

</comment><comment><USER14> The Gene Marks article is breathtakingly out of touch. He really ought to get to know some seriously poor people. Perhaps live among them for a time.

</comment><comment><USER15> At least this kid tried to gain some perspective before writing about it - <http://scratchbeginnings.com/>

</comment><comment><USER16> Is it off topic to wonder how the story of the badly behaved boy and his mother ended? Presumably with the police involved, they got separated and she was "protected" even more, albeit deprived of a livelihood. Maybe in another era, the consensus was that sex work was such a great job that legal penalties were needed to disincentivize it or there wouldn't be enough women left to be wives and housekeepers. In these more enlightened times, we consider it such a horrible job that anyone who would do it must be crazy or coerced, and needs to be shown that there are alternatives, but we retain the legal penalties in case we're not sure.

</comment><comment><USER17> Learning requires only access to education and a stable living environment... and then of course actually doing it.

Internet has mostly taken care of access to education. That leaves only living conditions and motivation as precursors to success.

<comment> guard-of-terra Motivation for grade hunting is a tricky thing. I don't understand where people are supposed to take that.

Boredom counter clicks like hell when near any education system featuring grades.

<comment><USER18> How does "education" equate to "grade system"? Are you mistaking credentials for education?

</comment></comment></comment><comment><USER19> To be honest, I don't know that this article is HN material (but I didn't flag it). That said, thank you for posting this. Poverty is not just something you can "The Secret" your way out of.

<comment><AUTHOR> There's a hazy line, but it gratifies my intellectual curiosity (as someone who is relatively ignorant of the subject) so I submitted it.

From: <http://ycombinator.com/newsguidelines.html>

What to Submit: Anything that good hackers would find interesting. That includes more than hacking and startups. If you had to reduce it to a sentence, the answer might be: _anything that gratifies one's intellectual curiosity._

</comment></comment><comment><USER20> At least of a few of the teachers outraged about Forbes will be working Google Scholar into their curricula because of the article.

</comment><comment><USER21> "How best to prioritize learning to read rigorously over scheming to get home and be the man of the house in the stead of the father who left? How best to find joy in school with so much hate and embitterment poisoning the rest of your life?"

How can we fix this? The problem is that no matter how much our teachers may push students to do better and work harder in school, their home life may work against it.

It's one of the side-effects of freedom. To some degree, there will never be a way to fix it. Unless we can control what happens when they get home.

<comment><USER22> You are bringing up the argument for Welfare, Universal Healthcare, etc., that there is nothing that the schools can do. The problems that these kids are facing stems from the fact that they live in poverty. This leads to issues such as the one mentioned by the author. The only way to solve the problem would be to try to figure out a decent Social Benefits system for the poor, to where poor parents do not feel the need to resort to prostitution, drugs, drinking, etc.

<comment><USER23> > try to figure out a decent Social Benefits system for the poor, to where > poor parents do not feel the need to resort to prostitution, drugs, > drinking, etc.

Why do you think that the lack of a "decent Social Benefits system" is the reason why they do prostitution, drugs, drinking?

To put it another way, you seem to be assuming that someone drinks because they're poor. Could it be (for some/many) that they're poor because they drink?</comment></comment></comment>