AWS, MongoDB, and the Economic Realities of Open Source - <AUTHOR> https://stratechery.com/2019/aws-mongodb-and-the-economic-realities-of-open-source/ <comment><USER5> Two comments:

Firstly, the discussion at the front about the music industry is quite insightful, but I'd go further - they didn't want to sell convenience at first. Used to the physical embodiment of recordings rather than the de- materialized reality of digital music, they spent years working on _mandated inconvenience_ through DRM and other legal actions. Always remember that if the music industry had won unopposed you'd have to pay a license fee to set a MP3 as your ringtone, as well as having to license every copy on every device separately.

Secondly, about mongodb: I'm reminded of [https://www.gwern.net/Complement](https://www.gwern.net/Complement) "Commoditize Your Complement", but in reverse.

Open source software is by definition commoditized. Everyone can have a copy at no cost. So what is an "open source VC funded" company doing? Creating complements and selling those. It's just that there's no intrinsic reason that the same company that gives away labour as OSS should also make the best complements to that OSS. It's not a law of nature that e.g. Redhat should be the best people to provide consultancy on RHEL.

The music industry did not expect their product to become free to distribute at the margin, but every company operating as an "OSS startup" has to know from the start that their software can't be charged for directly.

<comment><USER6> I realize that the idea of "Commoditizing Your Complements" has gained new life lately on HN, but let's give credit where it's due - Joel Spolsky in 2002.

