Ask HN: Setting up an open source project. - <AUTHOR>

We have a ton of projects at massify.com we've been itching to open source, but we're obviously a little short on time.  I'm wondering if anyone has actively participated or maintained an open source project and can help me answer some bullet points:
A. Has anyone ever started an open source project? B. Any recommendations for project hosting (github, sourceforge, google code, etc.) C. Tips on general project maintenance.
The biggest project is that we want to fork PHP.  I'm not sure what kind of nightmare that would be.  We have successfully been running a patched version of PHP that supports anonymous functions, closures and array shortcut notation.  I guess this might be a whole different topic?  Has anyone maintained a fork before?
Thanks for any input. <comment><USER2> We've got a couple of projects at SourceForge.net, and I have to agree with everyone else. It is slow, and it's interface has always been pretty clunky-- dealing with tickets and the forums is pretty horrible. I wouldn't use it today.

For our newer stuff, we handle it internally...but we have a slightly odd situation of having a commercial branch and a GPL branch, and the commercial branch is private. Open Source hosting places don't make that easy.

If I were starting a new project today, I'd try both github and Google Code and see which one I liked better, and then I'd go with it. git is really cool for highly distributed projects, but unnecessary for most projects with only a few developers--there are still some benefits, but if the Google Code tools work better for you, then the revision control choice probably doesn't matter enough to make a difference.

For one company I worked for a few years ago, we ended up building out a code hosting platform based on trac, Subversion, Mailman, Virtualmin to manage it all on the backend and grant project owners their own web space, etc. (SciPy.org is the result, and several Open Source Python scientific computing projects are hosted there. It works pretty well, or did when I last dealt with it about three years ago.)

Generally, it's more important to actually get the code out there than how you do it. Documentation is the hard part of the equation, and it's more important than you'd think. Your code will not be adopted without at least good documentation for installing it and getting it running. People will put up with a lot once it's installed and doing something productive for them...but if the install doesn't work, you've lost them, and they'll very likely complain about your software to others.

Forking a major project like PHP is dangerous mojo. I don't blame you...whenever I work in PHP, I feel like someone is stabbing me in the eye every time I have to create an array by typing "array(1, 2, 3, 4)" or try to do anything even a little clever. Have you talked to the PHP folks about possible inclusion in PHP 6? I mean, I know their mental model for software development is deeply flawed, and maybe they won't be eager to incorporate such dramatic changes, but if you could avoid a fork and still get the code out there, it'd be a win. Worst case, you should remain on friendly terms with the parent project--do not fork in anger, as it's bad for everyone involved. Do what you can to insure your bugfixes go back into mainline and that you follow their code very closely so that compatibility is maintained except in the specific areas where you diverge.

<comment><AUTHOR> Thanks for the download.

Re: forking. I'm not really involved in PHP internals beyond keeping an eye on it, but there have been some really brilliant patches by a single guy that keep getting rejected because they're not of the "PHP mindset". Honestly, I think their mindset is a little f'd up. The namespaces in PHP 6(5.3) are ugly as hell.

We wouldn't be forking in anger, we'd just be posting the latest PHP with patches that make it useful. Use it if you want, that sort of thing.

Anyways, thanks for the feedback.

<comment><USER3> I'd say that "of the PHP mindset" is quite possibly one of the worst insults you can give code.

</comment></comment></comment><comment><USER4> Google code is a good place to host. Very fast to get started and you get a very clean website with all the basic tools. Bug reporting is simple so your users will be happy too. It uses SVN but google give you the option to host your repository somewhere else if you dont like SVN. However Google allows only a restricted set of licenses so you need to check their list of supported licenses.

launchpad is also an ok place to host code (and it allows any license) but it doesnt host wikis for example and some of the UI elements are rather radical and may not suit your taste. if you host on launchpad, you will need to host a proper website and/or wiki somewhere else.

Dont go with sourceforge. The site has become slow and full of ads which cover half your screen. The interface is clunky too.

edit : launchpad uses bazaar a distributed VCS.

</comment><comment><USER5> I'd recommend github for source hosting. I've got multiple open source projects that I run or use that use github for scm and use lighthouseapp.com for ticketing. These are fairly large OSS projects with many many contributors and it works great. <http://github.com/wycats/merb-core/tree/master> and <http://github.com/evanphx/rubinius/tree/master> as well as a bunch of other smaller oss projects.

Both github and Lighthouse will give free accounts to open source projects.

</comment><comment><USER6> github is great for forking and the like, I'd go with that and lighthouse for tracking and google groups for a mailing list.

Or, you could just run your own git repo, trac, and mailman.

Just stay away from sourceforge.

<comment><USER7> See, I was going to mention SF. It seems to be becoming less and less popular these days. Why is that? Do you think it's become too big for its boots?

<comment><AUTHOR> My impression is that it's painfully slow and the UI is horrid. Six clicks to download a package and it's not very clear even then.

</comment></comment></comment><comment><USER8> At Polar Rose we simply started to put projects on Google Code. Some are well documented, others are mostly code dumps and need more attention. We use subversion internally and Maven for working with well defined (Java) components/libraries. So there is not much difference between working on code hosted in the public or private repositories.

The most difficult thing was actually not a technical thing but a mindset issue: To teach people in the teams how they can identify components that can be released as open source. And to actually do it.

</comment><comment><USER9> We have something on SF which we don't update often because of all the reasons you've read in other posts. The up-to-date code snapshot is hosted in-house on Subversion. Issues are tracked in-house with Mantis, user/developer mailing lists are run in-house with Pipermail, the code is built on the server with the help of Maven (since it's all Java, YMMV), and wikis hosted in-house with the help of Dokuwiki.

Why all the in-house stuff? Control, for one. We also ask for registration information before giving access to the source code. This comes around to lead generation when it's time to sell services (which is all the time).

Check it out: <http://www.openclinica.org/index.php>

</comment><comment><USER10> I have a question that is along the same lines, if we have a project that we want to open source and basically make money on service contracts what is the best open source license to go with?

<comment><USER9> LGPL, we went with it for our code and have been doing okay by it. The only trick is that we use a number of other OSS packages as well and we have to do an audit every once a quarter to make sure the licenses are all in line with ours.

</comment></comment><comment><USER11> I'm hosting some projects on my own box. It's a mix of svn and bzr repositories fronted by Trac.

Trac is awesome, but it doesn't really understand bzr branches and such, so linking to code from inside Trac is a little weird. If you'll be using DVCS, shop around for something more congruent.

Also, browsing a bzr repo from Trac is pretty slow.

</comment><comment><USER12> It would be best to package your PHP additions as an extension if you could, but I imagine you'd have done that already if it would work.

PHP on Ubuntu comes with the Suhosin patch installed, so there is at least one third-party PHP patch that has some significant distribution.

</comment><comment><USER13> i did work on an open source J2ME api(BIZU ME) and stopped when I started working full time. I can say that sourceforge is ok for hosting since that is what I used for hosting and had no problems what so ever. The UI is weird to deal with but its alright once u get used to it. I haven't tried any other such as google code etc so I cant give u any feedback on those.. You will probably need a bug tracking tool such as jira for tracking your issues. Jira is really good and offers a free licence if your project is open source. Apart from that , you will need weekly updates or else people lose interest pretty quickly!

</comment><comment><USER14> Trac is great, and I've used it a number of times, but if you are rolling your own platform then Redmine (www.redmine.org/) is worth considering as it is much nicer and easier to get started with.

</comment><comment><USER15> A big thumbs up for Github. I've got OSS and closed source projects in GH and I absolutely love it. Pull requests are the new patch ticket.</comment>


Ask HN: Want to experience Remote Work. How to? - <AUTHOR> I really want to experience remote working and want to meet with great people across the globe. But i actually don't know how to look or apply for a remote position. Applied to a few but didn't get any proper response.
Can you guys share your ideas and help me about working/applying,how to handle the time difference,the salary,the communication etc ?
PS : I'm a pragmatic software dev mostly experienced with JS/CS/Node/Ruby/Rails. If you need a nice guy please contact me. <comment><USER2> For the World

1) Think about a project that you would love to work for.

2) Now search a FOSS equivalent of that project on privatelee.com or google

3) Read the contribution & coding guidelines, setup your IDE/Editor accordingly

4) Fork the project and start contributing, connect to the core developers through their prefferd medium. IRC/Mailing-Lists/Forums or plain Email.

5) Credits & Honor.

For a Company

1) Ask yourself what you want to change in the world, if you had power & money. Think about it seriously and flabbergast yourself, by finding out what you really wanted to do all your life.

2) Hunt companies actually doing that on privatelee.com or google

3) This will be the first time you can be really honest about why you want to work for this company. Keep that in mind when you're writing your job application. Send it by Email and add tracking to it, so you can see, if and how companies read your CV etc.

4) Wait for a response for 4 days and remind the person, cc another responsible person. You can hunt anyone's email address easily online.

5) Be yourself in your job interview. Easy. You always wanted to do that and it's your dream. Everybody wants YOU in their company. For me it wouldn't matter if such a candidate had failed school or not, when he had the skills and intrinsic motivation to help the company go forward.

6) $$$

<comment><AUTHOR> Hey thanks. Great points. So you advise to look for companies without using any job / referral site and contact them directly ?

<comment><USER2> Absolutely! I had success doing just that.

</comment></comment></comment><comment><USER3> Working: Find a company that won't micromanage you, and will trust you to get shit done.

Applying: Same as any other job. Make sure to stress that you can manage your own workload and communicate well.

Communication: Mainly Skype and email.

Salary: Same as any other job. Don't take a pay cut to work remotely -- you're still doing just as much work.

Time difference: Most companies have "core hours" where everyone needs to be available. They should be flexible otherwise, if you want to start later or earlier.

In terms of finding gigs, Careers.StackOverflow and WhoIsHiring will be your best bets.

<comment><AUTHOR> Hey thanks for the great points. But isn't salary relative to the location of the company?

<comment><USER3> It depends. If the company is in SF, they'll either pay you an SF salary, or a salary relative to where you're working from (see Buffer's ad in WhoIsHiring). But more abstractly: don't take a salary you won't be happy with.

<comment><AUTHOR> Which one is better hourly or a normal salary?

<comment><USER3> With hourly (as a contractor) your taxes will be more complicated, and you may get stuck with less benefits. Salaried, your income is more predictable, and generally works the same as it would if you were working "normally."

It really depends whether you want to work remotely long term or short term.</comment></comment></comment></comment></comment>


Find out what is new from iDealyzer - <AUTHOR> http://getidealyzer.com/coming_soon

<comment><AUTHOR> Can a coming soon page for new features of an existing product go viral?</comment>


The Fugate family of Kentucky has had blue skin for centuries - <AUTHOR> https://allthatsinteresting.com/fugate-family-blue-people-of-kentucky <comment><USER2> A fascinating article, but it's a bit frustrating that there are no colour photos. I tried searching the internet and found photos of other blue-skinned people but none of them had this genetic cause (mostly it was silver "supplements").

<comment><USER3> [https://historycollection.co/the-fugate-family-of- kentucky-h...](https://historycollection.co/the-fugate-family-of-kentucky-had- blue-skin-for-generations/3/)

<comment><USER4> Don't visit that site if you value your scrollbar or browser history...

<comment><USER5> I was curious why and tapped it.

It spams back button history so quickly that you cannot return to HN anymore. Open in new tab if interested.

<comment><USER6> Doesn't seem to do anything on IPhone's safari.

</comment></comment></comment></comment></comment><comment><USER7> > The Blue Fugates are shown in this colorized black and white photo. Date > unspecified. Original source unknown, via ABC News

It's somewhat dishonest to illustrate an article on color with a photo that was colorized by someone we don't know at an unknow date-- i.e. we don't know anything about how they decided which shade of blue to apply on their faces. So the only interesting information caried by the photo, the shade of the blue color, has no source.

Also, this appears to be largely copied from this ABC News article: [https://abcnews.go.com/Health/blue-skinned-people- kentucky-r...](https://abcnews.go.com/Health/blue-skinned-people-kentucky- reveal-todays-genetic-lesson/story?id=15759819)

<comment><USER8> The main reason people turn blueish is because of excessive colloidal silver usage. I expect it is the case for the family in this phony story.

<comment><USER9> Did you read the story?

<comment><USER8> I read it but I think the reasoning might be wrong.

</comment></comment></comment></comment><comment><USER10> The diagram explaining recessive genes uses blue for unaffected and red for affected. In an article about recessive genes for blue skin...

<comment><USER11> Maybe it is using the same effect as "Hard-to-Read Fonts Promote Better Recall"

[https://hbr.org/2012/03/hard-to-read-fonts-promote-better- re...](https://hbr.org/2012/03/hard-to-read-fonts-promote-better-recall)

<comment><USER12> You're too kind

</comment></comment></comment><comment><USER13> It's possible I saw a member of the Fugate family back in the '80s. I grew up in West Virginia, not terribly far from the Kentucky state line. An older woman, perhaps in her seventies, was shopping in a local grocery store. I was old enough to know not to stare, but I wanted to, and couldn't help but do a sly double-take. She was bluish. No other way to describe it. No one there to witness it ever seemed to believe me (not that I can blame them), but it was a few years later that I learned the name of the family and did some research. Photos of people who are doped with enough colloidal silver to cause argyria (I think that's right) always make me think of her, and I often wonder if that was really what I saw at the time.

</comment><comment><USER14> Some real gems in this article- "I'm kin to myself" and "she was as blue a woman as I ever saw" (how many blue people have you seen?)

<comment><USER15> I think that is meant in humour

<comment><USER16> Yeah, she's saying that they're the bluest person they've ever seen because they haven't seen any other blue people.

Source: My family comes from Harlan, KY and I have Fugate relatives.

</comment></comment></comment><comment><USER17> My mom developed blue skin in reaction to a medication she was taking.

The doctor was so interested in her body's response he brought her in front of this university medical class. Apparently it's quite rare. It went away a week or so later.

(cant remember the name of the medication but it was certainly not a listed side effect).

<comment><USER18> I think there was an article last week the mentioned a rare side effect of benzocaine turning blood blue. Found it: [https://www.nbcnews.com/health/health-news/common-numbing- me...](https://www.nbcnews.com/health/health-news/common-numbing-medication- turned-woman-s-blood-blue-n1055991)

</comment></comment><comment><USER19> > _The Fugates he treated ingested this dye and within a few minutes, the blue > coloration of their skin disappeared, and their skin turned pink._

Really? Within a few minutes??

Nitpick aside, such an interesting article! The world is such a big and interesting place!

<comment><USER20> More amazing (to me) was that a doctor actually solved this problem effectively. A few times that I went to doctors with minor problems in the last decade, they usually had no clue what's wrong (they even admitted it), but prescribed antibiotics.

<comment><USER21> I imagine the biggest challenge your doctors faced was diagnosis.

It's a lot easier to treat someone when you can diagnose them at a glance.

<comment><USER20> Blue skin is a symptom, not a diagnosis. I doubt the doctor who saw him could immediately diagnose it, however he didn't give up and cracked that case eventually (and even found the cure!)

<comment><USER21> Well yeah. I was simplifying a bit.

The doctor would have to do a bit of research, but being such a rare symptom, achieving a diagnosis for blue skin would be much easier than reaching a single diagnosis from something like chest pain.

</comment></comment></comment></comment></comment><comment><USER22> Are we going to talk about the absolutely ridiculous amount of ads in this article?

<comment><USER23> My blocker reported that it had blocked 118 items. I'd rather not know what that looks like.

</comment></comment><comment><USER24> Weird. I worked with a guy once whose parents believed colloidal silver would cure him of his ADD. Instead he turned blue.

<comment><USER25> That's terrible because, if I remember correctly, that's permanent. :/

<comment><USER26> You remember correctly.

[https://nccih.nih.gov/health/colloidalsilver](https://nccih.nih.gov/health/colloidalsilver)

</comment></comment></comment><comment><USER27> This is fascinating. Krsna in the Indian epic Mahabharata is similarly blue in color.

<comment><USER28> He's dark skinned. Not really blue. His depiction as blue skinned is more symbolic

<comment><USER29> So he's blue-skinned.

Or are you implying he exists or existed for real independent of people's psychotic heads?

<comment><USER28> All the written source material about him implies that he is dark skinned.

Visual representations of him show him as blue for other reasons (mainly the comical stigma against dark skin).

</comment></comment></comment></comment><comment><USER30> If you want to see photos of that condition, search Google images for "methemoglobinemia": [https://tinyurl.com/y6ct4ye3](https://tinyurl.com/y6ct4ye3)

</comment><comment><USER31> That image from wikicommons showing how recessive genes are inherited but the affected person is red and the unaffected is blue.

I know the blue person in the image is not related to the article but it's interesting how the article is about blue people yet the "affected" result is shown as red.

</comment><comment><USER32> Once I donated blood and it came out green! Everyone was astonished. No idea why to this day, any ideas? Blood is back to its normal red color. Wasn't taking any medications or feeling ill.

<comment><USER33> I believe sulfates in the blood can cause it to turn green.

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

<comment><USER32> Thanks! I wonder what caused my sulfates to rise. Maybe something I ate, or an infection without symptoms that I noticed. Or perhaps I did take a medication and I don't remember. Or just something genetic.

Thanks for sharing, because it looks like it's not something I need to worry about because my blood quickly went back to red.

</comment></comment></comment><comment><USER34> Methemoglobinemia seems to be a popular medical topic lately. It's an easily treatable disease, usually methylene blue is used, and it's more an inconvenience than anything else.

<comment><USER35> I don't know if I'd call the inability for your blood to transport oxygen merely inconvenient.

<comment><USER34> It's inconvenient because of how treatable it is with modern medicine.

</comment></comment></comment><comment><USER36> For all the people looking for color photos, not of these specific people but at least to give an idea, You can do an image search for "Methemoglobinemia" which is what the condition is called. Turns out people who have it are _rather_ blue. Bluer than in the colorized photo in my opinion.

</comment><comment><USER37> The travel channel did a segment on this a few years back: [https://www.youtube.com/watch?v=7d-07Ced410](https://www.youtube.com/watch?v=7d-07Ced410)

</comment><comment><USER38> > the tint still comes out in their skin when they are cold or flush with > anger.

It's a bit hard to admit, but I'm really disappointed there isn't a picture of this.

</comment><comment><USER39> This is about as credible as a press release from [name of a prominent engineering school redacted]. There is no evidence of any blueness in the pictures.

</comment><comment><USER29> Ashamed of it and ridiculed?

I would have tought of it a fascinating and fashionable! Especially with white hair. Man, I want that when I am old!

And yeah, their ancestors might have been incestous. But that isn't the childrens' fault, now is it.

Man, … people somtimes.

</comment><comment><USER40> There is a much simpler explanation for that, silver in water. I assume that all the case is environmentally, not genetically related, or that the history is just fake.

</comment><comment><USER41> Why was the color blue chosen by evolution?

<comment><USER42> That's not how evolution works... random variation, sometimes detrimental, will sometimes lead to advantage

<comment><USER43> Sometimes both. Sickle cell anemia gives you slightly better odds of surviving malaria for instance.

<comment><USER44> Sickle cell anemia is Mendelian and recessive. So if 2 carriers (Rr and Rr) have kids, 50% of the children will be strictly superior (carriers), 25% will be normal, and 25% will die young. Not a bad outcome, especially if you have a lot of kids to reduce the variance.

<comment><USER45> > 50% of the children will be strictly superior (carriers)

Is that domain nomenclature? Because I wouldn't call having to be careful who procreate with otherwise risk losing 25% of my children from that relationship as "strictly superior"...

<comment><USER46> 2/4 resistant to malaria with no side effects and 1/4 dying is much much better than 4/4 dying from malaria

<comment><USER47> pretty good considering something like half of all human beings who ever lived died of Malaria!

<comment><USER48> I am mildly disappointed to learn that this is probably an overestimate, although it is pretty significant [http://factmyth.com/factoids/malaria- killed-half-the-people-...](http://factmyth.com/factoids/malaria-killed-half- the-people-who-have-ever-lived/)

<comment><USER47> Thanks for calling it out! I think I first heard this from Plasmodium researchers, and in my mind the claim has strengthen over time. A better statement would be: ""Malaria could have potentially killed nearly to half the people who ever lived, predominantly children"."

And this is based off the idea that for most of human history people have lived in Sub-Saharan Africa, where the majority of people who lived died as children, and the predominate cause of death was Malaria.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER49> I'm not convinced this is the real deal. Change my mind?

<comment><USER50> You think it's a bogus article? Look through the reference list here: [https://en.wikipedia.org/wiki/Blue_Fugates](https://en.wikipedia.org/wiki/Blue_Fugates)

<comment><USER49> Wow, I'm convinced now. The colorized photo made me suspicious.

</comment></comment></comment><comment><USER51> Is this article a carnival sideshow? "<Family/Individual> had <unusual genetic disease you're unlikely to ever encounter> that caused <visible differences from other humans>"

I get it, we like to look at situations where people are different, but does this actually inform, educate, or improve us by reading? Or is this article just a chance to point out some people who are different.

I've been thinking about this recently, and trying to moderate my curiosity (because blue skin certainly piques my curiosity) against what I'm trying to get out of the article and what the people in the article get out of the article. Is the Fugate's family improved by this? What about other people with methemoglobinemia? Are their lives improved?

Another way to think of it is, who benefits from this? Who is being put on display?

Edit: I ask because I think these are important questions to ask, and because I genuinely have a difficult time telling sometimes. It's useful to see responses of how others interpret this.

<comment><USER52> This article is biologically fascinating! It detailed the genetics and the biochemistry involved, but also included a rich history of those affected. It's a synthesis of things that interest us.

Alzheimer's, cancer, and other disease states are also hugely interesting. That's one of the reasons people study them (in addition to the desire to save and improve lives).

Human stories often intersect with biology. Henrietta Lacks and the HeLa cell line...

<comment><USER51> I think that this article might meet those criteria, I still think it's important to ask questions like this about articles like this. Because it really is a fine line between putting people on display (like we literally used to do when we kept other humans in zoos) and examining the various biological traits in humanity.

<comment><USER53> So you commented before reading it?

Your critical thinking would be more useful in any other article that you believe does not match that standard.

<comment><USER51> I've read the article. I commented after reading the article. I asked questions because I was curious how others would answer them. Because I had not reached conclusions to them myself.</comment></comment></comment></comment></comment>


In a Blast from a Financial Crisis Past, Synthetic CDOs Are Back - <AUTHOR> https://www.wsj.com/articles/in-a-blast-from-a-financial-crisis-past-synthetic-cdos-are-back-1503912601 <comment><USER2> CDOs helped to usher in the entire collapse of the economy in 2007. I find it hard to believe that the reemergence of these financial instruments which function largely in shadow banking are going to be a good thing long-term. It took several years for the previous CDOs to implode and did nothing but transfer monies from the middle class to those who could afford to bet on CDOs. If the same happens again, more will lose their retirements and the middle class will shrink even more.

More oversight may have been put in place but banks created instruments that were not regulated before and nothing will prevent them from creating more instruments that fall outside of the regulators reach. Finally, when you create instruments that bet on the dbt default, you are likely to achieve just that......default in large numbers. Without the success of CDOs the banks could not sell them and for them to be succesful, people must be defaulting on debt. It has been said that the next financial crisis will come from the higher incidence of default from car loans and from the burgeoning student loan default rates.

In my opinion, the increase interest and investment in CDOs spells economic trouble for all of us.</comment>


How to build $100m SaaS business - <AUTHOR> To build a $100m SaaS business go to market strategy is the key. Back in 2014 when we started, we never knew that there is a framework to look at Go-to-Market (GTM) strategically considering different factors like marketing, sales, product virality, etc.
Read the full post here - https://sesamint.substack.com/p/5-ways-to-build-100m-saas-business
All SaaS founders, VCs, and the community let's change the dialogue. Let's start chasing scooters, bikes, cars, campers, and buses. If possible let's chase the rockets too! <comment><USER2> > Read the full post here

Please submit the URL and title on [https://news.ycombinator.com/submit](https://news.ycombinator.com/submit)</comment>


What a typical 100% Serverless Architecture looks like in AWS - <AUTHOR> https://medium.com/serverless-transformation/40f252cd0ecb <comment><AUTHOR> I hope you will enjoy reading the article as much as I enjoyed writing it. Would love to chat about it and learn from your experiences so don't hesitate to reach me!</comment>


"The Best of edw519" is now free. Reverse Happy Birthday - <AUTHOR> http://edweissman.com/53640595

<comment><USER2> This is amazing stuff - thanks much!

I made a slightly more readable HTML version (with linked TOC and back links) here -> <http://bit.ly/lSLTVT>

This could be converted to an ePub I think, with the linked TOC. If this a problem let me know and I will take it down, or maybe you could post it on <http://edweissman.com/53640595> to get the linked TOC?

<comment><AUTHOR> Thank you hieronymusN. Much prettier than mine.

One problem though - you lost most of the paragraph formatting and spacing; you can see the difference on almost every entry if you look closely enough. Fix that and I'll just put your version on my blog.

[Once again: thank you everyone for the kind words and feedback. You made my day!]

<comment><USER2> Facepalm - you're right, my regexes got a little too aggressive. I've reposted it with the formatting intact.

I also posted a version as PDF - again it has the linked TOC which makes it easier to navigate. The PDF isn't as nice as the HTML though.

[PDF] <http://bit.ly/inAWAc>

<comment><USER3> Do you have code handy to convert from html (with a TOC) to epub?

I looked up some python examples to start with:

python epub docs [http://www.egofile.com/2010/01/convert-openofficeorg- writer-...](http://www.egofile.com/2010/01/convert-openofficeorg-writer-html- to-epub.html)

<http://code.google.com/p/python-epub-builder/>

[http://www.ibm.com/developerworks/xml/tutorials/x-epubtut/se...](http://www.ibm.com/developerworks/xml/tutorials/x-epubtut/section5.html)

<comment><USER2> [EPUB] <http://bit.ly/kQYAZQ>

I made this one with Calibre, and its optimized for the iPad. Let me know how it looks for you.

</comment></comment></comment></comment></comment><comment><USER4> > 87\. What got you "hooked"?

Loved this story, and I enjoy coding the more I do this.

The problem is to keep it focussed on "productive" output - otherwise you end up like that guy who wrote TeX instead of The Art of Computer Programming; or Blart Versenwald III¹; or

        6. It automatically classifies unread comments based upon similarity
        to classified comments and some rules. (The idea was to classify the
        first 300 comments and have the software classify the remaining
        3,700. I realized this capability was unnecessary when the book
        would only contain 256 entries. Oh well.)

Not to look this wonderful gift horse in the mouth ( _all_ the bits I looked into at random were actually great), but it would be nice if titles linked to their comments.

1\. _One of the greatest benefactors of all lifekind._ <http://www.cse.ohio- state.edu/~soundarm/book4.html>

<comment><AUTHOR> _...it would be nice if titles linked to their comments..._

I purposely omitted references to the original Hacker News threads because I wanted the book to stand on its own.

Hope this helps:

[http://edweissman.com/index-from-the-best-of-edw519-to- the-o...](http://edweissman.com/index-from-the-best-of-edw519-to-the-original)

[Many thanks to everyone in this thread for the well wishes. You guys are helping to make my day!]

<comment><USER4> Thanks! I actually meant links to the comments lower down on the same page (eg for clarity: _87\. What got you "hooked"? ... 87\. What got you "hooked"?_), and then people could link to specific entries - but I like your interpretation better.

[I had trouble expressing this in the GP, and went for over-conciseness, as "comment" is ambiguous. I still can't think of a brief but clear way to say it - there's probably some TeX typesetting terminology for it].

<comment><USER2> I agree - you can check a linked TOC version here <http://bit.ly/lSLTVT>

and [PDF] <http://bit.ly/inAWAc>

</comment></comment></comment></comment><comment><USER5> Happy birthday and thanks for the gift!

Edit: I tried to buy it, but Scribd won't allow me to do it because I'm not from US (and neither is my credit card). Is there any other alternative?

</comment><comment><USER6> Hope you are not angry with me for taking it through readability, saving it to pdf and converting it to mobi.

Wishing you a very happy birthday!

<comment><USER7> Could you possibly upload that? I'd love to read this on my Kindle.

<comment><USER6> Since I'm not sure what edw519 would think of _me_ sharing his work online, I did the less wrong thing. I'm pretty sure you've got mail.

<comment><AUTHOR> No problem. I'm kinda curious what it would look like, too.

Thanks for the interest and the well wishes, chanux.

<comment><USER8> I may mark this up in LaTeX, then, simply because I've never tried it on something this large. I'll share it here if that's alright with you, edw519.

Question for the peanut gallery - embedding images in LaTeX seems to suck. Any recommendations? (I'm using MacTeX 2010-basic)

<comment><AUTHOR> Cool. Thanks, whimsy.

(edw519, alumnus of Theta Chi, Beta Chi Chapter)

</comment></comment></comment></comment></comment></comment><comment><USER9> First of all, this is awesome. Thank you!

Secondly, I am reading through this and came across this:

 _14\. Should I still be a programmer?_ _"I lack the fundamentals of Computer Science, the things every programmer should know: Algo's, Data Structures, Operating Systems an understanding of compilers and being profficient with linux."_

 _Relax. That's true for 99% of all programmers._

I feel like I am in the same exact boat as the original poster. However, I am a senior in college who has several interviews lined up. I have interviewed several times before and always flop on the "fundamental questions". Is there any further advice someone can give me? Thanks in advanced.

<comment><USER10> "I have interviewed several times before and always flop on the 'fundamental questions'. Is there any further advice someone can give me? Thanks in advanced."

Have you considered learning the fundamentals? Its not a snarky comment I'm genuinely curious.

If you are programming, find you enjoy it, and wish to continue doing it for money, continuing education should be right up there on your list of things to do. (whether you have a Ph.D in CS or just a high school diploma, new stuff is coming out all the time).

There are a lot of free resources now online. You can get the syllabus and curriculum for classses that are taught in places like Stanford or MIT or UC Berkeley. So even if you spend the next two years of nights and weekends 'filling in the gaps' in your knowledge you will find that not only do you get better at your 'day job' but you will start aceing those 'fundamental' questions.

There was a time when to do this you would have to audit a class at a nearby university which imposed limits based on schedules, location, etc. But those times are behind us now. Take an old desktop machine from the e-waste dumpster behind some company, load up FreeBSD or Linux on it, and start doing the home work from some of these courses. The fundamentals are fundamentals because they apply universally, and you don't need a fancy rig to compare the performances of various sorts, or explore bloom filters, or key exchange algorithms. You can run MySQL on crappy hardware for the size databases you need to run to learn SQL.

Granted the assumption is that you can currently access the internet and you live somewhere that is currently consuming IT hardware (pretty much most of Europe, Asia, Australia, New Zealand. and the N. American continent).

If you are a 'Senior in college' and your major was CS and you flop the fundamental questions then there is a bigger problem here.

</comment></comment><comment><USER11> These pearls of wisdom are no less than PG's essays. What I find most impressive about his wisdom is that it had withstood the test of time....it's not just about finding the next big idea and executing it when you are 20/30 something and then do what? It goes much more deeper than that. It is about how to maintain genuine interest in programming, over a period, measured in decades(spanning all different type of envmts) and not years/months...To me that is the ultimate measure of success(for a hacker atleast).

</comment><comment><USER12> Any chance you can put this on the Kindle store? Not sure how easy it is, but I'm sure myself and many others would like to buy a Kindle copy :)

</comment><comment><USER13> Great! Was planning to buy it but couldn't do it because of scribd (tired of having services requiring US credit cards)... Happy birthday!

</comment><comment><USER14> Love it! Bought a copy too! IMHO you're the best commenter on HN edw519! :)

<comment><USER15> Maybe a silly question, but where can I buy it?

<comment><USER16> <http://www.scribd.com/doc/52729281/The-Best-Of-edw519>

<comment><USER17> Ah, this is annoying.

Selling is only allowed to people in the US? What on earth for?

I realize it's available free but I wanted to buy for the principle of the thing.

<comment><USER18> Just as a shot in the dark, I imagine there's probably a mountain of legal paperwork to do business overseas that they just didn't want to deal with.

</comment></comment></comment></comment></comment><comment><USER19> Happy Birthday Ed! Thanks so much for all the inspiration. I've been reading this book for the past week each day during my bus commute. You have no idea how much pumped I get and can't wait to get to office and start hacking. Thanking you so much Ed for this.

</comment><comment><USER20> I signed up to tell you that I'd love to pay for a kindle version. And happy birthday!

</comment><comment><USER21> bought it!

still think it was totally worth it!

thanks and happy birthday!

</comment><comment><USER22> Happy birthday, Ed.

</comment><comment><USER23> Happy Birthday, Ed!

The knowledge which is packed in the book will save a lot of blood, sweat and tears in the coming years down the line.

You're truly a blessing!

</comment><comment><USER24> This looks amazing and I'd love to pay for an eBook version, but Scribd won't let me buy it as a non-US resident. Any alternatives?

</comment><comment><USER25> Thanks Ed, I always enjoy your comments and almost always nod in agreement! I look forward to reading this. Happy birthday!

</comment><comment><USER26> Ed, could you create a post with the 10 principles of the book? I just feel getting "take-aways" at a glance will help reader absorb information better. Your content is excellent so presenting in one-page summary is always a good thing. I wish more people will read it. It deserves it.

</comment><comment><USER27> Thanks! Reading this book at the moment, seems I missed a lot of good stuff since I signed up :-)

</comment><comment><USER28> Love #246 Hacker News Front Page 12/31/2019

But it's Mark Zuckerberg, not Mark Zuckerman ;-)

</comment><comment><USER29> I'd like to support the author - is it possible to purchase this book and read it on Kindle?

</comment><comment><USER30> Happy b-day Ed!

I couldn't buy your book, but now i can get it free. Thanks a lot :)

</comment><comment><USER31> This feels like a treasure trove. Actually works out as a decent format for a book, I think. I saved the page as a webarchive to dropbox and opened it on the iPad with GoodReader. Good reading on the train. Cheers edw519.

</comment><comment><USER32> I'd like to wish you a Very Happy Birthday indeed Ed and what a wonderful gift :)

</comment><comment><USER33> I like that age is not important in programming (see 94).

So H.B. to you.

</comment><comment><USER34> Ahhh, thanks Ed! You rock!

</comment><comment><USER35> Thanks so much Ed. I was looking forward to buying this when it was first posted on HN, but it was not available in my country. Now it is :) , thanks to you ! And a very Happy Birthday :)

</comment><comment><USER36> your book was an insight of what life could've/would've been if I pray I become as wise and as productive as you have demonstrated.

good job/ haspy birthday>!

</comment><comment><USER37> Happy Birthday Ed! Thanks so much for sharing.

</comment><comment><USER38> I wonder why you are not still a startup millionaire ?

</comment><comment><USER39> Happy Birthday Ed. Thank you for the gift.

</comment><comment><USER40> Thank you Ed, this is amazing!</comment>


NTSB chair eviscerates Tesla for inaction over Autopilot concerns - <AUTHOR> https://www.engadget.com/2020/02/25/ntsb-chair-eviscerates-tesla-for-inaction-over-autopilot-concern/ <comment><USER2> Another fun read on this that was just posted [https://news.ycombinator.com/item?id=22416420](https://news.ycombinator.com/item?id=22416420)</comment>


The Right Way to Ask Users for iOS Permissions - <AUTHOR> https://medium.com/p/96fa4eb54f2c

<comment><USER2> Excellent post on lifting the opt-in rate for push .. The opposite side of the spectrum is user annoyance and app abandons when these channels[specially push] are used to spam

<comment><AUTHOR> Yeah, that's another post. This is just trying to get people to trust the app. Maintaining the trust is actually something else we've spent time on.

<comment><USER2> @bmull you might want to check out what we are doing in the space @[http://www.informion.com](http://www.informion.com) \- we are essentially using relevance as a key driver for engagement.

Would love to connect @ritwiktewari</comment></comment></comment>


On Lisp's Readability and Parenthesis Stacking - <AUTHOR> http://gregslepak.posterous.com/on-lisps-readability <comment><USER3> The problem is not the ()))))), it's the 200 lines function which does 20 different things all at once. Split that into smart and readable function.. You identified a problem (Hard to get where that println goes), however, you came with the wrong solution.

But I need to say that you are right about the fact that many lisp code are really ugly.. Maybe it's because when programmers are coding in lisp they considere themselves hackers and don't think about coding cleanly.

"With great powers come great responsibility." Since Lisp is the most powerful language, people should learn to separate abstraction into separate function. I mean, it's not because you have lambda and you don't have to name function that you absolutely need to do it.

Often, for small function, lisp coder tends to put that in a lambda and inline it directly in the bigger function.. which in my opinion is not the way to go.

A friend of mine once told me he really liked lambda because he had difficulties to find good game for function and variable.. by stacking all lambda together, it was way faster and easier for him. The problem with that, of course, is when other programmers will actually try to read that code and understand what it does.

Flame me if you want but when I need to work on someone else project written in lisp code, I always know it will be a pain to understand it. However, when I need to read java or C++ code, even thought the syntax is uglier and more verbose, I know I will have no problem reading it.

So here's a small trick for you hackers:

\- Don't be afraid to separate your code into many functions, even if you are using lisp.

\- Don't be afraid to use (let) syntax to give a name to portion of codes.. it might be harder to write (finding good variable name is sometime really hard and takes more time), however, it will make the code so much readable.

<comment><USER4> am I mistaken in thinking that part of this problem is a desire to not pollute the namespace since most(all?) lisps are unable to properly privatize functions?

<comment><USER5> Perhaps this is true in CL, but Clojure makes it easy to define private functions.

In the case of the particular example he points to it's just a long function because many people contributed to that function over a period of several months.

<comment><USER4> Thanks! I didn't know about defn-

Time for refactoring :D

</comment></comment></comment></comment><comment><USER6> " _If you feel that parenthesis stacking actually improves the readability of your code, by all means, feel free to do so! However, "everyone else is doing it" is not a good reason to sacrifice the readability of your code._ "

I think it is a good reason. The community benefits when everyone uses a consistent style. Readability isn't just about being able to read your own code, it's about helping other people read your code.

The accepted style of the community will make sense up to a point; no one wants to make things really hard on themselves, and people gravitate toward things that are comfortable. But it'll also be partly arbitrary and probably not optimal in every way. Part of learning a programming language is learning the idioms and dialects of other programmers.

Using a style no one else in the community uses is like making up your own words in spoken language. People will be able to understand you given some effort, but are they going to bother? If they do bother, they're probably going to be annoyed. Even if your new words are "better".

If you're the only one reading your code, knock yourself out. Otherwise you should probably suck it up and adapt, in my opinion.

" _No other language that I'm aware of stacks scope delimiters or has a community where the standard indentation width is two spaces wide, and where sometimes even a single space is considered acceptable._ "

Idiomatic Ruby uses two space indentation. Maybe because Ruby is often so deeply nested, like Lisp.

<comment><USER7> Scala also, has a standard two-space indentation.

</comment></comment><comment><USER8> Meh. Took me all of two seconds to figure out what scope that line was in. Then when I read on and was told its hard, I double-checked by counting parentheses only to find out I was right the first time. I honestly don't know what hes talking about.

As for "line count" not being important, I personally like fitting as much code into one screen as I can (especially since I often code on my netbook). Short functions are important, but even then, nice and compact code is still very important to me. Especially since I'll split code onto their own lines once the line gets more than about 70 or so characters long.

I dunno. Even if line count was unimportant to me, I don't see what the problem is, since I found it easy to spot the nesting.

Anyway, that code is much too complicated. Hes using Clojure (ie, a Lisp), he should make use of the available abstractions to simplify the code. This will, in turn, make it easier still to figure out nesting of arbitrary lines of code.

</comment><comment><USER9> "Now try the question again, in what function or macro is the highlighted line located in? Was it easier to answer this time?"

No, not really, no. I didn't find it any easier either way.

I also don't buy this fellow's argument that lisp is the only language in which people rely on the editor to help them figure the the scope of expressions. I know that I use the editor when coding in C like languages as well. So I don't think that this argument for trailing parenthesis bears any weight.

The only argument that does make sense to me is that inserting a new expression at the end of a form can be annoying with editors that expect to operate on lines.

Personally, I find "parenthesis stacking" to look nicer, and it certainly has the advantage of being standardized and widely accepted in the Lisp community. One of the advantages of Lisp's syntax is that indentation and formating is so well standardized you can rely on an editor to do it right every time.

<comment><USER10> It was the "let", right?

<comment><USER11> Yes.

</comment></comment></comment><comment><USER12> I've long ignored the Lisp formatting debates because I seem to provide, for myself at least, the only counter-example that many authors are convinced doesn't exist. That is, the traditional Lisp parentheses "hell" is very much readable to me, thank you. More so than the C-indented style.

I use C-M-b and -f to jump around the parentheses but I would do the same with properly indented C code as well. I don't always "see" whether this right paren aligns with the left paren that has 16 or 20 spaces of indentation.

Secondly, the author dismissed the argument of lots of indentation and lone right parens making the code longer, but it's a valid point. I can see the Lisp function in one screenful while the C version would flow outside. And for me, that's even worse.

Third, code always needs mental parsing in your head. Code isn't meant to be merely read, it's meant to be inspected and studied. It's an interactive process and it's not cheating to use an interactive editor to help you with that.

</comment><comment><USER13> Interestingly enough, his "parenthesis-stacked" C code looks just like Python, which I find a pleasure to read.

There's one difference, though: conventional Python is indented four, not two, spaces. In fact, the main aspect of his "normal" C code that makes it more readable (to me, at least) is his use of four spaces for indentation.

Personally I think the biggest barrier to Lisp readability is too little indentation (two spaces is typical). Looking at his reformatted Lisp, the way I identified the nesting level of his highlighted line was not by looking at trailing parens but by looking at the indentation, which was much wider (and therefore clearer) than standard Lisp.

<comment><USER14> Your mention of Python made me wonder if anyone's experimented with an indentation-sensitive syntax for Lisp. It turns out they have.

In this Scheme RFI, "I-expressions" can be freely mixed with S-expressions in source:

<http://srfi.schemers.org/srfi-49/srfi-49.html>

This argument for I-expressions touches on many of the same points as the OP; e.g., whether source needs to be readable independently of the editor:

[http://www.dwheeler.com/readable/retort-lisp-can-be- readable...](http://www.dwheeler.com/readable/retort-lisp-can-be- readable.html)

<comment><USER15> If you watch a Lisp-related mailing list, it seems like once a week someone brings up the topic "hey, what if I replaced the parens with significant whitespace?"

<comment><USER16> The answer:

You end up with seemingly arbitrary limitations like single line lambdas, just like Python.

<comment><USER17> False. The I-expression:

      lambda (x y)
        display x
        + x y

corresponds to the S-expression:

      (lambda (x y)
        (display x)
        (+ x y))

</comment></comment></comment></comment></comment><comment><USER18> It seems to me like the second example's readability stems almost entirely from the indent increase. I don't see how the stacking helps or doesn't help at all. I just saw the addition linebreaks as noise that ruins the flow of the code.

Even with the current example, I immediately said, "Inside the let." The only uncertainty for a half-second in my head was with the with-open, but that's only because 2-space tabs are pretty tight and long functions like that make reading the drop harder.

<comment><USER19> Indeed. And if your eyes aren't up to detecting that (this function is indeed long), EMACS has traditionally had two ways of manually finding that out: previous line retains the current column number, so you can position yourself at the println's opening paren and then go up. Or automatic highlighting (blinking in the monochrome days) when the point is over the closing paren.

In my personal experience (e.g. reading Lisp Machine system code) it hasn't often been a major problem. Then again I think I'm really good at following aligned columns and I can see other people not being good at this.

</comment></comment><comment><USER20> The Clojure example he gives of a closing paren stack that looks like ]))))])))) highlights the downside of the Clojure sugar for vectors. It's a lot easier to just keep pounding out parens at the end of an expression until they match up than it is to carefully alternate ] and ). This outweighs whatever gains were made by the vector literals IMO.

I think I would have preferred some standard reader macros instead for collection literals.

<comment><USER12> It would be easy to add a nice electric-right-paren function to clojure-mode that would be bound to ')'. It would always insert the right kind of a closing paren.

Actually, I'm wondering why that doesn't already exist there. (Just checked.)

<comment><USER21> paredit-mode (<http://www.emacswiki.org/emacs/ParEdit>) already provides a lot of functions for manipulating s-expressions, including keeping track of your braces.

</comment></comment></comment><comment><USER22> Poor Python programmers...they can't trail their delimiters, because they don't _have_ any!

</comment><comment><USER23> I did find it vaguely easier on the second one but (aside from already knowing) I'd chalk it up to two reasons:

1) 4 space indents instead of 2 making it more visually obvious.

2) I wasn't told "pop quiz" and so I didn't assume it was some sort of trick and so I trust the the indentation.

</comment><comment><USER24> > Now try the question again, in what function or macro is the highlighted > line located in? Was it easier to answer this time?

No? In either case, if it were me I'd highlight the previous close-paren (whether it's on its own line or not) to see what form it associates with. I'd do the same thing with a close-brace in C++ or an end token in Ruby. Long code blocks are a problem of every language, not just Lisp.