[https://www.joelonsoftware.com/2002/06/12/strategy- letter-v/](https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/)

<comment><USER7> The first four words of the linked Gwern article are "Joel Spolsky in 2002". In fact he gives him credit 3 times!

<comment><USER8> Yes but why not link to the original (which is also more readable)

</comment></comment></comment></comment><comment><USER9> Agreed, the dream of a megacap open source company is dead. Mongodb shows this, the Unity fiasco (I'm surprised nobody has put the two together) shows this: [https://news.ycombinator.com/item?id=18874400](https://news.ycombinator.com/item?id=18874400) Guys, charge for your work. Don't place the economic value of your company to be ancillary to your product. That just invites another company that has that ancillary as their core competency to come and do it much better than you while you waste time creating this free thing that other people free-ride off of.

More on unity: [https://arstechnica.com/gaming/2019/01/unity-engine-tos- chan...](https://arstechnica.com/gaming/2019/01/unity-engine-tos-change-makes- cloud-based-spatialos-games-illegal/)

Here's the main difference between unreal and unity. Unreal costs 5% royalty per sale, meaning their product is extremely expensive to the developer if sales are high. Unity is generally royalty free and relies on "support and services" to make money. This is why Unreal will always encourage the growth of the ecosystem while Unity jealously guards the actual profit centers of the business, because Unity makes nothing on its core product!

<comment><USER10> > megacap open source company

Isn't this by itself an oxymoron? Open source isn't shouldn't be one's marketing stunt to gain attention, if you want to charge your software make it proprietary and charge people for license. Using open source as a last resort bait isn't cool.

My only jab at Amazon is that they should give back their code to the community or they need to be forced to do so, not that they can't make money from OSS software, if that is what license at the time, permits.

<comment><USER11> The problem is the licenses suck. Parity and Prosper solve these problems with Parity covering your use case:

[https://licensezero.com/](https://licensezero.com/)

<comment><USER12> Those aren't Open Source licenses, so that's the same as the suggestion in the parent comment to make the software proprietary and charge for licenses.

<comment><USER11> Parity is an open source license that should achieve the goal of contribution sharing better than the others since it's wording focuses on changes, not distribution models.

[https://licensezero.com/licenses/parity](https://licensezero.com/licenses/parity)

It also has a patent license, unlike many permissive ones. They shouldnt even qualify as open source if you can get sued under patent law for using that software. Need some patent protection in license.

<comment><USER12> > Parity is an open source license

No, it isn't: [https://opensource.org/licenses/alphabetical](https://opensource.org/licenses/alphabetical)

A few issues:

> 3\. Contribute software you develop, deploy, monitor, or run with this > software.

That goes farther than the OSI, FSF, or DFSG allows, extending into software that is not in any way derived from the licensed software.

It's also not obvious from the license that it allows private modifications that aren't distributed to _anyone_.

> To contribute software, publish all its source code, in the preferred form > for making changes, through a freely accessible distribution system widely > used for similar source code

This requires that you publish your code publicly, rather than just providing it to those you provide binaries to.

<comment><USER13> license-review deja vu! To recite my views:

Parity conforms to the Open Source Definition as written. "Is it open source?" and "Has OSI approved it?" are related, but distinct, questions, as acknowledged by OSI process.

OSI-approved copyleft licenses already sweep broader than derivative works of the licensed software.

OSI has approved copyleft terms requiring contribution back of private changes.

<comment><USER14> Have you considered submitting for OSI approval?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> When you give money to redhat, you buy insurance that if you encounter a problem, they will support you. It is expencive, but there is clearly a lot of work involved in producing new release. IMHO redhat deserves its money.

When you give money to Oracle, you are financing lawyers who try to find the best way to make you pay more without improving the software.

<comment><USER16> "IMHO redhat deserves its money". I agree. But the vast majority of people employ CentOS which is redhats derivative.

Oracle engineers work hard on java and deserve their money but the vast majority of people employ OpenJDK which is OracleJDKs derivative.

<comment><USER5> For a long period of time I regarded Oracle as absolutely undeserving owners of the JDK; they didn't write it, it was bought from Sun, they shipped adware in the installer, tried to sue Android out of existence, and were poor stewards of the language.

<comment><USER17> You wrote in the past tense. Did something change your view?

<comment><USER18> well, with openjdk nobody remembers oracle now. so I guess that changed.

if oracle wanted to continue to be the owners of Java they shouldn't have called their bluff and sued Google.

<comment><USER19> OpenJDK is mostly developed by Oracle employees. There isn't OpenJDK without them.

Oracle did the right thing against Android J++.

</comment></comment></comment></comment></comment></comment><comment><USER20> > It is hard to imagine [AWS, Microsoft, and Google] ever paying for open > source software.

It's surprising that someone setting out to write about the changing economies of open source ends up missing the point so thoroughly. These companies are some of the biggest contributors to open source.

What they aren't likely to want to pay for is a site license from some company trying to sell them a MongoDB under terms practically identical to what Oracle does for Oracle DB. That's the "CD" model the article could make a comparison to.

I don't think we're ever going to have something like an open source version of the Oracle model that's equally sustainable, just like the notion that you're going to buy an entire album to listen to one song isn't coming back.

Rather, open source is going to be something where you might run a database like PostgreSQL, and if you're a big enough user contribute to its development, either yourself or by paying some support company of core devs. That company might also provide support, or you could go with another provider for that etc.

<comment><USER21> > These companies are some of the biggest contributors to open source.

I wouldn't expect AWS to make a lot of code contributions to MongoDB when they've built something else that's 3.6 compatible, though. It's not like they're going to make contributions to a new, incompatible version of MongoDB. They've already made the call to fork.

I agree with what you're saying about other products, but not this particular case.

<comment><USER22> It isn't a fork, it's an entirely new database that implements the same API.

c.f. [https://twitter.com/nathankpeck/status/1083385031207387136](https://twitter.com/nathankpeck/status/1083385031207387136) from someone at AWS DevRel.

There's nothing about Mongo's license that's super relevant here -- it's a similar situation to other cloud providers offering "S3"\- or "EC2"-compatible APIs.

(IANAL, but AIUI API copyright/fair-use isn't entirely settled in the US, Oracle v. Google nonwithstanding, since 9th Cir. isn't per se controlling precedent nationwide in copyright matters)

<comment><USER23> Also important is the API that AWS is compatible with was itself part of the OSS licensed code of an old version of mongo. Oracle vs. Google is different as Java was never OSS licensed.

</comment></comment></comment></comment><comment><USER24> Honestly at this point I would rather use Closed Source software than Open Source that isn't "Free as in Speech". It's a wolf in sheep's clothing. At least closed source is honest about its intentions.

I use Free Software not because the price, but rather so I can be Free. So I can know I am free to use software I develop with it in whatever way I want.

I find the push to market open source by limiting it's use one of the most distasteful things in recent software history.

<comment><USER25> MongoDB's new license does not in any way prevent you from using MongoDB in whatever way you want. It simply requires you to, in some cases, release the changes you make to it publicly. You know, like the GPL did before companies found that a SaaS model let's you side step the release changes requirement.

<comment><USER26> >* like the GPL did before companies found that a SaaS model let's you side step the release changes requirement*

Unless you use AGPL where the trigger for releasing your modifications is making the change available by any means (direct or otherwise) rather than with the standard GPL where the trigger is distribution of outputs compiled from the modified version.

<comment><USER25> MongoDB did use the AGPL and still had issues with companies trying to argue they didn't need to release their changes. So they switched to their own license which was even more explicit on the matter.

<comment><USER27> What problems did MongoDB run into? Can you link to any specific instances?

<comment><USER26> I think it was specifically Amazon not releasing their changes.

Maybe AGPL would cover them and force the release, but if Amazon stuck their heals down it would be an expensive legal fight. My guess is that it was just easier to change the licence used going forward to one that is more explicit and unambiguous about the matter.

It was my understanding that AGPL was supposed to cover this specific type of use, so would also be interested in know if there is a real problem or if the licence change was simply to make the point without needing to go lawyer-to- lawyer with someone in possession of Amazon's resources.

<comment><USER28> I'd actually be kind of surprised if Amazon did actually use it - most of the big tech companies are allergic to AGPL, and e.g. Google does not allow it to be used at all, even internally.

<comment><USER26> _> I'd actually be kind of surprised if Amazon did actually use it_

They did, which is how this discussion started.

Until 4.0.4 / 4.1.5 MondoDB was released under the AGPL licence. Upon those releases it switched to SSPL (which IIRC is APL plus extra "commons clauses"). Amazon have stopped using MongoDB as they do not want to (or for some reason are unable to) abide by this new license, but had previously been happy to use the code under [their interpretation of] AGPLv3.

<comment><USER28> I haven't seen a source clearly saying that Amazon had been using MongoDB - <USER2> thought the DocumentDB release last week was the first MongoDB product they offered?

EDIT: and searching HN comments, there's multiple people claiming AGPL is entirely banned inside Amazon too

<comment><USER26> In which case I don't see why this is such a big issue. Amazon couldn't use it before the change because of their licence use policy, and can't after the change either. So the change represents no change in that respect.

Implementing an interface compatible with something that you can't use for licensing reasons is no biggie. Other projects, Free/free/OS/commercial, do that sort of thing all the time.

I wonder where the problem that drove the change actually was... RH dropping it from their distro _is_ an issue related to the licence change, but I don't get the impression that was the intended target.

I should probably find time to dig back into the details, as I feel I've missed something notable.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> It is a good read, with good insights. The conclusion - "This tradeoff is inescapable" is true only to the extent that a new model for open source does not arise. Stepping back a couple thousand feet, open source is an amazing thing - a bunch of people alone or in collaboration, building great things which other people then use to build other ... etc. If we can find a way to sustain this it would be great.

It is to me absolutely clear to me that Amazon is benefiting from the work MongoDB has done, and without commensurate compensation. (Is anyone proposing Amazon does not benefit?) And having watched Microsoft embrace, extend and extinguish way too successfully, it is at least a concern that the effect of Amazon's action will be to the long term detriment of MongoDB.

This to me is the problem that must be solved. One possibility is to modify the OSS model and licenses by creating a distinction between the members of the community and non-members like Amazon and Apple. If you want to use any OSS software (with the new license) then you must become a contibuting member of the community. If you don't want to be a member, then __NO __OSS software is available to you. In other words, Amazon could not pick and choose which OSS to use, but only to be a member of the community with all the benefits or not.

I'm not saying this is the answer, but I am saying this is the problem we need to solve.

OSS is an ecosystem - one that should and must protect itself from predators.

<comment><USER30> I see arguments like this a fair bit, and I'd like to explain why I'm not at all convinced.

Your position is entirely predicated on the assumption that we must protect Open Source companies above the freedom of users/developers, which does not fit my beliefs on what FOSS exists to do.

If MongoDB Corp goes away because everyone is using the AWS version, I would be sad to see an Open Source company end, and would feel bad for the people who lost their jobs, but I wouldn't rewrite the licenses to be Open Source Except Big Bad Cloud.

FOSS licenses exist to encode a somewhat overlapping set of moral philosophies, and if a particular company (or companies) aren't able to monetise around those philosophies, they have made a strategic mistake of some kind.

The response to this should not be for the VCs behind these companies to dilute the essence of FOSS until it can be used to trap users/platforms. That would lead us to a world where we have replaced the monopolies of proprietary software with monopsonies for "open source" companies, and I have zero interest in that world.

<comment><USER29> Good points, and I may not have said this well, (and here's the obligatory but ) but... \- I am not proposing to "protect OSS companies over the freedom of ...". Rather I am attempting to explore a way to provide a boundary between the entire OSS community (users/developers, etc) and those companies that attempt to exploit that community. As others have pointed out, there are many companies that make a contribution to open source on a generous basis - Microsoft, even FaceBook by golly. \- I don't think the distinction there is "Big Bad Cloud", it is between those who help build and maintain open source and those who exploit it.

The goal to me is that the people who have created the incredible thing we call OSS should have a reasonable expectation of sharing in the benefits.

<comment><USER30> I would love it if more companies would get involved with FOSS communities, either by sponsoring work, or getting involved directly, but I would still argue that it's against the spirit of FOSS (and the letter of most licenses) to try and force them to.

When we choose to put our software out in the world under permissive licenses, we can't really turn around and complain when people make use of it in ways that are beneficial to them. On that basis, I object to the use of the word "exploit" in its negative sense.

Edit: I'd like to add one thought - there are different groups of people who could benefit by greater engagement from large corporate use of FOSS. Two that come to mind easily are the funded startups trying to find viable FOSS business models; I admire their optimism and their goals, and wish them luck. The second is individuals and small groups who tirelessly maintain incredibly important things that the rest of us take for granted and have to fight tooth and nail for every grant, every hour of their own spare time and every hour of their employer's time, to keep those things going for us. If I have to choose a group to care about supporting, it's definitely going to be the latter, for whom I have immense respect, undying gratitude, and sadly insignificant donations.

<comment><USER29> I agree your sentiment in general and especially with the last sentences ... It is one of the reasons I'm interested in trying to find some way(s) that we ensure they (the individuals and small groups) have some appropriate reward and that they are not exploited. I'm really not familiar with mongoDB and I don't use it, but I suspect that it started out as a person or small group that grew and grew and helped many people until ...

But perhaps exploit is too strong a word? It certainly seems that at least Amazon is acting as a bad citizen in this case by taking more than they are giving back. And it is within the realm of possibility that they will damage this project - the EEE syndrome is one possibility.

But yes to the respect, gratitude and sadly the insignificant donations as well.

<comment><USER31> Not to detract at all from your point, but Mongo (10gen) was very, very well- funded out of the gate, and the original idea was a platform-as-a-service built on open source apps before they pivoted to the open source database idea.

</comment></comment></comment></comment></comment></comment><comment><USER32> I work on an open core business model, and we spend a fair amount of time thinking about ways to prevent third parties from stealing our lunch.

CockroachDB has an interesting model, where they've tried to closely couple their open source and premium products. This coupling makes it harder for third parties to build against the open source and even easier for enterprises to use it.

Do people here have examples of companies that are taking innovative approaches to the licensing/OSS question?

<comment><USER33> But why did Red Hat succeed then? (this is a genuine question, I'd have guessed IBM would re-package RH's products, and Oracle failed with their Unbreakable Linux)

<comment><USER34> To put it succinctly, Red Hat doesn't sell Linux, they sell expertise in Linux.

<comment><USER35> Arguable this is what MongoDB, Inc. sells as well. A big part of their package for enterprise clients is optimization and consulting services.

<comment><USER36> Consulting is not the main driver of Red Hat revenue, the main thing Red Hat sells is Support.

Support is something enterprise customers want, and they will sign yearly contracts to get it. In return, if/when they have a production issue, 0-day vulnerability, etc, they have someone to contact (or may have contacted them!) to help them resolve the issue. And Red Hat has experts in both support and engineering, meaning resolution can be anything from a config change to a rapidly released patch. Happy customers renew year after year.

I work for Red Hat Consulting. This is a very different beast, consulting involves selling lots of short to medium term projects with the occasional long project, then trying to optimally staff those projects. You only get revenue while consultants are on the ground. It's not surprising to me that an open source company that relies only on consulting wouldn't be sustainable.

</comment></comment></comment></comment></comment><comment><USER37> Mostly FUD of a supposed opensource monetization debacle on the aftermath of Amazon DocumentDB.

Not every opensource monetization scheme is the same. Mongo and Gitlab are not the same. One is mission-critical production software, the other is a productivity tool (which can become critical, but in a different manner), thus different ways to monetize. Hashicorp, Canonical, Mesosphere and NodeBB are not nearly the same. Why put everyone on the same pot?

Opensource is not an industry. Opensource is a guarantee, a certificate of transparency. Opensource is global-scale collaboration. And much more.

Neither is everyone _moving everything_ to fully-managed PaaS, at least not in the way described by the OP, who assumes a lot of givens there. Many use cloud infrastructure, but not all the services, some have private clouds or other hybrid setups.

Application platforms are constantly changing, why now assume Mongo or any other opensource models are doomed? MongoDB Inc. is a public company and is perfectly capable of defending their bottom line against a magnificently sized but over-committed competitor like AWS. Mongo has NOT done a good job with their PaaS or enterprise tooling so far, competitors have popped up, so now they have to up their game, that's all.

To underestimate OSS monetization is very presumptuous. To compare musical recordings, an end to itself, to infrastructure mission-critical software is downright stupid.

</comment><comment><USER38> I don't like the assertion that the only thing that was valuable on CD's was the convenience, not the music. I'd argue that the copyright itself is the reason the music industry had pricing power. As everyone knows, they lost the pricing power with the rise of piracy platforms and it became too costly to try and keep the market cornered as services like Spotify and Pandora started to make deals with several labels. At some point the major labels had to throw their hands up and and capitulate. It's worth noting however, that the most powerful artists- people like Taylor Swift and Garth Brooks retained their distribution rights and did not capitulate for a long time. This is further evidence that the copyright is what creates the shortage that creates the pricing power.

It's really no different from the pharmaceutical industry. The cost of making the first pill of a new drug is billions of dollars. The cost of the second is basically zero. Yet drugs are extremely expensive because the companies that develop them have complete pricing power for several years because nobody else is allowed to manufacture that drug.

I think the point he's making whether directly or indirectly, is that MongoDB made a miscalculation in open sourcing their software at all. I would agree with that except that one would have to wonder whether there is anything so unique about MongoDB's software that would enable them to exert much pricing power. In other words, would MongoDB risen to the level popularity they did if the software was not open source?

</comment><comment><USER39> MongoDB is choosing a dinosaurs business model, and it's going to hurt them and their ecology.

Mongo the org should play MongoDB like Google does Kubernetes, Golang, Chromium, etc. Have your people in there, funded, steering the project as 'FOSS' while you release actual products.

Mongo dropped the ball by having no on-ramp product like GCPs Firebase. Their Cloud provider hate is just a flailing reaction to bad business and existential fear.

Stop being a crybaby when someone makes a few forms and buttons that spins up a vm with your DB software running. Of course cloud providers would want a tight integration with their systems.

Managed Kubernetes on AWS makes k8 stronger, managed Firecracker on GCP and Azure makes Firecracker stronger.

<comment><USER40> The article mentions that MongoDB already has its own hosted database service, Atlas.

<comment><USER39> It does, I've used it, I even have the socks, but it's a managed Database product. It's not equivalent to Firebase, AWS Lightsail, Digital Ocean One- click, etc. So a new MERN developer isn't going to gravitate toward that.

It's more like AWS RDS for MongoDB.

<comment><USER41> [https://www.mongodb.com/cloud/stitch](https://www.mongodb.com/cloud/stitch)

</comment></comment></comment></comment><comment><USER42> I think Stratchery made a mistake in think this is about open vs closed source, but rather it's down to Amazon's desire to own core infrastructure.

Amazon wants to have an offering in every major database category. Whether you're open source or closed source, it's safe to assume if you get decent marketshare Amazon will come after you.

Even if MongoDB was proprietary Amazon would have built a competitor in this space.

</comment><comment><USER43> This whole thing is a race as software itself gets better and better. Just think about how hard it was to run things 5 years ago before the rapid rise of containers and orchestrators. One person with Kubernetes can easily run a large cluster with hundreds of applications, even with private owned hardware. And this is all free now.

Being ahead of the curve with proprietary products is a viable business _but just not as big_ as these companies want it to be. Meanwhile there are thousands of smaller boutique software firms solving problems and making great profits.

</comment><comment><USER44> Why can't MongoDB can't compete with AWS? Aside from cloud vendor lock-in, and economies of scale that AWS has. Curious if anyone here has experience with hosting using Mongo's enterprise offering. The article makes the point that Amazon is targeting a lower version of the API, can't the enterprise version compete on features?

<comment><USER45> Other than multi-document transactions, many of the changes to MongoDB since 3.6 are to do with performance and scaling - this is AWS' bread and butter.

Something to consider is how many applications depends on cutting edge database features. Developers often consider a database an object persistence mechanism whose details are to be tidied away. See, for example, the emphasis on database portability in ORMs.

MongoDB's most effective enterprise offering is support, in my opinion. They know their database well, which can make a big difference if your company is heavily reliant on it.

I suspect for many users though, AWS support will be good enough. Presumably, that's the danger to MongoDB.

<comment><USER46> In the spirit of complete transparency, I work at MongoDB. Depending on users' specific needs and the features of MongoDB they use, the differences could go quite a bit further than 'just' support. Some of the important differences to keep in mind include regional availability and approaches to resiliency (Atlas allows you to scale beyond a single node and offers multi-region clusters; DocumentDB limits you to a single primary), role-based access control (DocumentDB currently only supports user that has full access to all databases in a cluster; MongoDB allows fine-grained control), freedom from vendor lock- in (With MongoDB you can always choose to host your own clusters whereas DocumentDB does not afford you this option). These are only a few of the differences between the hosting platforms, on top of that, you would, of course, be limited to an incomplete set of features ([https://docs.aws.amazon.com/documentdb/latest/developerguide...](https://docs.aws.amazon.com/documentdb/latest/developerguide/mongo- apis.html)) compared to MongoDB 3.6 and you would be missing out on improvements available in MongoDB 4.0 and future versions.

</comment></comment></comment><comment><USER47> I find it interesting that the price of storage has essentially flatlined for the past five years, although the cost of hard drives have decreased by about 50 percent over that same timeframe dollar-per-gigabyte ([https://www.forbes.com/sites/tomcoughlin/2017/12/20/digital-...](https://www.forbes.com/sites/tomcoughlin/2017/12/20/digital- storage-projections-for-2018-part-1/#41e9a3a13a20)).

Innovations at the 'business' layer may be the best way to compete with AWS, in the way that it captures a large chunk of value generated through OSS. Decentralized cloud platforms essentially take the principles of open source and apply them to the very infrastructure on which software runs.

At Storj, for example, we have an Open Source Partner Program that attempts to solve the 'Amazon Problem' by enabling any open source project to generate revenue every time their end users store data in the cloud.

Storj tracks usage on the network and returns a significant portion of the revenue earned when data from an open source project is stored on the platform. Critically, this enables open source projects to derive sustainable revenue from usage, whether by commercial customers or non-paying open source users.

In my opinion, this can help drive and support the next wave of Open Source monetization models (essentially through this concept of 'Commoditize Your Complement" \- where the complement is cloud consumption)

<comment><USER48> Perhaps this is a good idea in theory, but it's lacking in implementation. Having used Storj in the past, I've found it to be the least reliable service I've ever used. The SLA excludes events beyond your control, which sadly includes the availability of your storage network. I wouldn't say this solution is even close to being production ready.

<comment><USER49> Storj has spent the last year rebuilding the entire network after hiring JT Olio (Director of Engineering) Ben Golub (Interim CEO, previously CEO of Docker).

The V3 Network is leaps and bounds more performant and economical than the V2 Network. It is compatible with the S3 bucket-object store and is an easy shift for applications already using S3 as an object store layer. You can speed test it vs S3 using the ./cmd/s3-benchmark tool in our distro.

Try it out for yourself: [https://storj.io/blog/2019/01/getting-started-with- the-storj...](https://storj.io/blog/2019/01/getting-started-with-the- storj-v3-test-network-storj-sdk/)

</comment></comment></comment><comment><USER50> Amazon has for years been stealing from merchants on their platform and AWS is just another part of their platform. They are everything we caution people against when they depend on a single API like being a superfluous Twitter client getting crushed, just a much, much larger API.

In Mongo's unfortunate case they couldn't stop people from deploying to EC2 before Amazon determined it was worth stealing, but it doesn't even have to be software you use on EC2 it can be your software too.

They copy products from third party vendors selling on Amazon -

[https://www.bloomberg.com/news/articles/2018-09-27/amazon-s-...](https://www.bloomberg.com/news/articles/2018-09-27/amazon- s-copy-cat-products-targeted-as-eu-quizzes-smaller-rivals)

[http://fortune.com/2016/04/20/amazon-copies- merchants/](http://fortune.com/2016/04/20/amazon-copies-merchants/)

They even copy SaaS hosted on AWS if the number are good -

[https://www.theregister.co.uk/2013/03/08/amazon_copies_partn...](https://www.theregister.co.uk/2013/03/08/amazon_copies_partner_products/)

<comment><USER51> [Meta warning] This comment is being downvoted because of the incendiary language, but it is actually quite insightful. I wish the author changed some of the words used :(

</comment></comment><comment><USER46> Michael from MongoDB here. Amazon, Microsoft, and Google are certainly big players in this field, and common wisdom is that they are best qualified to scale, but in this case, we have a clear counterexample. DocumentDB clusters are limited to a single region of AWS. MongoDB Atlas clusters can span the entire globe with low-latency reads and writes in multiple regions. In terms of pricing, DocumentDB is cheaper when you choose to go with 2 instances. AWS achieves this by shifting high availability to the storage layer which in turn means that any failover could require between 1 and 2 minutes to happen - <USER3> compares to seconds that this would take with MongoDB Atlas. If you go with the default DocumentDB configuration and use 3 instances you end up paying a premium between 20-35%. With this in mind, it really depends on your use case whether DocumentDB ends up being cheaper for you. In terms of reliability and the hosting service is global, Atlas currently outperforms DocumentDB.

</comment><comment><USER52> This discussion is new because AWS and others are new and growing rapidly and it's a huge mistake to conflate it with conventional discussions and strategies about open source.

The threat is not just to open source but also entire categories of software and hardware.

The situation is so dire that you may create a product that does 10Gbs or something else and AWS offers 5Gbs but with automatic snapshots, high availability, scalability and distributed out of the box, and because of ease of use, access, near free management and scale users will still prefer AWS and your market will be limited to a extremely tiny subset requiring some specific niche and willing to configure, roll it out and maintain on their own.

This completely changes the incentives to create, because to compete you now need to create a 'cloud native' product that leverages AWS and other clouds. Which means a transformation of traditional open source and entire categories of software as we understand them to something new.

</comment><comment><USER53> How easy is it to migrate to or away from a cloud service like AWS ? I think the end-game for these cloud giants is to lock you in, so that you simply can't switch to a commodity provider.

<comment><USER54> When we embarked on our migration _into_ AWS, we thought about this pretty carefully. There wasn't _anything_ that we couldn't move in a year. That provides a sufficient backstop (IMO) to anything becoming untenable in the AWS ecosystem. Most everything could be moved in a handful of weeks of effort, or at least enough parts to achieve the reason to move.

AWS is still in a battle for market share; I think they're extremely "friendly" to their customers at this phase of the game. Will that change in a half-decade or decade? Maybe, but I think they're earning their profits now and likely to continue to do so.

<comment><USER55> At scale you need to move out of the cloud. Once you hit a certain point there is no economic gain.

<comment><USER54> That is almost surely true at extreme scale. The interesting question is whether that's true for 0.1%, 1%, or 5% of companies. (I think it's on the lower end of that range somewhere, provided the 5% scale cases are willing to be smart about their hybrid strategy.)

<comment><USER55> Was at a startup around 2k nodes in AWS. Bill was over 400K on average a month.

When purchasing RI I saw 800K a month.

<comment><USER56> > When purchasing RI I saw 800K a month.

I don't understand. Can you please clarify?

<comment><USER55> When buying reserved instances ( 3 year reserved ) the normal 400k spend was doubled to 800 thousand that month

<comment><USER56> Ah, thanks. What was the monthly spend after the RI purchase?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER51> How would it be different if whole of MongoDB had a proprietary license? Amazon would do the same thing with the same effect.

Open Source is a red herring here - the problem is with selling software when AWS sells "performance, scalability, and availability."

<comment><USER43> It's unlikely that the product would have as much usage in the first place to get any attention, nor would the protocol be open-source for AWS to host or build its own version. That's a critical difference compared to proprietary software, in which case AWS would be a customer and the vendor would be just fine.

<comment><USER51> Why would AWS be a customer if Mongo was entirely proprietary and not when it is mostly Open Source?

<comment><USER43> Because open-source is free, that's the big difference. Why would they pay for something they don't have to? There's barely anything in the enterprise edition that's worth paying for, especially when most of it is operations tools that AWS doesn't need.

<comment><USER51> If it was proprietary it would not be free - why should they pay then and not now? I am arguing that they would not, just like they don't now - there is no difference. The problem is with selling software - not with Open Source, if it was entirely Open Source - then they would not have to pay and they would use it.

<comment><USER43> What? If it's proprietary or closed source then the clouds have pay for to legally offer it to their customers. They can't just steal it without paying.

This is extremely common. How do you think Windows, SQL Server, Oracle, Redhat Linux, Spark Enterprise, Cloudera/Hortonworks, and lots of other products are offered by the clouds?

If there's enough demand for proprietary software then the clouds will do a licensing deal directly with the vendor, however MongoDB gave away too much of the product as open-source so there's no reason to pay them. That's the problem. The other issue is that if it was never open-source then nobody might even be using it in the first place, so it's a hard balance.

<comment><USER51> If it is proprietary they don't have to pay - they can always write their own - just like it happend in this case. If it is economic to write their own now - it would also be economic to write their own when Mongo was entirely proprietary. There is no economic difference in these two situations. But maybe you believe that it was not economy that dictated the rewrite - <USER4> rather it was a kind of tantrum - "others can have it for free why can't we!!!???". I don't think it was an emotional decision.

<comment><USER43> If that was feasible then they would already have SQL Server and Oracle APIs offered using their own tech instead of buying other vendors. Aurora MySQL and PostgreSQL still uses the open-source code layer on the top and just switches out the storage engines, and it's most likely the same here by using parts of actual MongoDB with a different storage engine.

<comment><USER51> Isn't the MongoDB code covered by their Server Side license [1]? AWS could not use this legally.

1\. [https://www.mongodb.com/blog/post/mongodb-now-released- under...](https://www.mongodb.com/blog/post/mongodb-now-released-under-the- server-side-public-license)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER57> I'm surprised utility-based software pricing isn't being pursued more. The cloud providers are the natural point to bill.

Currently they sell computing resources wholesale to others who then somehow need to monetize it. (I mean raw cycles, storage and bandwidth are worthless _on their own_ )

As a software user, paying a simple usage-based fee that includes compute, storage and software fees would be ideal.

As a cloud provider having people develop product that could be used to sell their own base product _at no development risk of their own_ would be advantageous.

Also as a software development group not having to deal with the complexities of scaling the platform can have advantages.

</comment><comment><USER58> The next open source model I see being successful is one which open sources it's code, but keeps models proprietary.

Say I build a system for detecting of pigs leave their pen. Open sourcing it lets people build models for sheep, cows, and chickens. With resources I improve those models and provide additional tuning for onsite locations. There is an open source solution with code and community models, but I provide an "accuracy guaranteed", upgrades, and maintainence.

We can even lease the hardware (cameras, field GPU boxes, etc.), want a new model for kids in a school yard, no problem! I'll do that for you, it'll be $100k and I retain rights to the model.

</comment><comment><USER59> _> No, they are still not selling music; in fact, they are beating piracy at its own game: the music industry is selling convenience. Get nearly any piece of recorded music ever made, for a mere $10/month._

I find it more convenient, to have a DRM-free backup of the music I paid for. Sure, streaming is useful, but not when it's available in the form of rent only. That's why I'm using Bandcamp and not Spotify.

</comment><comment><USER60> Is it possible to let people use software freely, but if they make money from a service that uses it, you have to pay for it? This seems to me to be the fairest approach, particularly in a hosted environment. Think of something like codepen.io but instead of premium pricing they only charge you when you process payments. In a way, this is what the App Store and Play Store are already doing, no?

<comment><USER61> Unreal engine charges 5% royalty for projects using it (waived for the first $3k/quarter).

</comment></comment><comment><USER62> My question - how badly did Amazon get burnt by using Oracle?

In databases in particular Amazon seems to be on a huge kick to not have to pay anyone else. Even if they end up with a bunch of quasi-overlapping products (SimpleDB, DynamoDB, MongoDB) they just seem very aggressive here. At this rate they are going to have 10+ database offerings in the future.

<comment><USER63> It's easier for AWS for accommodate all their customer's needs (MySQL, MongoDB, Postgres) and reduce the cost of switching than it is to convince them to rewrite an application or legacy application to leverage say DynamoDB. The benefit of DynamoDB is great, but it's just one slice of the computing pie.

</comment></comment><comment><USER64> Open source works if you:

\- Treat your OSS projects like MARKETING tools, not revenue streams.

\- Offer a freemium version of what you produce (e.g., offering a "Pro" version that's well-maintained and adds valuable features).

\- Back your projects with services (e.g., consulting, fast support, "off the shelf" implementations, enterprise workshops, etc.).

\- Back your projects with paid support.

\- Scale your performance expectations of the business to the cash flow of your services.

If you want to make money off of OSS, you have to run a business. It's the responsibility of the project's creators to deliver products and services utilizing their technology to provide something better than others can (and charge for it).

Otherwise, keep it closed source.

<comment><USER65> Indeed, that is NodeBB's business model (and the same model as many other forum software companies, come to think of it).

We provide fast support to anyone that wants it, and peace of mind to companies that utilise our product. We are, in essence, domain knowledge as a service.

Many people have tried to undercut us, which is a great way of keeping us honest, but there's nothing quite like getting support from the guys who wrote the software :)

My only regret is that I cannot support everyone who wants to use NodeBB, for a price point accessible to all.

</comment></comment><comment><USER66> I'm the furthest thing from a lawyer, but wouldn't it be nice to say my software is open source, and you can use it in your software, but if the software product you're selling with my software in it is making over $X, you have to pay $X?

Or, even more generally, is there a legal way to protect your code from being taken advantage of by the top 1% of companies? Could that become popular?

If I help a million developers and companies make money, fine, but it is immensely frustrating how the Amazons and Googles of the world reap so much of the benefit.

</comment><comment><USER67> I don't see why big companies like Google, AWS and the like wouldn't fund open source development, precisely because they have realized great returns using those softwares to reap monetary benefit. If I were a CEO and my core business was built on OSS, I would allocate budget to help the projects used within my organization. It's just common sense to do so. Reality might be different but then that makes for some really short sighted decision making on behalf of those companies.

<comment><USER68> Disclosure: I work on Google Cloud.

Actually, we do precisely this. Google contributes heavily to Linux, KVM, LLVM, and so on in addition to the open source projects we launched (Android, Chromium, Kubernetes to name some popular ones).

Our marketing team decided to highlight this on [https://cloud.google.com/open-cloud/](https://cloud.google.com/open-cloud/) which does an okay job. Feedback welcome, and I'll pass it along to them.

<comment><USER67> That's very good. Does Google also donate money to OSS projects they use? Postgres? Redis? uWSGI? Gunicorn? MySQL? I'd imagine they are heavily used in many projects within Google.

<comment><USER69> They aren't used.

<comment><USER30> Google definitely uses MySQL (e.g. [https://www.mysql.com/customers/view/?id=555](https://www.mysql.com/customers/view/?id=555)) and offers a MySQL deployment/management as a Service in GCloud. No idea what, if any, their contributions back to upstream have been, but I know they've been using it for important internal stuff for years, so I would be very surprised if, at the very least, no patches have come from out from the chocolate factory doors.

<comment><USER70> Google built and open sourced an entire horizontal scaling cluster management system for MySQL: [https://vitess.io/](https://vitess.io/)

</comment></comment></comment></comment></comment></comment><comment><USER71> Amazon has had a documented past of taking massively successful Open Source projects and adding their own bells and whistles to it and upselling them.

Amazon is the new Microsoft.

</comment><comment><USER72> So its like Mongo is being eaten by AWS in terms of its service offerings after it gains mindshare as DocumentDB is essentially a swap-out replacement for larger companies. That somehow smells to me as it erodes funding from its foundation in some way. I don't know.

<comment><USER46> Michael here from MongoDB - We're currently still running tests on users ability to change from MongoDB to DocumentDB. It may not be quite as simple as exporting and reimporting the data. Many features present in MongoDB 3.6 do not work in DocumentDB ([https://docs.aws.amazon.com/documentdb/latest/developerguide...](https://docs.aws.amazon.com/documentdb/latest/developerguide/mongo- apis.html)). Preliminary test results show that DocumenDB is closer to MongoDB 2.0 in its features (with some exceptions). That means people that choose to switch over will have to find workarounds and change their code to work with DocumentDB. We'll be releasing our analysis on this soon with more information.

<comment><USER72> That is definitely not good for my needs. I'll be sticking to Atlas over DocumentDB or simply plain Mongo latest. Thank you for the comment.

</comment></comment></comment><comment><USER73> The 'Why Software Should Be Free' case assumes the software exists at all. I think this is the case for a lot of common infrastructure software and I think these will continue to move to open source.

But without a license payment much software might not be available at all.

</comment><comment><USER74> Maybe the proper way to fund open-source is just governments, altruistic companies and users, not selling? To some extent all of those already happen but growing so slowly, funded open-source software % growth could be sped up.

</comment><comment><USER75> Everybody follows

Speedy bits exchange

Stars await to gl@ow"

The preceding key is copyrighted by Oracle Corporation.

Dupl@ication of this key is not allowed without permission from Oracl1e Corporation.

Copyright 2003 Oracle Corporation.

</comment><comment><USER76> I thought the speculation was that DocumentDB was running on postgres and its just the API that's compatible. Open source might have played a roll but wouldn't this move from amazon be just as possible with a closed source API?

<comment><USER77> I thought so too, it's similar on how BigTable also supports the HBase APIs.

</comment></comment><comment><USER78> The economic reality of building software is that it is enormously expensive. Yes, you could develop your own operating system, compiler, UI frameworks, databases, etc. Or you could use something that already exists and works and focus on creating something new instead. You'll never get around to building something new if you first have to reinvent countless wheels.

That's why there are only a handful of widely used operating systems, many of which are Linux based at this point and all of which depend on many small OSS components. It just takes too much effort to get to the same level of functionality. The two notable exceptions are Apple and Microsoft that both choose to maintain their decades long investments in their respective software stacks. Even Microsoft has recently joined the club and is now doing open source openly. Sound economics and it has done wonders for their valuation.

Another reality with software is that its value decreases over time. It inevitably becomes a commodity. Design, algorithms, and successful features find their way to competing products and inevitably one of them gets distributed under a very permissive license. As that happens, the way to differentiate and stay valuable (and relevant) is to improve what you do, how you do it, and how well you do it.

This is the economic problem MongoDB is facing: their added value is tanking and they felt they needed to make their already quite restrictive license even less permissive to be able to get more revenue from their users. This makes the product harder to use commercially unless you pay (which is intentional). However, this causes people to look for alternative solutions and causes many of them to find their way to competing products.

The predictable result: several competing products now offer more or less drop in replacement functionality with most or all of the technical features that made MongoDB so cool just a few years ago. Amazon just capitalized on that by launching their own (closed source) product.

The long term economic success of OSS is tied to its development community. This requires ongoing investments to happen. An OSS community is usually not a single company that owns the software but the collective of users and developers of the software that together 'own' the software and derive value from it. There are certain types of software projects out there that are so essential to so many companies that they thrive for decades and are pushed forward by companies and people pooling resources through donations, active contributions, etc.

This requires a pragmatic attitude to licensing. We just saw frenemies Google and MS join forces around chrome. That is not charity: they both have a big enough economic stake in that project to put their differences aside (which are considerable). The licenses are key to facilitating such communities between mutually distrusting entities like that. It fundamentally has to facilitate the software can be used freely by anyone; that is the basis for collaboration.

</comment><comment><USER79> The irony is that MongoDB brought this on themselves. They created a market for "like MongoDB, but reliable and secure" but were unable to deliver it themselves.

<comment><USER40> MongoDB has a fully managed service called MongoDB Atlas that runs on AWS (and Azure, GCP).

</comment></comment><comment><USER80> I'll be interested to see what Jepsen[1] makes of this. MongoDB traditionally lost a lot of data when there was a split-brain in the network. According to the post, AWS is a re-implementation of MongoDB v3. Will Amazon's implementation fare any better?

[1]: [https://aphyr.com/posts/284-call-me-maybe- mongodb](https://aphyr.com/posts/284-call-me-maybe-mongodb)

<comment><USER46> Michael here from MongoDB - I can't answer your question about DocumentDB and Jepsen, but there is a more recent analysis from Jepsen: [https://jepsen.io/analyses/mongodb-3-4-0-rc3](https://jepsen.io/analyses/mongodb-3-4-0-rc3). DocumentDB is built on Aurora, so the architecture is completely different.</comment></comment>


Open source Air Quality Test - <AUTHOR> http://www.instructables.com/id/Air-Quality-Test-Box/ A brief description at http://seeed-studio.github.io/Air_Quality_Test_Box/ <comment><AUTHOR> A brief description at [http://seeed- studio.github.io/Air_Quality_Test_Box/](http://seeed- studio.github.io/Air_Quality_Test_Box/)</comment>


Million requests per second with Python - <AUTHOR> https://medium.com/@squeaky_pl/million-requests-per-second-with-python-95c137af319#.j2eoj7oik <comment><USER2> "Hello world" is not particularly interesting. Make it do something simple, but fast. Like connect to memcached, get a random piece of data, spit it out.

</comment><comment><USER3> Why would you benchmark single thread performance?</comment>


Lazarus Version 1.6 - <AUTHOR> http://www.getlazarus.org/release/lazarus-1.6 <comment><USER2> It might be worth noting that 'getlazarus' is an independent project from the Lazarus IDE itself, it uses more up to date releases that are yet to be available and is designed to be much friendlier to use.

<comment><USER3> > much friendlier

I'll say. Just watching the video I felt like I had a peek into developer heaven. Pretty nice amount of polish there.

<comment><USER4> Now imagine being used to this in the mid-90's and then being dropped into UNIX CLI, vi (no vim on those days), Emacs and C.

</comment></comment></comment><comment><USER5> I like Lazarus a lot. I guess I should maybe develop some more GUI tools with it.

About setup on MacOSX: I think it could be easier by having it in Homebrew. Or as a self-contained app bundle. (I found a Homebrew Caskroom Lazarus package. But that seems not up-to-date? Also, maybe it should be in the main Homebrew tree?)

Edit: Maybe actually installing from here is easier: [http://www.lazarus- ide.org/index.php?page=downloads](http://www.lazarus- ide.org/index.php?page=downloads)

<comment><AUTHOR> This installer uses homebrew or macports. You get to choose:

[http://www.getlazarus.org/setup/?download#macintosh](http://www.getlazarus.org/setup/?download#macintosh)

</comment></comment><comment><USER6> I love modern FreePascal with Lazarus; I wish there were more recent books about it, but it's a wonderful language and IDE.

I really hope people here give it a shot.

<comment><AUTHOR> Although there is plenty of information out there, I am working on making tutorials, guides, a new language reference, and even some lexical diagrams in SVG:

[http://www.getlazarus.org/learn/language/lexical/](http://www.getlazarus.org/learn/language/lexical/)

<comment><USER7> The video on the Application Explorer shows a Lazarus IDE 1.7 ?!

Great diagrams, BTW ! Love the overall very modern look of the website.

<comment><AUTHOR> Regarding 1.7, I distribute builds based on the trunk revision which is usually pretty far ahead of the release versions. Thanks for noticing the website design.

</comment></comment></comment></comment><comment><USER8> I really like the fact that Lazarus is easy to build (even on my Windows system).

1\. grab the source code 2\. make install LAZARUS_INSTALL_DIR=C:\lazarus NOGDB=1 3\. done

Anyway, it's nice that we have an open source, cross platform Delphi-like environment :D

</comment><comment> open-source-ux A question for Pascal programmers: have you used Pascal for web development? And would you recommend it for web development? If so, how did you find its speed of execution? By web app development, I mean code that runs server-side and processes forms, or generates pages dynamically.

Web development is dominated by dynamic languages, but surprisingly few compiled languages seem to make headway in this space. The Go programming language looks like it might change that, but other compiled languages remain quite niche.

I know many people baulk at the idea of running an "old" compiled language like C or Pascal, but these languages seem (to me) to remain extremely fast and very light on resource usage. Two qualities that feel a bit out of fashion in todays web programming environment.

<comment><USER9> Yes I do, but not as old style PHP or ASP (html pages server side rendered). I use AngularJs for the front end and a CGI/Stand Alone servers written in Lazarus/FPC server side.

Please take a look at the Brook Framework, it allows developing REST applications: [http://silvioprog.github.io/brookframework/](http://silvioprog.github.io/brookframework/)

<comment><USER10> the brook framework doesnt seem very active

<comment><USER9> The GitHub repo doesn't, but Silvio is working privately on the new 2.0 version. Also there's a Google Plus community [https://plus.google.com/communities/101133820055678331036](https://plus.google.com/communities/101133820055678331036)

Anyway, the current version is very stable, I use it since a couple of years without a glitch.

</comment></comment></comment></comment><comment><USER11> This looks amazingly comprehensive and high quality for a non mainstream language. I wonder how difficult it would be to get something like Rust, Nim, D or Crystal to be able to call the FreePascal ABI and link with this.

<comment><USER12> It's status as "mainstream" is of course debatable, but Object-Pascal (aka Delphi) is #10 on TIOBE: [http://www.tiobe.com/tiobe_index](http://www.tiobe.com/tiobe_index)

Lots of "famous" software has been written in Object-Pascal: [https://jonlennartaasenden.wordpress.com/2014/11/06/famous-s...](https://jonlennartaasenden.wordpress.com/2014/11/06/famous- software-made-with-delphi/)

<comment><USER4> Just a pedantic comment, Object Pascal was actually developed by Apple with feedback from Niklaus Wirth as their main systems programming language (in the early days) and later adopted by Borland for Turbo Pascal 5.5 on MS-DOS.

</comment></comment></comment><comment><USER13> I installed lazarus (not from this website) two weeks ago and I was annoyed of the multi window (à la GIMP) thing. It seems it has been changed in this particular version ? I wonder, because the IDE in the video of the front page is showing a 1 window IDE.

<comment><USER9> By default it works in a multi-window envidonment, but if you want you can install the package AnchorDockingDsgn (from the Package->Install/Uninstall Package) that lets you "dock" the windows you want.

</comment></comment><comment><USER14> Tried it on my hi-DPI Thinkpad, needs hi-DPI support to be usable there. I remember being quite fond of Delphi when I was a student. No programming environment before or after Delphi has let me focus _only_ on the problem at hand, and no environment had made it so easy to create and reuse components.

</comment><comment><USER15> This looks like a pretty good equivalent to VB before it went all .Net and got a steeper learning curve.

<comment><USER16> Similar idea as old VB, but in no way equivalent. Much better language, much better component system.

</comment></comment><comment><USER17> Am I the only one thought it was a new release of "Lazarus: Form Recovery"?

<comment><USER18> Never heard of that. But FWIW: the name does actually reference a previous dead project.

</comment></comment><comment><USER19> This seems useful for cross-platform desktop UIs. Are there any Pascal compilers targeting iPhone & Android?

<comment><USER20> Delphi does. It's good, but expensive: [http://www.embarcadero.com/products/delphi](http://www.embarcadero.com/products/delphi)

</comment></comment><comment><USER21> I was really disappointed this wasn't Lazarus Form Recovery back from the dead. What is this project about?

<comment><USER9> This is an IDE for FreePascal.</comment></comment>


Researchers orbit a muon around an atom, confirm physics is broken - <AUTHOR> http://arstechnica.com/science/2016/08/researchers-orbit-a-muon-around-an-atom-confirm-physics-is-broken/ <comment><USER2> Related discussion on the same study: [https://news.ycombinator.com/item?id=12270483](https://news.ycombinator.com/item?id=12270483)

<comment><AUTHOR> Thanks

</comment></comment><comment><USER3> For protons, the muon-derived radius is 4% smaller than for the electron- derived radius. But for deuterium, the discrepancy is only 0.8%.

Is there some obvious scaling argument why adding a neutron should reduce the anomalous effect by a factor of 5? Actually, why is it that the deuteron's charge radius is so more than 2x the proton's? It obviously doesn't work like you'd expect something volumetric to work.</comment>


I wish I didn't know - <AUTHOR>

I don't believe in intelligence, I don't believe in IQ, I don't believe that one person is smarter than another person.
I know this isn't HN material, but I've been drinking wine and taking my Klonopins and figured I would vent.
I hate my knowledge but I love my knowledge.  I'm so unhappy and wish I didn't know.  I wish I was stupid and lived in ignorant bliss.  I wish I didn't have to drink and smoke to ignore it all.
I have "major depressive disorder" and I know where it stems from.  I know too much.  I read too much.  I want to learn too much.
I wanted to be a genius when I was a child, I really didn't care about much else.  I don't believe in the word genius anymore, because knowledge isn't intelligence.
I feel like there are many out there that feel the same.  I feel like you visit this site.  I know many of us have knowledge, but we don't know wrong from right.
I'm sorry you feel this way too, I wish that there was something that we could do.  I think it's hopeless, but please tell me what to do. <comment><USER2> A quickie google search suggests that alcohol and klonopin don't mix. Better watch that.

Depression is nasty business. You need to change things up. Be smart and only change one variable at a time: diet, supplements, sleep, exercise, the usual suspects. Measure, repeat, measure again.

Tell your shrink. If you don't have a shrink, get one. If you have one and you don't relate, get another one. There are good shrinks out there.

<comment><AUTHOR> Yeah, I know, I have a pretty high tolerance. Thanks for the suggestions, though, I will work on it. As for shrinks, I don't particularly trust them :/, but I will look into it.

Thanks for replying, I appreciate it.

</comment></comment><comment><USER3> You dont need a shrink, you just need to find yourself.

Sounds like you have been looking very much outside yourself when you should look inside instead. You seem focused on intelligence, IQ, and knowledge. All of those are likely to make you more depressed since you are not meant to be a robot. :)

Hope this helps :)</comment>


Show HN: Mobile Video Sharing App Prototype - <AUTHOR> https://invis.io/584N4KF46 <comment><AUTHOR> Curious to see what you guys think of this app concept. The idea is to bring home videos to mobile.</comment>


Cyber Dust - <AUTHOR> http://www.cyberdust.com/faqs.html

<comment><USER2> It's interesting that the interface is made in a way so as to make it difficult to tell from a screenshot who the receiver and sender is.

I don't have much faith in screenshot detection; it seems something like an arms race between screen shot app makers and the developers of this product, and it doesn't prevent a photo of the device's screen in any case, so it's pretty much moot except for possibly preventing screenshot behaviour from malware.

</comment><comment><USER3> Sounds like [https://telegram.org/faq](https://telegram.org/faq)

</comment><comment><AUTHOR> Marc Cuban is tweeting the hell out of this right now, thought it would be worth showing here.

<comment><USER4> "Show HN" is restricted to things that the poster has made (I assume you didn't make this?) so we took that out of the title.

<comment><AUTHOR> oh sorry about that, thought it was more like show n tell :)</comment></comment></comment>


The Capacitive Button Cult Must Be Stopped - <AUTHOR> http://ignorethecode.net/blog/2011/07/04/the_capacitive_button_cult_must_be_stopped/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+IgnoreTheCode+%28ignore+the+code%29

<comment><USER2> Its interesting to hear designers on a rant about capacitive buttons. Switches are the bane of most electrical engineers because they cost a lot and they have a finite lifetime. So generally they are thing that is going to 'kill' the product. And because they are both mechanical and have moving parts (in the non-capacitive variant) when they break the users just push harder trying to get them to work and that can crack traces on the circuit board and end the life of an otherwise working piece of gear.

Capacitive buttons can be 'tuned' (which is to say one can adjust how sensitive they are) somewhat depending on their antenna design and the ambient conditions. What is really hard for them is in a high emf environment (think lots of fourescents and shag carpets) there is so much charge available at your fingertip that even turned waay down they fire with the barest touch, reverse the circumstance like a modestly humid day out in a field somewhere and they are lucky if they can see your finger at all. If you're finger is wet (and thus charge will tend to distribute more evenly around you body) they are nearly worthless.

I recently saw some interesting 'piezo' buttons where they were effectively capacitive buttons but covered by a bit of piezo material so that you had to push on them to get them to activate. But while better in many ways, the cost difference between a button that is just a trace on the PCB (essentially free) and one that has a bit of piezo material in it (even if it only costs 2 or 3 cents) is easily someones salary when you're activating 500,000 devices a day.

<comment><USER3> The devices themselves have a finite lifetime. As long as the switch outlives the projected time to obsolescence of the device, it's fine. And I know there are switches out there which can do that...

What really irks me (and what I'm surprised to see so few people spell out) is that there's no tactile feedback on capacitive buttons (or microwave-like buttons). Tactile feedback makes every aspect of the UI profoundly better.

(Tactile feedback is possible on capacitive buttons... the first company which brings capacitive touchscreens with tactile feedback to market will make it huge (and the recent huge investment from Apple may have been into that technology). But no one has come out with a decent implementation yet...)

<comment><USER4> an idea for tactile feedback if used in low power version, well below "pain" level:

<http://en.wikipedia.org/wiki/Active_Denial_System#Effects>

Developed by CPI here in Palo Alto.

<comment><USER5> I thought you were going to say an electric shock. Although an electric shock would also use a lot of power and probably be a terrible idea just like microwave heating of the skin, at least the shock would provide fast feedback

</comment></comment></comment></comment><comment><USER6> Those buttons hit their maximum disaster level when installed on an induction stove. You know, the ones that are one flat shiny panel with areas that magically turn red and hot at the push of a button?

Of course, said buttons are always next to impossible to press correctly (except by accident), so the standard use case is to mash your finger onto it until some form of feedback occurs.

More often than not, that feedback comes in the form of 3rd degree burns as a result of mashing your finger onto a magically hot stove.

I hope there's a special little room in hell where the guy who designed that stove is forced to repeatedly burn his thumbs on it for all eternity.

<comment><USER7> _Those buttons hit their maximum disaster level when installed on an induction stove. You know, the ones that are one flat shiny panel with areas that magically turn red and hot at the push of a button?_

That's not an induction stove. An induction stove uses electromagnetism to heat a ferromagnetic cooking device positioned above a coil. The stove surface only becomes hot due to conduction away from the pot or pan. If you put nothing above the induction coil, nothing gets hot.

Here's a picture from Wikipedia. It's boiling water through a newspaper positioned between the induction coil and pot, with no damage to the newspaper: [http://upload.wikimedia.org/wikipedia/en/a/a6/Induction_Cook...](http://upload.wikimedia.org/wikipedia/en/a/a6/Induction_Cooktop_Rolling_Boil.jpg)

The kind of stove you're thinking of is a glass-ceramic resistive cooktop. It's just a piece of glass that sits between a big old resistor and your food. (Annoying about how easy it is to burn yourself, but very easy to clean!)

<comment><USER8> He probably meant smooth cook-top as someone else already pointed out.

</comment></comment></comment><comment><USER9> Another issue people don't bring up: the weather. Living in Seattle I frequently wore mittens. With the physical buttons it would not be a problem to operate the phone, with the touchscreen there is this long ordeal of pulling off the mitten to answer the phone. If it is raining (or rather, when is it not raining?), the rain will mess with the touchscreen, making it sometimes impossible to answer a call. You might say there is a solution: either cut off the fingers or sew in some conducting thread to the tip of the mittens. This doesn't solve the rain problem though.

<comment><USER10> Who answers their phone in the rain with the face up? Isn't that a little ridiculous? I think every piece of technology has its limitations. I could argue that button phones are loud, and I can't text with them during class or meetings. If you answer your button phone while it's raining, the rain will likely also screw up your button-phone... probably with more permanent damage than touch-screens.

Also, a lot of touch screen phones (iPhone in particular) have been adapted for modern use. With my Klipsch Image S4i headphones (or with the natural iPhone 4 headphones), you can answer/hang up calls using the headphone controls. I've yet to figure out whether I can activate voice control for dialing, but that'd be even better.

When I need to dial on my iPhone in the winter, thin cabretta leather (damascus d302 for example) works wonders, at the same time keeping your hands dexterous and warm. I feel a lot of the problems you're describing are more functions of outdated technology, than poor design in general.

<comment><USER11> > Who answers their phone in the rain with the face up?

Or put to break this question into two parts:

1\. Who would like to answer their phone when it rings, whatever the weather?

2\. Could the phone sometimes be the "other" way up when you take it out of your pocket?

<comment><USER10> I think you're misunderstanding.

1\. You already can, by using headphone controls. 2\. Sure (if you don't feel it out), but how does a buttoned phone eliminate this problem? The issue is not mutually exclusive to touch-screen phones, and I'd argue it's worse on buttoned phones, since you risk the water seeping in between the button cracks.

</comment></comment></comment></comment><comment><USER12> This is why I liked the older Android devices (as opposed to the new ones). Having physical buttons and a trackball were significantly better than both capacitive buttons and optical trackpads. Trackballs are significantly better than optical trackpads from a use-perspective. They work in all orientation, have finer grains of control, don't require awkward flicks to work, and have a much easier learning curve. The industry really needs to stop trying to the trendy thing and focus on things that work.

</comment><comment><USER13> I don't agree with his comment about the stove - Sure it's more fiddly than a real button or dial, but the ease of cleaning more than makes up for it IMHO.

<comment><USER14> For most purposes, I find the idea of buttons on a stove inferior to plain old knobs. I can see some merit to the idea of programming an oven to change temperature after a certain amount of time or some such, but a lot of stoves have buttons without any such capabilities.

Most stove buttons I've seen are membrane switches with plastic over them, presenting a smooth, easily cleaned surface. These seem to be the optimal way to put buttons on a stove.

<comment><USER15> I like the concept of knobs on stoves. But there doesn't seem to be any sort of standard so when one breaks or goes missing you're on the hunt for a replacement. Not so bad for a fairly new one, but when you have a 50 year old gas stove.... I'm sure visegrips makes good money on people that need pliers for their hobs.

<comment><USER14> I figured the knobs on old gas stoves would be roughly interchangeable, but had no particular reason for believing so.

As an aside, I'd rather cook on a 50 year old gas stove than most stoves I've used that had any kind of buttons. There's nothing quite like fire for cooking.

</comment></comment></comment></comment><comment><USER16> My guess is capacitive buttons have a lower failure rate than physical buttons. It's probably a decision born of cost.

<comment><USER14> I don't doubt it. The problem is that consumers are still viewing them as a high-end feature instead of the cost-cutting measure they are, so they keep showing up in high-end products with prices that could support the superior and more costly physical buttons.

<comment><USER17> Indeed it is. Data point: until this discussion I too believed that capacitive buttons are much more expensive and much more "high-tech" than physical buttons.

</comment></comment></comment><comment><USER18> tldr: _Did they never play a game in landscape mode, and accidentally back out of the whole game by merely holding the device wrong?_

I really don't get the anti-(physical-)button trend.

<comment><USER19> less moving parts, less overall parts, cheaper to make, looks cooler in the marketing...

</comment></comment><comment><USER20> The author mentions his experience with capacitive buttons that are too sensitive. I have the opposite problem on my phone—the buttons aren't sensitive enough.

I think that capacitive buttons are just too difficult to tune because the conditions they are used in vary so much. My phone doesn't even register touches at all if my hands are slightly sweaty.

<comment><USER21> Not to mention that your tusks dont register at all.

</comment></comment><comment><USER22> I remember when I bought an LG Chocolate when it first came on the scene about 5 years ago. It had capacitive touch buttons that were in such a bad place that if I was talking, and the button brushed against my ear it would hangup the call. It was awful and I vowed never again. Its the very reason I never got an iphone, opting for blackberry instead.

<comment><AUTHOR> Wait, I don't understand this argument. iPhones are one of the few phones that _don't_ have this issue.

<comment><USER22> If I can activate a touch button with my finger than why not my ear?

EDIT: I didn't know about the proximity sensors and other mechanisms until the replies below informed me. I still prefer tactile though :)

<comment><USER23> This is an example of Apple's design brilliance. They have a feature that _just works_ , and it's perfectly normal for users to have no idea why it just works or why other products that seem to have the same features are so frustrating to use.

Of course, the downside is that people sometimes buy a product that seems to be "as good as an iPhone," and they have no idea that their user experience is worse than the iPhone's, they just assume the iPhone works just as poorly as theirs.

<comment><USER24> I think this is a standard feature of most modern touchscreen smartphones and not some "design brilliance" relegated to only Apple devices.

I currently have to carry two phones, one is an Android device and the other is a Windows Phone 7 device, they both implement the proximity sensor and it works the same way as the iphone.

IIRC correctly HTC (back in the days of Windows Mobile 5) already employed this feature in their "slate" phones before the original iPhone was released. They then improved it by adding some rather unique features, like being able to flip the phone over (i.e. laying screen side up on a table) to silence/reject an incoming call.

<comment><USER25> I didn't use the HTC phone that you mention, but it would be interesting to know if the feature was implemented as well as it is in the iPhone. This feature has literally never failed for me in 2 years of using my iPhone (it sometimes gets false positives when the phone is in my hand, but it's not too bothersome).

</comment></comment></comment></comment></comment></comment><comment><USER26> How about capacitive buttons in elevators? It's very annoying if your hands are full and you can't easily find some other exposed body part to touch the button.

With normal buttons you at least have a shot at nailing them with an elbow or a foot.

</comment><comment><USER27> I would totally buy his book if I didn't find the prices of tech books to be completely absurd.

I remember how for 15 years VHS movies cost from $79.95 to $119.95 because they figured their only customers were video rental stores. The problem was they were selling each movie once for $80 instead of selling it 500 times for $20. Since fixing their flawed pricing model, far more movies are sold than before, to the point that rental stores have all but disappeared.

Could a similar thing be happening with books? Perhaps they are pricing for library use, where many users are expected to read one book. Or perhaps they are targeting captive audiences like in colleges where impoverished youth are shaken down.

Usability failure? Market failure? Or smart pricing model?

I'd buy a decently bound paperback as is being offered of this length and interest for $9.95 to $17.95. But I won't pay $35-44, not even close.

The question is, how many others are out there like me that represent lost sales. Maybe I am the only one. In that case, $44 is the right price. Or why not even $99.

<comment><USER28> I didn't set the price, but I will note that tech books typically only sell small numbers, regardless of price. It's a small target market.

<comment><USER27> It's only a small market if your publisher keeps telling himself that. It becomes a self fulfilling prophecy.

Sure there are tech books on antenna design for satellites that don't sell many copies. But there are other topics that are of far more board interest. Usability is one of them.

As of May, 2002, the U.S. Department of Labor - Bureau of Labor Statistics says there are approximately 562,700 computer programmers in the U.S. That's just one job title and the field has grown since then. There's also software engineers, web designers, programmer-analysts, etc. Easily a couple million jobs.

Paperback like you have there costs $2.87 to print in quantity 3000 in Singapore. There's a lot of flexibility in working with the price. I would experiment with it but that's just me. Presumably your publisher has experimented. But maybe he hasn't. Perhaps he assumes that the potential number of people interested is less than 2 million. Perhaps he thinks it is 100 or 200. I bet it's more than that though.

<comment><USER28> Fair enough. You make a good argument. Maybe lowering the price would increase revenue; I don't know.

</comment></comment></comment></comment><comment><USER29> As soon as I saw the title, I thought of my Samsung Omnia 7, heh. Back button is manageable, but search button has caused a lot of swear words!

</comment><comment><USER30> My Samsung TV has capacitive buttons - in the shiny black surround, labelled with tiny iconographs in very, very dark grey. It took me several minutes to even find the 'on' button when I first got it.

<comment><USER31> My Samsung monitor is like that. Navigating its on-screen menu is an ordeal. I have to look back and forth between the menu and the bottom right of the bezel, where the 'buttons' are, carefully placing my finger for each 'key press'. Forget about trying to do this in low light conditions. But - it was cheap.

</comment></comment><comment><USER32> Anything that vaguely pretends it's a button without being one deserves to burn in hell for all eternity. This includes touch screens, capacitive or otherwise, and any other such nonsense. If I'm meant to press it, make it obvious and use a button. If I'm meant to slide it, give me a slider. Turn? Give me a knob. How hard can it be, seriously?

As for engineers moaning about the life time of switches, puh-please. Show me one phone with buttons that has outlived its buttons. You can't? Didn't think so.

What really needs to go is this touchy cult. It's ridiculous. There are a couple of things where it makes sense. Angry Birds is not one of them. Anything else is just a useless fad. Especially touchy keyboardy crap that NO ONE can type on. Show me one person who can type 150WPM (and I don't mean swipe or predict or any such crap) on a touch screen and I'll go out and buy an iPhone.

<comment><USER33> What input device would be the best way to play Angry Birds, then? Having played the Mac App and Chrome App versions, I definitely think touch makes the most sense.

<comment><USER34> A custom device including one knob to control the angle and one (physical) slider to control the strength. I know this is stupid when thinking about a casual game, but it would totally make sense to me if my job was to "play angry birds 8 hours a day".

My point is that proper "physical" controls are better for almost every task out there. The obvious downside is that you can't make them appear and disappear depending on the current application being executed ;)

</comment></comment></comment><comment><USER35> One place I found that capacitive buttons have worked well is on the newer xbox models. The power and tray eject buttons are capacitive and it works well there.

<comment><USER36> Nearly broke the CD tray on my 360 when I was leaning over my TV stand to get at the wiring in the back, brushed the power/eject button with my knee, and jammed the tray into my leg. I'd rather a button.

The PS3, on the other hand, has its capacitive buttons on a surface that's at right angles to things that might brush up against it. Which is, IMO, the best design.

</comment></comment><comment><USER37> The worst offenders are android phones like my nexus one with capacitive buttons right beneath the software keyboard. Overshoot the space bar just a tiny bit? Hello home screen, goodbye app. Some apps handle this and you can just press back -- others lose all of what you just typed.

</comment><comment><USER38> what is a capacitive button?

<comment> mkr-hn A button that works on the same principle as the trackpad on your laptop.

<comment><USER39> Just to clarify, I believe mkr-hn means the trackpad itself, not the buttons on the trackpad. Most trackpad buttons these days are physical. The trackpad itself, however, is capacitive.

</comment></comment></comment><comment><USER40> What is a capacitive button?

EDIT: Oh, I see now. They are buttons that respond to electric impulse from the fingers on touchscreens.

The solution the author seems to be seeking is: everyone should use the old Nokia bricks?

<comment><USER39> The iPhone doesn't look like a Nokia brick, yet it has a hardware home button.

Similarly, the Nexus One had hardware buttons below the screen. On the other hand, the Nexus S uses capacitive buttons.

Hardware buttons are typically easier to press, have better feedback (even when compared to haptic feedback), and easier to find when your eyes are closed. Hardware buttons do not imply "Nokia bricks".

<comment><USER41> The Nexus One's below-the-screen buttons are capacitive. The Nexus One only has a mechanical trackball.

</comment></comment></comment><comment><USER42> as long as my phone's primary interface is a capacitive touchscreen, i don't see a problem with the buttons being capacitive as well. it's really just an extension of the screen interface, dedicated to a specific purpose.

yes, it sucks that i can't press the buttons on my phone with mittens on. but i wouldn't give up my capacitive touchscreen in exchange for a phone that operated solely by physical buttons.

<comment><USER28> The touch buttons aren't just an extension of the screen. For example, they don't provide visual feedback when they're active or activated, and when you're looking at the screen, they look like they're part of the bezel.

Note that while you're using it, you never accidentally hold your phone with a finger covering your screen. That's because you're looking at the screen. You know where it is. It's bright. It's easy to see its edges. It's the focus of your attention. The bezel around the screen, on the other hand, is not, but merely touching it in the wrong place will cause your phone to do unexpected things.

</comment></comment><comment><USER43> isn't the entire screen of a smart phone a capacitive button? It's pretty hard to accidentally dial my ex or launch the "fart noise" app in a meeting on it so why not link the "capacitive" buttons to the same software unlock as the device already has. (referring to my Android / HTC desire)

<comment><USER44> ed, I know what you mean -- it seems like an empty argument until you get one of these phones (specifically Android) with the fundamental buttons all touch sensitive.

Normal touch-screen phones all have context sensitive operations, for example you are playing a game and no where on the screen can you accidentally press the "Fart noise" app button or the "Hangup" button -- because they just aren't there.

With Android there are those 4 or so required buttons (Home, Back, Menu, Call/Search) and moving them from mechanical buttons to capacitive you CAN find yourself in the middle of a YouTube movie or game where your thumb just barely touches the back button, closing the app and taking you home.

Or as another user mentioned, you are on the phone talking and part of your chin or face (if you try and neck-cradle the phone while doing something) may hit the hangup button, menu button or Home button to suddenly start activating other things on the phone, ending or interrupting your call.

It is absolutely MADDENING.

The iPhone never suffered from this because it always had the one single mechanical button and the proximity sensor was good enough that when it got close enough to your face, all input on the pad was deactivated. Most of the Android phones that have mechanical core buttons don't suffer from this either for the same reasons.

It's once you get those damn touch-sensitive buttons on there... oh boy, there are a few times a week where you just want to throw your phone right into the ground and wish it a happy birthday.

<comment><USER45> FWIW I haven't had a single problem like this since I got a hard case for my phone (HTC Desire HD) with raised edges. Of course this changes the aesthetic quite a bit - a trade I'll make for the protection of the case - and doesn't help if your phone has no proximity sensor, but it is at least a partial solution.

</comment></comment></comment><comment><USER46> Stop putting fruit on your stove.

</comment><comment><USER47> Amen

</comment><comment><USER48> I absolutely despise the touch-sensitive 'wheel' on my iPod Classic. It's useless if I'm working in the garage with nitrile gloves on. I've resorted to using my elbow or nose at times.

It's even pretty useless _without_ gloves, if I've been doing anything that gets my hands dry, or had the iPod in my pocket so that it became relatively moist. I often have to breathe on my fingers before changing the volume!

<comment><USER49> I can tell you that that's the specific device's fault. My phone's capacitive screen works wet or with nitrile gloves.

</comment></comment><comment><USER50> Anything which is not tactile is bad if you ask me. That means capacitive buttons, touch screens etc. Even Star Trek shot themselves in an episode when a blind person had to use a panel:

<http://memory-alpha.org/wiki/Tactile_interface>

Now I'm not partially sighted, but I'm not always looking at the display.

</comment><comment><USER51> Sounds like /somebody's/ never used an iPhone.

<comment><USER52> iPhones don't have capacitive buttons. They have a touchscreen which while capacitive is much more sensitive, relatively expensive, and backed up with a IR proximity sensor and lots of engineering to make it just work.

They're just not related to this discussion.</comment></comment>


The Atoms of Programming - <AUTHOR> http://www.sicpers.info/2017/11/the-atoms-of-programming/ <comment><USER2> Regarding the conceptual modeling (a parallel concern to the author's desire for paradigms), Daniel Jackson [1] and his graduate student researchers at MIT have made great progress on clarifying the relation between concepts and purposes in software design recently, as well as beginning to collect an index (yet to be published). I wonder if an index exists for logical system paradigms?

These two lectures by Jackson are great:

SATURN 2016 Keynote: Rethinking Software Design - [https://youtu.be/LDny7VGLzTE](https://youtu.be/LDny7VGLzTE)

UMass Amherst CICS Distinguished Lecture: Daniel Jackson (Massachusetts Institute of Technology) [https://youtu.be/cNe6g0qczxE](https://youtu.be/cNe6g0qczxE)

[1] [http://people.csail.mit.edu/dnj/](http://people.csail.mit.edu/dnj/)

<comment><USER3> Thank you for sharing those; Jackson presented his ideas in a very clear manner. I especially liked how he broke down the evaluation and the accompanying examples. If one replaces users by other developers or even future self, the application of his ideas can lead to better system organization and consequently better developer experience.

</comment></comment><comment><USER4> I don't really agree that paradigms are more important than programming languages the way the author suggests here. Most paradigms are best captured in particular languages oriented around those paradigms. I can learn and understand functional programming paradigms much better in a functional programming language than in C. As a naive 18 year old many years ago who knew a bit of BASIC, C++, Java and Pascal I started to think all programming languages were "entirely similar". Being introduced to ML at university rather disabused me of that notion.

I guess my point is that paradigms are important, but that they are best learned in the context of languages that are designed around those paradigms and that learning them can actually be hampered if you are only familiar with languages that don't have good support for those paradigms. New paradigms are also often only really introduced and proved effective in the context of new languages designed around those paradigms. Dreaming up a new paradigm is rather an academic exercise if no language exists that can well represent that paradigm and can be used to build actual working systems proving the paradigm useful and effective.

<comment><USER5> I had a different process. I started with thinking (Basic, assembler and Java) that different paradigms were uniquely suited for different problems. Learning logic programming and functional programming changed this notion. It's possible to reduce a paradigm to explicit boilerplate code. In most cases you can reduce the boilerplate to almost nothing and get mostly idiomatic code without changing your initial approach.

The only thing left are non-functional requirements and while you could get a constant factor of slowdown, most compilers take care of 99% and you won't change complexities.

</comment></comment><comment><USER6> > But collecting the models, the different representations of systems > conceptually that can be expressed as software, sometimes called paradigms: > this is very interesting.

Isn't this another way of saying _design patterns_? I know the answer has to be "no", but I don't see why.

<comment><USER7> Unfortunately "design patterns" for most, means technical programming language patterns, rather than the patterns found in "problem domains" outside of computing that can be repeatedly and predictably modeled into code.

They do exist, but are very rarely known. Take object-orientation. Typically the primary pattern known is just object, class and inheritance. However, there are patterns that build on those to model the things, people, places, events and concepts, and the roles they interact in, and the constraints that limit them, in every "business" or real-world domain.

Why aren't they better known? I think it is because object modeling has entirely lost the battle today to data modeling, where data entities are acted on by external code organized using functional decomposition. It doesn't seem to bother most that for 45 years we have been struggling with the problem that doing so increasingly results in a "big ball of mud" as project size and complexity increases.

<comment><USER8> We maintain a lightweight platform alongside a legacy platform that is an untestable ball of mud. This resulted from rapid implementation of business demands over the years, along with a practice of addressing numerous data quality problem through hacks in components, rather than cleaning the data or using a sanitization layer to access it.

Lack of dependency inversion in systems like this is truly the road to ruin, as the system complexity grows so quickly in time, due to interactions, that eventually nobody really understands what it does or why it does it.

I suppose this is tolerable for some applications, but if you need to numerically validate it, it's a nightmare.

</comment></comment></comment><comment><USER9> "A language that doesn't affect the way you think about programming, is not worth knowing."

\- Alan Perlis

</comment><comment><USER10> I thought I was crazy for a second... I clicked on the link that scrolls into view when you visit the linked page, and it brought me to an article with the same name and roughly the same content: [https://www.startupon.net/2017/11/18/the-atoms-of- programmin...](https://www.startupon.net/2017/11/18/the-atoms-of-programming/)

I thought that was the article people were discussing and couldn't figure out why no one else was mentioning having trouble following the flow of the language:

      But the utility, the summary configurations of suggestions that speed on these programs,
      exist in fully separate condo and are merely (though the undeniable truth that here's
      that that you can maybe be additionally bear in mind is immensely worthy) translated
      into the digital or paper medium.

I guess it's a previous version which hadn't gone through proofreading? Pretty confused here.

<comment><USER11> Actually the whole site (startupon.net) is a bit bizarre.

There is an article on Milo which looks computer generated.

And then translated to English; instead of alt-right it has alt-correct!

And the phrasing is really weird.

<comment><USER10> Wow you're right... very very strange. I really want to know what's going on behind the scenes.

</comment></comment></comment><comment><USER12> Shouldn't the URL be changed to remove the #hash?

</comment><comment><USER13> This is linking to a comment?</comment>


Why We Need To Kill "Big Data" - <AUTHOR> http://techcrunch.com/2013/01/05/why-we-need-to-kill-big-data/

<comment><USER2> Newsflash: a two-word category descriptor isn't good at conveying nuance. It does pretty effectively convey the idea, though, that in whatever specific area of application, storing and processing data is a core technical challenge.

If you need a shorthand "way to describe startups that are dealing with large quantities of data", as a non-nuanced category, "big data" does a pretty great job.

</comment><comment><USER3> How about Big Time Cloud Data™?</comment>


Interesting sounding job in Vancouver for Python/C++ hacker - <AUTHOR> http://summify.com/jobs/backend-engineer

<comment><USER2> remote?

<comment><USER3> Yes, we're open to remote people</comment></comment>


Show HN: Does anyone want to help fix PHP..? - <AUTHOR> We're trying to build a wrapper to fix inconsistencies in PHP's core functions, but the project has kind of stalled for a month (personally, I've been crazy-busy with work).
Does anyone feels like joining the effort..?
This is the repo: https://github.com/nkkollaw/zubr/ <comment><USER2> Yeah, why not.

<comment><AUTHOR> There are many reasons why not, but I could use some help! :-)

You're welcome to fork the repo and/or join the discussion.</comment></comment>