</comment><comment><USER25> First, if you're writing code in an editor, there's no problem with using that editor help you write the code. Complaining about having to use an editor to use paren-matching is like complaining about screws because they don't work so great without a screwdriver. You have tools, you can use them, you don't get man-points for scratching your code into a stone slab with a chisel.

That rant aside...

Trailing parens (and trailing braces in brace-y languages) do increase _local_ readability, but they do so at a _global_ readibility cost. They eat lines of code, which makes it difficult to see an entire code fragment at a time. Like all trade-offs, there are reasons why you should and shouldn't, and situations where you should and shouldn't. And the important thing is, the cost of trailing parens is higher in a Lisp than it is in your average brace-delimited language. This doesn't mean that it's _always_ the right decision in C or the wrong one in Lisp, but _on average_ C is more likely to get a net benefit than Lisp.

Lisp simply nests more than C-style languages. This means that you pay the line-costs more often and your code density goes down a lot faster. There are a couple of reasons that Lisp nests deeper, some of them from the language itself, some cultural. From the language side, C only uses braces for control structures, and those don't return values. In Lisp, both functions and control structures use parentheses, and control structures return values so they often get used as arguments to functions, increasing the nest depth. From the cultural side, C-ish languages use variable assignment and sequencing of operations as its fundamental operations and braced control structures are less frequent, while Lisp passes values as arguments to functions as its fundamental operation. Lisp tends to use additional parentheses in places where a brace language would use a semicolon instead of a brace.[1]

I have to say, the trailing-parens didn't really help me read the example that much. Having extra parentheses didn't help me figure out what line indented with what. In fact, it made it harder because there were more lines in the way. I suppose people who favor brace-y languages count braces rather than matching indentation, but like I said before, Lisp nests more so that's a lot of counting. Again, this doesn't mean that stacking parens is always right in Lisp, or even that it's right in this code sample, since I'm not the one writing or reading it. It means that, once again, these religious wars are silly and you should pick what works best, and my $/50 is that trailing is more expensive in Lisp so it doesn't increase readability as often. FWIW, people who claim Lisp code is naturally more dense could argue that Lisp can more easily pay those extra lines.

[1] Example idiomatic C-ish language (JavaScript perhaps):

      a = foo(x, y);
      b = bar(x, y);
      return qux(a, b);

vs idiomatic equivalent lisp, which prefers to nest deeper rather than assign intermediate values:

      (qux
        (foo x y)
        (bar x y))

<comment><USER3> About your editor rant, I am not sure I agree with you. A great editor will help you for sure in productivity. However, a language shouldn't be unreadable without a correct editor.

Imagine that, to read English, you actually needed a powerful editor.. Yes, some tools help you to be more productive (such as searching, replacing, etc.).

So, again in my opinion, a good test to see if a language is readable is to print it and read it without any special tools such as syntax highlighting. If you can actually do that, imagine how syntax highlighting will make you even more productive!

By the way, it may sound absurd, but try reading English or Python without colors..

<comment><USER26> The editor helps you write Lisp, by keeping count of parens, but once it's written, it should be readable without any special support.

And reading Python without colours isn't much fun.

Haskell can get away without colours in Papers, but the authors tend to substitute lots of mathematical symbols there with the help of TeX. (And they use other typographical hints instead of colour.)

</comment></comment></comment><comment><USER27> You know, I kinda like that Lisp-style C++ formatting...

<comment><USER16> Kinda Pythonic, as someone else already noted.

</comment></comment><comment><USER17> The real reason that parenthesis-stacking is the norm is twofold:

a) Trailing parentheses just look ugly. I can't really explain why - <USER2> it's merely a cultural thing, come about only because lispers are so _used_ to looking at stacked-parenthesis code.

b) Lisp code tends to get _very_ nested. In C or Java code, you rarely get more than 3 trailing braces in a row. In Lisp, if you trail parentheses, you regularly end up with 5 or more lines of nothing but trailing parentheses. This contributes to the ugly factor and makes for a lot of "wasted" whitespace. It's also one of the reasons 2-space indentation is the norm for lisp instead of 4-space.

Honestly, I don't think trailing parentheses makes lisp code particularly easier to read. I agree with noahlt that it's mostly the 2-space versus 4-space indentation issue.

<comment><USER28> I think the nesting in lisp code is ultimately what makes lisp difficult. Deep nesting is hard to read!

Haskell is also deeply nested, but the where statement makes it very easy to read. A where macro would be easy to write in lisp, the real trick would be making it part of the standard lisp style.

</comment></comment><comment><USER29> The main advantage of parenthesis stacking is that it signals that the form you're using might be too nested. Granted, a lot of leading white space does this too. YMMV.

</comment><comment><USER30> I would say the real solution, the one which increases readability the most, is to remove the need for many parentheses at all by using optional significant whitespace – see <http://www.dwheeler.com/readable/> for an example of such a syntax. (Of course, if you don't export your code to normal, over-parenthesized Lisp before giving it to others, they will have trouble running it.)

</comment><comment><USER31> Readability is more about consistency than some style war. If you read more code that looks like X, then code that looks like Y will look "weird" and "unreadable". The exact opposite holds for those who read more Y.

Try reading a Japanese manga translated into English. You start from the _back_ of the book and read the _right_ page first. Or try learning a language with "verb at end" kind of structure if English is your native tongue.

With lisp, the parentheses help create uniform parseable structure for both code and data, so I appreciate the compromise of a repeatable indentation scheme for code (using an editor) that lets you totally ignore the parens when reading.

With lisp, I do find syntax formatting such as bold keywords very effective even in the absence of color. So yeah, it is easy to create readable lisp in print as well. In fact, with bold keywords and gray parens, lisp code looks gorgeous and eminently readable.

<http://xkcd.com/297/>

</comment><comment><USER32> Oh hey everyone look! Another childish post about syntax! Let's all argue about nothing!

</comment><comment><USER33> I found both of the C code examples equally readable, but personally use neither one when I code in C. I don't (usually) stack closing braces in C mostly so that I don't accidentally kill a line with a closing brace on it. That sort of thing can theoretically happen in Lisp, but is usually easier to spot and easier to fix.

I do, however, in C put the opening brace on the same line as the definition, generally to make grep more productive. I've found it nice to be able to grep for { (or even "){" and get some useful information.

</comment><comment><USER34> Well, if this guy is going trailing parens, I'm going to start, too. I thought someone old beardy lisp guy would jump out and shoot me if I did, but he seems to be doing fine.

<comment><USER35> You might as well try to use <http://edward.oconnor.cx/elisp/hl-sexp.el> everywhere, including REPL first.

<comment><AUTHOR> This is a nice emacs addition and helps the developer, but it doesn't help the people who then look at his code using other editors, or via public repos on the web.

</comment></comment></comment><comment><USER36> I write my LISP the way I write my JavaScript: I use one space for indentation, I break up my lines a lot, I nest deeply, and I tend to have a line break after the open and before the close, if the nesting is more than a layer or two deep and two broad. I'd prefer to use a tab for indentation, but I often find myself typing my code into an "eval box" (a textarea on a web page tied to a button that calls eval on the contents of the box).

<comment><USER37> It sounds like you're not using a javascript debugger (or rather rolling your own).

If that's the case I'd encourage you to familiarize yourself with some, firebug/the Chrome Inspector/IE + VS/whatever

</comment></comment><comment><USER38> A bit out of topic, but does anyone here write (serious) scheme/lisp code with vim ? Just a curious question ...

<comment><USER37> <http://paul.graham.usesthis.com/>

I use vim for so many other things that I find it tricky to switch unless I'm going to be writing lisp for the rest of the day.

I do miss paredit mode...

</comment></comment><comment><USER39> Most programmers prefer to use spaces instead of tabs because of some rant written ages ago by a Lisp programmer.

Spaces are better only for Lisp. Tabs are better for C++.

At least for parenthesis the custom is different.</comment>


Some Fundamental Theorems in Mathematics - <AUTHOR> https://arxiv.org/abs/1807.08416 <comment><USER3> The second theorem (the generalized Pythagorean theorem, which uses inner product spaces) feels incomplete to me. The exposition is fine, but I don't think the explanation should have concluded with the regular

        a^2 + b^2 = c^2

equality. You wouldn't use that in the context of an inner product space. The generalized Pythagorean theorem actually looks like

        ||x + y||^2 = ||x||^2 + ||y||^2 + 2<x, y>.

I think it would be better if there's less editorializing of the equalities and more relating of their abstract forms to their "simple", familiar forms. Otherwise I don't really understand the exercise - if the first page has a theorem involving inner product spaces, this is clearly targeted at people with at least a full course of linear algebra under their belt. Unless the audience is already aware of how that second equality implies the first equality, this explanation doesn't capture the heart of it.

As another commenter said, this is not a self-contained exposition (and I don't think it realistically could be). But if it's not going to be self- contained, I think it could be improved by more completely showing how the elegant abstractions imply the things we're already familiar with in a neat way.

<comment><USER4> The Pythagorean theorem is about orthogonal vectors, so it would just be

      |x + y|^2 = |x|^2 + |y|^2

Plus the line just above that tells you: let

      a = |x|, b = |y|, c = |x-y|

I don't think they are obscuring anything. I think they are showing how the a b and c in the familiar a^2+b^2=c^2 can be generalised to |x|, |y|, |x-y| for any orthogonal vectors x and y in an inner product space.

</comment></comment><comment><USER5> Number 20 in logic is incorrect. It's surprising how often this is misstated. There are lots of complete axiom systems. Indeed, take as your axioms all true statements in a given model. Voila, you now have a complete axiom system. It's not just a useful one but it is complete. What isn't complete is a recursively enumerable axiom system that contains arithmetic of the standard model of integers.

Overall it is a nice list and well done.

EDIT: Deleted a sentence that was pointed out to me that was wrong in the context of the assumptions made in the paper.

<comment><USER6> >Number 20 in logic is incorrect.

>What isn't complete is a recursively enumerable axiom system that contains arithmetic of the standard model of integers.

That's exactly what #20 says. The "axiom system" there, by definition, includes Peano axioms (2nd sentence of #20).

<comment><USER5> I didn't read that part but the statement is still wrong. Take as your model the standard model of integers. Collects all true statements of this model. Make this your axiom system. It is now complete and contains the first order Peano Axioms.

<comment><USER7> Then that system is not finitely axiomatizable (there are infinitely many truths in that model) so the original claim is still true. It's true for all finitely axiomatized theories.

<comment><USER4> Not finite, but recursively enumerable, no? Since you can just start from PA and derive conclusions forever, so this is an effective procedure in that any true statement will eventually be thus produced.

<comment><USER8> No, even if you start with the axioms of PA and enumerate all theorems provable, you'll miss some true sentences, one of them being the Goedel sentence of PA.

</comment></comment></comment></comment></comment></comment><comment><USER9> I came into the link ready to nitpick the choices (for some reason which I really should examine), but it's actually a nice birds-eye-view of the field that is rare to see. I feel like mathematicians, perhaps more than most, tend to stay siloed within our specialized subtopics.

<comment><USER10> I belive it's because math is such a "clean" field that it doesn't take many people to 'clear' a topic and advance a subfield or branch into sub-subfields. So you don't have a large number of people all rooting around in the same area speaking the same language.

With complex sciences like biology, or worse, wet lab experimental science, it takes so much drudgery just to get data to work with, that you can have 100x people working in the same area, trying to cover the data/processing requirements to support theorizing and cataloging discovered entities.

</comment></comment><comment><USER11> This list is fun, but it's a little bit sloppy:

\- The central limit theorem relies on the mean and variance of your random variable existing; there are random variables for which mean and variance don't exist.

\- The definition of "measure-preserving" in the ergodic theorem statement is missing the measure.

\- dim (ran A)^perp = dim ker A^T can be strengthened by dropping the dim's. If v in ker A^T, then A^T v = 0. Pick any Ax in ran A; then <v, Ax> = <A^T v, x> = <0, x> = 0, so v is in (ran A)^perp.

\- Others pointed out that 20 looks busted.

\- The definition of Haar measure needs to fix the measure of some nonzero- measure set, or "unique" needs to be replaced with "unique up to scaling" otherwise the theorem isn't true.

\- "Sounders Mac Lane"

\- 25: x_0 came out of nowhere; it's unclear from the text which "invertible" is meant; the basin of convergence for Newton's method for finding a local continuation can be very small indeed.

\- 36: Why is the adjoint of A named T^*?

\- 46: You need some assumptions about f.

<comment><USER12> I think you're being a bit harsh.

The central limit theorem does hold for iid rv (independent identically distributed random variables) with finite mean and variance. Now, those assumptions can be relaxed (the rv need not be independent, but they can't be too dependent, and they need not have finite variance, but they can't be too "far out"), and some of the pertinent proofs are only a few decades old; but you can hardly expect a survey with 135 proofs to cover all the subtleties.

Some of the other points may be more egregious howlers, but, again, come on - this is not the definite reference for any one of those theorems.

<comment><USER11> There's more than enough neat stuff I don't know in there. Unfortunately it's tough to trust a source with so many errors in the stuff I do know.

I wasn't aware of any CLT for iid random variables with infinite variance. Do you have references?

<comment><USER12> Check Valentin Petrov _Limit Theorems of Probability Theory_.

Here [1] is a CLT for RV with infinite variance, Prop 3.1.12, but notice the (larger) scaling coefficient (1/sqrt(n log n)).

Also see the second answer on SO here [2].

[1] [https://web.stanford.edu/~montanar/TEACHING/Stat310A/lnotes....](https://web.stanford.edu/~montanar/TEACHING/Stat310A/lnotes.pdf)

[2] [https://stats.stackexchange.com/questions/169611/the-role- of...](https://stats.stackexchange.com/questions/169611/the-role-of-variance- in-central-limit-theorem)

EDIT to add: Having said that, the Lindeberg-Feller and the Lyuapunov formulation of the CLT do require finite variance, so maybe I was too quick in stating that that assumption can be relaxed.

</comment></comment></comment></comment><comment><USER13> I love Oliver Knill! Not only does he have very broad mathematical interests, he also has this crazy YouTube Channel ([https://www.youtube.com/user/knill101/videos](https://www.youtube.com/user/knill101/videos)) where he sometimes uses a synthetic voice (!) to give talks---supposedly because he cannot talk as fast as he wants to.

He really is quite an interesting charactern!

</comment><comment><USER14> Thank you for sharing! One thing I noticed is the statement in 20. Logic:

 _An axiom system is neither complete nor provably consistent._

I think this would benefit from some rephrasing, because such a system could for example be both complete and provably consistent (in the sense given in the paper) if it were, in fact, inconsistent.

Also, IUT is not "Inner-Universal Teichmuller", but rather _inter_ -universal Teichmüller theory.

<comment><USER15> That one also bothered me, because it is very much wrong.

The correct result is

 _Any consistent axiom system that describes the natural numbers cannot be complete or provably consistent._

You pointed out that an inconsistent axiom system is neither. And at the opposite extreme, Gödel proved that the axioms for the real numbers are provably consistent. (However those axioms do not allow for induction, and therefore do not allow one to describe the natural numbers!)

<comment><USER5> This is incorrect as well. Take the standard model of the integers. Now take all true statements in this model. Let this be your axiom system. It is complete. It is not recursively enumerable and therefore not very useful. You can also have second order systems that are categorical. For instance the second order Peano axioms. I believe they are complete.

<comment><USER15> Point.

But honestly, nobody ever convinced me that second order logic wasn't made up BS. :-)

Or that reasoning of a form that can't be verified, even in theory, actually is sensible. (Why yes, I do have Constructivist tendencies, why do you ask?)

<comment><USER5> Before I took Mathematical Logic in graduate school I believed all kinds of nonsense about Godel's theorems. Even after the class I still had false ideas about what it really meant. It took a while for the the recursively enumerable part to sink in as to why it is important.

I've heard what you say about second order axiom systems before but I don't know enough about the subject. I naively think, "Why not just use the Second Order Peano Axioms?". But people far more knowledgeable than me don't like them so I defer to their judgement.

<comment><USER15> I don't qualify as far more knowledgeable than you, in fact I'm probably less knowledgeable but with a different point of view.

However with that disclaimer, the fundamental challenge is that when we start reasoning about reasoning, things that "should obviously work" run into trouble. (Most commonly due to variations on the liar's paradox.)

First order reasoning within a first order logic system that we think is good is "obviously correct" reasoning.

Second order reasoning introduces as much reasoning about reasoning as we think we can get away with, hopefully without causing problems. The result is that second order reasoning lets us talk about what kinds of unverifiable statements we can discuss the absolute truth of. But I'm uncomfortable with talking about the absolute truth of any unverifiable statements, which makes it feel like discussing the subtle shades of BS we fool ourselves into believing.

</comment></comment></comment></comment></comment></comment><comment><USER16> Gorgeous.

IIRC S. Eilenberg once said "Elegance in mathematics is directly proportional to what you can see in it and inversely proportional to the effort required to see it.". This Knill book is _elegant_.

Topic by topic for a wide range of pure and well polished applied math, Knill is able and does go right to the most important results and for each gives a short outline of the needed definitions and of a proof, usually with good references to full details, and then states the theorem precisely. Net, for nearly any topic in pure/applied math, go there first.

For many of the topics, I studied them carefully from some of the best sources, but just on a short scan this Knill book often has a better treatment, e.g., has a super nice, simple, practical statement of a fundamental theorem in Fourier series, a super nice statement of the Lebesgue decomposition from the Radon-Nikodym theorem, some nice stuff from Zorn's lemma, and much more, e.g., often some historical notes.

I have to like the connection with Zorn's lemma: At one point I went to a lecture at Indiana University and to the tea before, and an older professor introduced himself as Max Zorn. Since the previous summer I'd taken a course in axiomatic set theory on an NSF summer program at Vanderbilt, I was nearly floored! All I could do was blurt out, "What did Paul Cohen prove?". The next day Zorn gave me his copy of Cohen's paper. I still have it!

At one point I saved FedEx by pleasing two guys from crucial investor General Dynamics by doing a revenue projection with the differential equation

y'(t) = k y(t) (b - y(t))

with y(0), k, and b given. So, the solution is a _lazy S_ curve that starts at t = 0 at y(0) and as t increases rises, has an inflection point, and rises from below asymptotically to b. So, it is a case of growth to a market size of b. With y(t) the current revenue and (b - y(t)) the market revenue yet to be obtained, has the growth rate y'(t) proportional to the current revenue y(t) (number of current customers talking) and the remaining customers (hearing the talking) (b - y(t)). So, it's a simple model of _viral_ growth.

Well, Knill has this differential equation with b = 2 for a case of biological growth!

</comment><comment><USER6> A supremely amazing collection! Succinctly written, and a joy to read. The curation is fantastic. Some would disagree with the choices, but the task was herculean. (e.g. geometric group theory is not really represented there - <USER2> one can't expect to have all of mathematics in 60 pages!)

I ended up going through the list, categorizing these theorems into know/don't know/should know categories. Time well spent.

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

Mandatory "Hey, there's a typo there" note:

In #77: HOMFLYPT polynomial's list of authors is missing Y: David N. Yetter, a professor in Kansas State University. Hope this omission will be fixed!

I learned knot theory and did research with Yetter in 2007 (which resulted in a paper on Vassiliev Invariants, a subject also mentioned in #77); that was a pivotal point in my life.

Besides mathematics, Yetter's other major interests, to my knowledge, are Orthodox Christianity and anime.

</comment><comment><USER17> As a math major, this makes me giddy. It's like a family reunion, all my old friends in one place.

</comment><comment><USER18> The Control Theory (129) section does a real disservice to the field by insinuating it is little more than the study of Kalman filters. While an important model, the core results of control theory are without a doubt stability criterions.

The Lyapunov stability criterion is even quite elegant, despite being powerful: A system is asymptotically stable if there exists a function V where for x/=0, V(x)>0 and [Sum]_i (dV/dx_i) (dx_i/dt) < 0.

<comment><USER19> Every single subject in the overview is summarized with similar brutality, yet it still reads like an encyclopedia. There's a lot of math out there.

</comment></comment><comment><USER20> It's amazing to see so many things included and yet so many missing. It really speaks to the breadth and depth of the subject. For instance, for elliptic curves, only a single result is mentioned (their points can be endowed with an abelian group structure), and it's really one of the most basic ideas known about these objects.

<comment><USER19> Right. If I pick one of these subjects where I know, say, 100x more than what is present, and know of the existence of 1000x more than is present, I can't help but multiply the number of subjects in this overview by that that same 1000x, and then my mind explodes.

</comment></comment><comment><USER21> Other lists in the similar spirit:

[http://www.cs.ru.nl/~freek/100/](http://www.cs.ru.nl/~freek/100/)

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

</comment><comment><USER22> The Topos theory example is completely wrong though? > For example, if E is the topos of sets, then the slice category is the category of pointed sets: the objects are then sets together with a function selecting a point as a "base point".

There's no object X where E/X is pointed sets. If you take the co-slice of a one point set 1\E that would be the category of pointed sets.

The right way to think about E/X is that its objects are "families of sets indexed by X", because a function f : Y -> X defines for each x in X a set f^{-1}(x). If you know about dependent types, this is basically a type dependent on X.

</comment><comment><USER23> Fundamental Theorem of Group Homomorphisms:

If f is a homomorphism from a group G_1 onto the group G_2, then G_1/ker(f) is isomorphic to G_2

...and that's the tea.

</comment><comment><USER24> The Church-Turing Theorem is not really a mathematical theorem; It is more like F = Ma in Physics. It's an empirical result.

<comment><USER25> The statement that "f is generally recursive iff it is Turing computable" is a theorem that can be proven, because we can rigorously define what it means to be Turing computable (computable by a Turing machine which is precisely defined) and generally recursive (which is the smallest set of functions closed under projection, composition, primitive recursion and minimalization). The theorem was proven by Turing and Kleene soon after the concept of Turing computable was introduced.

But if you remove the word "Turing" it is no longer a theorem. It becomes a thesis because we don't have a definition of what it means to be computable. It is in fact an innovation of Turing to identify computable with Turing computable, but that's by no means universal.

<comment><USER26> I think it's clearer to understand the Church-Turing thesis as two theses, not one. Turing's thesis was that (intuitive) computability equals (formalizable) Turing computability.

So you could completely ignore the recursive functions part (and so, Church's Thesis) and there would still be the same sort of lay confusion about the computability thesis.

</comment></comment></comment><comment><USER27> From #113, Artificial Intelligence

 _The lebowski theorem of machine superintelligence: No AI will bother after hacking its own reward function._

 _once the AI has figured out the philosophy of the "Dude" in the Cohen brothers movie Lebowski, also repeated mischiefs does not bother it and it "goes bowling"._

I'm relieved to learn that this is a theorem. :D

<comment><USER28> The Lebowski theorem: "No superintelligent AI is going to bother with a task that is harder than hacking its reward function" is surprisingly deep.

You can see the theory in action in human history. We have drives programmed by evolution, but we try to to shortcut them. Drugs are deliberate hack for example. TV, entertainment and games can provide rewards faster than effort towards real life goals.

We fully understand that there is difference between the drive's purpose and what we do, but but we don't actually value the purpose of our reward function, only the reward. Catholic church tries to insist that people should limit sexual pleasure to the purpose it was created (by god or evolution) but people don't listen.

</comment></comment><comment><USER29> >There is no apparent "fundamental theorem" of AI, (except maybe Marvin Minsky's "The most efficient way to solve a problem is to already know how to solve it."

Personally, I consider Richard Feynman's method (1. Write down the problem. 2. Think real hard. 3. Write down the solution.) to be just as fundamental.

The reason being that steps 1 and 3 are actually _very_ important. Step 1 asks that you model the problem you're solving, otherwise you might solve some other problem instead. Step 3 asks that you model the domain of solutions. This helps ensure that it is possible for solutions to even exist.

One of the big problems with unresolved and open-ended philosophical quandaries is that people never specify what they expect a solution to look like. Like if you don't expect a solution to look like a string of plain words, and instead expect it to look like some mystical revelation, then you can't honestly expect to get an intelligent resolution communicated to you.

I'd also say it is integral to understanding the difference between simply solving a problem and intentionally solving a problem.

</comment><comment><USER30> Naive question: How would one go about learning all about this (or even a subset of this) for the mathematically inclined working engineer? Where does one even start? Just take each theorem from each section and try to follow through the proof? What are the prerequisites required?

<comment><USER31> The theorems in this list are in many cases central topics in 1+ semester courses, and aren't really worth worrying about out of context. Overall you are looking at more than 5 years of full-time (40 hours/week) study, maybe more than 10 years. Unless you have extensive background reading and writing proofs, self-study is not likely to be very effective. You could conceivably make your way through with textbooks and the help of an expert tutor/mentor.

For most people the easiest method would be to enroll in an undergraduate mathematics degree at a decent university.

If you wanted to make your way through more of the topics in this list than an undergraduate degree covered, you could follow-up by enrolling in a PhD program.

</comment></comment><comment><USER32> I think it's a great list but the typos bothered me. To me, they seem to indicate sloppiness; and if there is sloppiness, could the mathematical results be sloppy too?

e.g., on page 2 itself:

"Anticipated by _Babylonians Mathematicians_ in examples..."

"Let f be a function of one _variables_..."

</comment><comment><USER33> Does anyone have a cheat sheet of sorts for the symbols and syntax used in these?

<comment><USER34> It doesn't work like that. Some of the same symbols are used in two different places with vastly different meanings, even within this paper.

To give an imperfect programming language analogy, imagine that every symbol is implicitly defined and has lexical scope. The grammar is as far from being context-free as possible. What may sometimes look like individual symbols to you are in fact a collection of inseparable symbols with its own semantic parse.

<comment><USER35> That's not really helpful. I struggle with the same problem, in fact the notation intimidates me to a point where I decided to forego getting deeper into theoretical computer science and haunts me every time I try to read a paper.

A resource that would explain formal mathematical notation would be great, much like a dictionary.

You can't google those symbols properly either.

<comment><USER34> Did you know what the words meant? Can you read this and except for the symbols understand everything else?

I don't think the symbols are the problem. They're a very superficial obstacle, at least in this paper.

This isn't meant as a put-down. It's just that I really do think the actual material requires a lot more preparation that consists in a lot more than just learning the definition of the symbols. I could rewrite the whole paper using only text and no symbols. The symbols are just shorthand for English words. I don't think if I were to replace all of the symbols with the English words that they stand for, you would be much closer to understanding.

<comment><USER33> "The symbols are just shorthand for English words."

OK, so then why would it be so difficult to produce a veritable cheat sheet to aide in reading a proof?

<comment><USER34> Because the symbols' translation to English words changes on context, culture, and even author. It's like trying to translate the word "rain" only by hearing it without having the context if it really meant "reign" or "rein". With some mathematical training, you don't really need the symbols to know what's being talked about, because you already have enough context to know what should be talked about and what fits into the context, regardless of how it's written down.

Anyway are symbols really the main obstacle for you? When you read "every second countable regular Hausdorff space is metrizable" (theorem 59 in this paper), you have no problem understanding what this means?

<comment><USER33> Fair point, but you know very well that, for true illustration, you'd have to expand out the meaning of the words "countable", "regular", "Hausdorff", "space" and "metrizable". And I bet you could. I get the sense you're being obstinate for a point.

<comment><USER34> And don't forget the word "second". I'd have to explain that one too.

And then I'd have to explain the words I used to explain these words.

It all just takes a while. I might be able to do it, but we'd both need to spend some time understanding all of this together, going back and forth, considering examples, and building the foundations.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER36> Some Fundamental Theorems in Mathematics are bigger than others. Some Fundamental Theorems in Mathematics' Mothers are bigger than other Fundamental Theorems in Mathematics' Mothers.

</comment><comment><USER37> Can you really trust any mathematician's judgment who doesn't use serial commas? ;)

</comment><comment><USER38> This is not a self-contained exposition, and a lot of the interesting implications of the theorems seem to be omitted (why are these theorems fundamental; and fundamental to what?) It begs the question: why not instead post a list of links to Wikipedia articles? That would allow the reader to click through to definitions that they are not familiar with, as well as explore what these theorems are (practically or theoretically) useful for.</comment>


Square Processing $2B In Payments Per Year - <AUTHOR> http://techcrunch.com/2011/10/10/square-processing-2b-in-payments-per-year-signed-up-800k-merchants-drops-new-user-limits/

<comment><USER2> Has anyone heard any rumors about when Square is going to release 1.0 of their android API.

I'm building a POS into some tablet based software my company sells, and I'd really like to do microtransactions without the $0.30 fee per transaction.

<comment><USER3> Google Payments (<https://checkout.google.com/inapppayments/>) has no transaction fee, just a flat 5%.

<comment><USER2> Thanks for the suggestion, but I need something that will work with a card swiper and do card-present transactions.

</comment></comment></comment><comment><USER4> Impressive, but does it make sense to measure things per yer on a 2 year old company? I'd be interested in a more granular breakdown and how/if market cycles effect them in the same way it does retailers in general.

</comment><comment><USER5> Wonder what portion of the $2B in transactions are those that come under $6 on which, Square actually loses money. Also, it averages $2500 per merchant, which seems that these are low volume merchants, and unlikely that Square has recouped their merchant setup costs yet. Transaction volume has to still improve significantly before Square will find itself in the black. Yet, much kudos to a true disruptor.

</comment><comment><USER6> So that's at least $55mm/revenue PA.

</comment><comment><USER7> Limited to the US market unless they do a chip and PIN reader.

<comment><USER8> Possibly of interest: <http://izettle.com/>

</comment></comment><comment><USER9> Square does an amazing job at solving both a hardware and a software problem in just 2 and half years. Pretty impressive.

</comment><comment><USER10> I have not interacted with Square at all... not in any store or online presence that I have seen.... Where are they?

<comment><AUTHOR> I seem to think that they are used by smaller or personal organisations (that's what I think they would be ideal for anyway). So maybe a lot of trades-people and freelances could be utilising their service.

</comment></comment><comment><USER11> "Rabois says that Square's merchants now represent 10 percent of the transactions in the Visa/MasterCard world."

This is either a) completely untrue, or b) a clever play on words (I don't know what "Square's merchants" means)

800k card readers shipped is significant and would be about 10% of the total companies that take credit cards, but the vast majority of those with readers are not actually companies (I have gotten several of them in the mail... saying "card readers shipped" is like AOL talking about how many CD's or disks they gave out in the 90's)

There are ~56Billion visa/mc credit and debit card transactions per year, if anyone was interested. (taken from Visa/MC 10-k's)... and a total of $3.5Trillion in transaction volume

<comment><USER12> I would guess it was (a) because the store doesn't have that line anymore. Now it says: "Rabois says that Square's merchants are now 10% of the reach of the Visa/MasterCard world."</comment></comment>


Swastika emoji - <AUTHOR> https://samgentle.com/posts/2016-09-08-swastika-emoji <comment><USER2> On the one hand, the goal of Unicode is to be able to encode all scripts, historic and contemporary. The swastika made it into a number of scripts before the Nazis ruined it for everybody, and so if Unicode is to encode those scripts, then it needs to include that character. It's easy to argue that it doesn't belong in the emoji block, but instead with the glyphs for the scripts that include it, but this is a technical detail that does not present any obstacle whatsoever to its use.

On the other hand, removing an emoji does not, in any way, prevent expression of the concept it describes. It leaves a very bad taste in my mouth, particularly when justified by what amounts to magic-bullet media theory, but to call it censorship is frankly absurd.</comment>