PHP solves problems. Oh, and you can program with it too - <AUTHOR> http://nikic.github.com/2012/06/29/PHP-solves-problems-Oh-and-you-can-program-with-it-too.html <comment><USER3> Let's talk about the conclusions that are drawn in this article. I'll try to challenge them one-by-one.

> PHP is a great language to start programming!

No. PHP is not a good language to start programming. And I mean programming in a broad sense, not slapping together websites (which is not really programming, let's be honest). Let's look at people who know how to program, you know, the guys who participate and win awards at ACM ICPC and TopCoder. There are several such people among my friends. Exactly zero of them have started with PHP. Some have started with Pascal, some with Java, some with C++. None with PHP, even though it was available and widely used when they started. I wonder why.

> Once you started, PHP is also good for "real" programming (you know, object > orientation and stuff).

First of all, "object-orientation and stuff" is not a measure of how good a programming language is. So you'll have to bring a better argument to explain why PHP is good for "real" programming (whatever that term means). Saying "but Facebook and Wikipedia use PHP!" doesn't count :-)

> PHP is not as bad as they say. There are issues, like with every language, > but they rarely cause problems in practice.

Actually, it is. It has some deeper issues that lack of consistency in function arguments. Some of them really do cause problems in practice, like its retarded type system and lack of sane support for multithreading. But I'm not going to name them here because there are tons of articles on the internet explaining those issues. You have probably read some of them. If they did not change your opinion about the language, then I surely won't be able to do it.

<comment><USER4> I hate PHP too, but this:

> Let's look at people who know how to program, you know, the guys who > participate and win awards at ACM ICPC and TopCoder.

Is goalpost moving. He's not suggesting that PHP is a great language to start with if you aim to become a great algorithmic programmer, rather that it's a great language to start with if you aim to become a competent web developer.

> Saying "but Facebook and Wikipedia use PHP!" doesn't count :-)

But why not? Surely "X and Y outrageously successful projects use Z" is a valid argument for Z's power as a programming language?

<comment><USER5> It's an invalid argument because not all projects are alike. Facebook and Wikipedia are indeed very successful projects but they have a massive advantage over the types of projects I deal with in enterprise environments. For instance:

\- technical environment: the Facebook/Wikipedia/generally-any-web-startup architects get to choose their technical environment 100%; in most corporates you need to integrate with legacy applications and databases in a specific environment, often enforced by IT policy, and this imposes significant constraints on which languages will be feasible options

\- interoperability: for large, modular systems developed by disparate teams over decades with little or no standards or co-ordination, a statically typed language can be absolutely invaluable for ensuring interoperability and discovering usage (documentation is typically non-existent in these environments, as are tests, and the latter is seldom - often impossible - <USER2> retrofit); even for new systems, static typing can save a lot of time when developing and integrating new work across large teams, in my opinion

\- resistance: business and technical knowledge lives in developers who are part of an ancient stack, e.g. Microsoft or Oracle or Borland; switching to PHP or Python or Ruby etc. means convincing these people to learn very different new technologies (good luck - won't happen), figuring out how to interface with legacy stuff using a language outside of the stack, introducing new tool chains, etc.j

\- time & budget: even if the existing developers are keen to learn, it's tough convincing the project manager you need an extra month to go through the upskilling process and that you need to spend time researching interoperability options, and that inevitably you will run into future issues, etc.; the problem is most projects are run and budgeted for on a local cost benefit analysis and very rarely would the benefit of switching languages for one project be worth it (even though, in the big picture across multiple projects, it may very well be)

An observation: whenever this debate comes up on the HN, the proponents of modern, dynamic languages are invariably people working in closed environments where they have the freedom to set standards, do things right from the beginning (coding standards & reviews, tests, documentation) and the ability to make technology selections across the board. Often this freedom is not a characteristic of other environments, and consequently the language used in a one environment may be unsuitable in another.

</comment></comment></comment><comment><USER6> Oh, please. Stop it! Not another fucking PHP vs. the world thread on HN! C'mon kids, get off it!

Any number of us could name tons of very successful (profitable, popular, worth tens, hundreds and billions of dollars) companies that rely to a large extent on PHP.

And the same could be said about a dozen other languages and frameworks.

Be done with this shit, will you? Haven't you had enough?

<comment><USER7> I blame Atwood for trolling PHP yet again with this link bait. I'm deadly serious: he has a history of posting anti-PHP rants, then sitting back and watching his blog traffic grow.

</comment></comment><comment><USER8> No one is disputing that you can hammer a nail with a brick. Most of the criticisms around PHP revolve around the idea that it's better idea to use a hammer (with one claw side, and one hammer side)

Likewise, when you have a real problem that isn't needs to run on a $5 shared host, or written for $4/hour in China PHP is rarely a good choice unless you happen to already know it.

If I needed to solve either of the above two problems I'd choose PHP. I write a lot of PHP (mainly wordpress sites) and it's certainly workable, it's just annoying once you've used languages like C#, Ruby, F#, Scala, Clojure, or Python.

None of the problems with PHP are unmanageable it's like driving an old diesel car, you just remember to plug it in the night before if it's going to be less than 40 degrees.

<comment><USER9> _$5 shared host_

Modern shared hosting can actually handle long-running processes and complex frameworks that used to require a VPS. I don't have broad experience with it, but I did just deploy a client's site to webfaction.com, which supports Django, Rails, arbitrary long-running processes, JVMs, custom Apache configurations etc.... Pricing can be as low as $5.50/month there, and there are probably even cheaper services for those who shop around.

 _you just remember to plug it in the night before if it's going to be less than 40 degrees_

People in warm climates who have never seen electric engine heaters might not understand this.

<comment><USER8> Good point on the block heaters, I guess that's a cultural reference most likely to be picked up by Canadians.

It's especially bad for diesels as when they age even with new glow plugs it isn't enough heat to make the diesel ignite with out waiting 5 to 10 minutes if it isn't a nice summer day.

Yeah I've run a couple rails apps on dreamhost, it's becoming more common but you know for sure that PHP is going to be installed.

</comment></comment></comment><comment><USER10> it's interesting to read the comments here. Most of them go on bashing PHP because it's a terribly designed language. They're probably right, but they're totally missing the point, primarily because this is a very technical community.

I'm not a programmer. Yes, I can solve problems with code, I can whip up a webpage, I can talk to a database, I can use Jquery. But I don't know what lambdas are, I don't understand what LISP macros are all about, and I wouldn't know where to begin writing image recognition software.

But you know what? I get stuff done. And PHP helps me do it. Because I can make things without worrying about not having a CS degree, not caring how a compiler works and not having to set up a server from scratch.

If you look at all the sites out there making money and getting views I think you'll find that an awful lot of them are made by people like me.

<comment><USER11> But you do know what a function is? Or a class? Or an object? It is not like those are non-trivial already or that knowing what a lambda is needs years of studies if you understood these things.

The fatal flaw in the "PHP is simple"-Argument is that its actually not simpler than other things (I wouldn't say that its harder either). Sure, it gets stuff done (tm), but so do others, also without any deep knowledge. They may not be Lisps or Haskells, but Ruby and Python are coming close.

The problem I have with the PHP community is that "its so easy to start" seems to be their main argument. Wouldn't the world be a better place if we had an easy to start stack _without_ a shitty language?

<comment><USER12> The problem is that any popular "easy to start" stack attracts people who have no idea how little they understand. And then they start building things badly because they don't understand. Some of it proves useful to other people who don't know what they are doing. And before long the ecosystem built around that stack becomes a horror to behold.

This has happened with PHP. It happened with Ruby on Rails. (Before disagreeing with me, think about how much abuse of monkey patching happened, and how many have been bitten by it.) It happened with Perl back when Perl CGI scripts were the de facto standard.

So yes, it would be wonderful to have an easy to start stack that is popular that guides people towards doing the right thing. But human factors guarantee that any that get popular will go downhill over time.

(I've ignored the obvious argument that the same features that make you popular also make you worse. See the famous essay _Worse is Better_ about Lisp vs C for context.)

</comment></comment></comment><comment><USER13> I think PHP's problems are actually quite solvable without core language changes. The OO model is actually pretty good, there's even reflection functionality that's sufficient to do stuff like auto-generating docs and self-validating DTO objects. The issue are the "legacy" api's, and the primitive types. What's missing are object api's wrapping the primitive and legacy functionalities. Those could be built quite easily though.

You could have something like jQuery's $ function, but for PHP variables, that gives you an OO api on top of that value (especially now that you can use the -> operator on return values of functions without intermediate assignment). I wonder why nobody's built that yet. I suppose because those in the PHP community are all busy programming instead of meta-programming.

<comment><USER14> Do you mean something like this?

      function s($string) {
        return new String($string);
      }

      class String
      {
        public $string;

        public function __construct($string) {
          $this->string = $string;
        }

        public function __toString() {
          return $this->string;
        }

        // several helper methods like the following:

        public function toLower() {
          $this->string = strtolower($this->string);
          return $this;
        }

        // this would create lots of extra objects,
        // but leave the original unchanged
        public function alternateToLower() {
          return new String(strtolower($this->string));
        }
      }

      $username = s('ExampleUser');
      echo $username->toLower();

My concern would be the memory used to create several dozen extra objects. If this is indeed what you're talking about, is there any strong benefit besides convenience?

<comment><USER13> Yes, lots of memory, much worse performance, but it doesn't really matter. If you care that much about those, you're not using any interpreted language.

Besides, most PHP code is linear without much looping other than iterating database records. The overhead of such an approach wouldn't matter that much, and when it does you can always use the old way of doing things.

But you wouldn't need to create an object per call, you could reuse a singleton that gets initialized by a wrapper function to work on your current variable (using references). Fix($str)->replace("foo", "bar") is a syntax that doesn't require object instantiation or string copying. And the singleton could use the mb functions internally to be multibyte aware.

</comment></comment></comment><comment><USER15> As C++ has taught us, the solution to the errors made in a badly misdesigned language is not to continue cramming every feature you can think of into it.

<comment><USER16> Right, and in recent years, PHP has been really cautious as to how it adds certain features, but more importantly, has been cleaning up old edge cases.

<comment><USER15> TFA seems to argue that people's complaints don't apply to PHP5 because it added a random assortment of features.

</comment></comment></comment><comment><USER17> I guess it's irrational, but the fact that there are some good points nestled inside this post only makes me more irritated about the post as a whole. You see, it's easier to just shrug and say "meh" if the whole thing is crap.

Te problem with the main premise is the same thing PHP apologists have been harping about all the time:

 _some poor soul wants to create an online encyclopaedia, or some teacher needs an online teaching platform, or someone wants to write a blog. Those people do not want to learn to program, they want to solve problems._

Newsflash: solving those kinds of problems is called programming. That's what programming is. You want to make the computer do something that it can't do with the existing programs, so you create a new program.

If a programming language is easy to use by _everyone_ , it's because it doesn't require you to think like a programmer. It's part of the language design. If you start fixing those design decisions, you'll most likely end up with a decent language that simply isn't easy to use by _everyone_ anymore.

This idea that you don't need to be a programmer to write programs has already failed on several occasions in history of programming: dBase, Visual Basic and Access are notable examples. Not repeating the history is too much to ask for, but let's at least try to avoid making it look like it's a good thing.

<comment><USER18> You do not need to be a writer to write, a driver to drive, a cook to cook, a runner to run, or a businessperson to conduct business...and you don't need to be a programmer to program.

<comment><USER17> And yet you need to be a dentist to work on someone's teeth, a doctor to prescribe medical treatment or a pilot to fly a plane.

Yes, you can program without being a programmer, just as you can drive a city car to your office and back, but you won't take that same city car to Monza and expect to beat Ferrari's Formula One team in a race.

So let's dispense with the sophistry and admit that you need to learn a specific skill set to do a skilled job and that you need adequate tools for that job.

<comment><USER18> A race car driver is a very different thing from a driver. There are also restrictions placed on who can be a race car driver. It sounds like what you are really saying is that programmers need to be certified by a professional trade organization, following a period of 2-6 years of education and apprenticeship, enforced by law. After all, that is what separates doctors, dentists, lawyers, and accountants from other professions. (Race car drivers have contracts and other measures to enforce exclusivity, as racing is generally illegal except on dedicated courses or in licensed races.)

Programming is a skill/trade. It is not a profession. _That is a good thing._ If programming were a profession, it would not be open to everyone to learn and do.

</comment></comment></comment></comment><comment><USER14> This is offtopic, but I just wanted to say that I really enjoyed your "PHP's Source Code for PHP Developers" posts. Please keep writing!

</comment><comment><USER19> The fact that people have to constantly defend PHP says something in itself.

<comment><USER20> That people constantly attack PHP?

In all seriousness, it just works when your building for the web (unless it doesn't.)

Is it often messy? Absolutely. Is it sometimes a bit verbose? Sure. Can it sometimes be like laying a snare, only to accidentally step back into it? Yes, but it's not alone, just seems to make it a little easier to occur.

It doesn't have to be that way, it just tends to be like that.

I prefer Python and Scheme, but I don't enjoy them when it comes to working with web development. There are frameworks that help with this, but it's still a pain. PHP is quick and easy, in that area and works 95% of the time in about 99% places you stick it.

I've been trying for years to embrace Python in web development, but it just annoys me during the setup. PHP gets out of the way, in that area, and let's me go.

</comment></comment><comment><USER21> Coming from someone who didn't start with PHP. Has used a variety of other programming languages. And programs in PHP daily I will say that it fails in many important respects and will for some time to come. The first things that come to mind are functional programming (it has some abilities but is fairly quirky and harder to read than other languages). Being able to use array_map or array_reduce is useful in many places but certainly not elegant in PHP. Code reuse is also not that easy with PHP (though traits may fix it, but we don't use PHP 5.4 yet because it's seemed fairly problematic for us in production) and the need for autoloaders is somewhat insane once you've used a language with an actual package system. It doesn't have a mature dependency management system (though Composer is currently an up and comer). It's great for small projects but horrible to maintain at large scale - and this is from someone who has written 100K+ line programs in PHP.

</comment><comment><USER22> That's what i like about PHP:

\- low maintenance. That's true.

\- straight forward coding. Yes you can shot yourself in the foot. But it's easy.

\- controlled file descriptors, functions, etc:

Tell me, how can you restrict the baseopen dir, certain functions such as exec'ing, how can you log all mails going out from.. python's wsgi, or ror, etc?

That's right. You can't. Well PHP can.

So, I dislike PHP for all the reasons everyone are going to write for the umpteen time too, but it does have several unique strengths too.

</comment><comment><USER23> Wrong! Nope!

PHP OO is screwed up and hacked together. Look at crappy support for late static binding, being unable to bind $this in closures, and all of the hack- glue that is get_class(), get_class($this), get_called_class(), self:: vs static::, the list goes on.

The thing is that, with PHP, the "new, modern" features are only surface deep... once you do anything slightly advanced, you can always tell that they were hacked on to a language that was never meant for anything more than 'include counter.php', and maybe that's okay, but stop saying it's a real programming language because it's NOT.

<comment><USER24> _but stop saying it's a real programming language because it's NOT._

Any definition of "real programming language" that can inexplicably exclude the Facebook stack is just meaningless. Saying that another stack could do it better is pointless since _PHP is what does it_. And just to preempt any "HipHop is the stack, not PHP", just remember that front-end Facebook engineers don't write C++, they build Facebook in PHP, inconsistent parameter orders and all.

<comment><USER25> Does everyone think the facebook stack is just built from PHP, there is a boatload of C etc too. Don't forget they have HipHop which makes thier PHP a little non-standard. Also they have a MASSIVE legacy codebase I presume so just swapping out to something might not be justifiable despite how much they wish they could.

</comment></comment></comment><comment><USER26> There's nothing particularly wrong with this article. It describes some aspects of PHP.

It's just that Atwood's article describes PHP _much_ better. ([http://www.codinghorror.com/blog/2012/06/the-php- singularity...](http://www.codinghorror.com/blog/2012/06/the-php- singularity.html))

I think the latter view is spot-on, and nikic's view here just serves as a perfect example of why certain people are still addicted to their awkward toolset.</comment>


Ask HN: Visiting LA, want to know the tech neighbourhoods - <AUTHOR>

I am visiting LA end of the month and would love to know areas where I will be close to the tech scene. <comment><USER2> There's an app for that: [http://www.represent.la/](http://www.represent.la/)

The data may be out of date, I don't know, but you can clearly see where the highest concentrations are. Near the beach in Santa Monica/Venice is what I consider the epicenter.

</comment><comment><USER3> There's more happening on the West Side but also Downtown and a few other pockets. See [http://www.lageeks.org/](http://www.lageeks.org/) which has a tech events calendar.

If you are in Marina Del Rey and would like to meet up for lunch, let me know.

<comment><AUTHOR> I'd love to! Are you on Twitter?

<comment><USER3> Great! My email is in my profile.

</comment></comment></comment><comment><USER4> Definitely one area is around Coloft [http://coloft.com/](http://coloft.com/) in Santa Monica.</comment>


De-facto closed source: the case for understandable software - <AUTHOR> https://13brane.net/rants/de-facto-closed-source/ <comment><USER2> The more I read about the js ecosystem, the more it seems the inmates are running the asylum

It's a long time since js needed a good stdlib.

Everybody was using this package but apparently no one but an adversarial player stepped up to actually maintain it.

(And don't get me started on "let's always get the latest version of the package")

> You want to download thousands of lines of useful, but random, code from the > internet, for free, run it in a production web server, or worse, your user's > machine, trust it with your paying users' data and reap that sweet dough. We > all do. But then you can't be bothered to check the license, understand the > software you are running and still want to blame the people who make your > business a possibility when mistakes happen, while giving them nothing for > it? This is both incompetence and entitlement.

Not surprising. Not surprising in the least. "Oh wow somebody 0wned the package I needed". Maybe because js projects have _an order of magnitude more dependencies_ than a Python/Java/Go, etc project. Maybe because in the extreme opposite of NIH, people feel the need to import a module for every small thing they want to do? "Stack overflow programming", "how do I add 2 numbers using React, is there a module for that!?!?!"

<comment><USER3> The cynic in me is saying that JS is the new PHP. Ironically, both are very capable and suitable languages, but the sheer freedom they offer attracts crowds of wannabe developers who think they are gods because they know how to shave off 10% of execution time in some small part of their overengineered and unmaintainable mess. And give talks about it, write blogs and post clever twits.

However developing robust software is possible in JS, the same way it was possible in PHP. You just need to take some time to vet dependencies a bit better and not use every fad when it surfaces. Common sense and experience help a lot. But it's incredible what can be built with modern toolchains and how maintainable it can be. Don't let the anti-JS feeling scare you from trying React / Vue /..., just don't forget that state management, separation of concerns and similar concepts are still valid.

<comment><USER4> > the sheer freedom they offer attracts crowds of wannabe developers who think > they are gods because they know how to shave off 10% of execution time in > some small part of their overengineered and unmaintainable mess. And give > talks about it, write blogs and post clever twits

Honestly, I think JavaScript just has a lot of new developers who have never been exposed to concepts of software development such as dependency management, cultivating trust, and how (free and) open source works. I think the kind of developer you're describing is actually a minority.

<comment><USER5> This is my thought as well. "I have creative experience and/or student loans but I don't know what to do for work so I'll take a Javascript course and become a web dev."

It's wonderful that programming is becoming a kind of "equalizer" on the job market. But without supervision from _software engineers_ (i.e. people with the experience and aptitude to design software properly) you end up with a mess.

<comment><USER6> The myriad of small snippets of JS encapsulated as npm modules is best compared to the alternative of copy-pasting solutions from websites like stack overflow. Instead of lots of copies of solutions to common problems, now everyone shares the same implementation. This obviously has the centralization weaknesses but also has the centralization strengths.

The fact that there's no panacea is a fact of life. There's a tradeoff, but it is not reflective of the people in the JS community.

<comment><USER7> In Java world those snippets tend to combine into bigger libraries. Apache commons and Google guava are the most known ones and their reputation is established. I don't understand why JS world does not do something similar. Some essential-utils from AiRbNb or whatever JavaScript analog of Google. And if there's still need for some tiny function, just implement it and move on! I can understand that JavaScript favors small download size, but modern tools should be able to remove unused code, so it shouldn't be an issue either.

</comment></comment></comment></comment></comment></comment><comment><USER8> "FOSS was never about trust in software owners."

Actually, it is. That's why foundations such as Apache, Mozilla, Khronos, etc exist. Transfers of ownership, abandonment, and bad faith are not new. We need to trust not only in the software for today, but for tomorrow as well. Foundations step in because they're able to harness the financial clout to attract maintainers.

"We must make software simpler."

We must make software INTERFACES simpler. And that means opinionated solutions, preferably with a HEAVILY opinionated top layer API for the 80% and a less opinionated lower layer API for the 20%.

This is where "wide open" development systems such as Javascript and Lisp fail: They offer too much freedom. You need a standard, opinionated library that provides most of what people need, just for interoperability sake. You need standard ways of doing the common tasks so that people can harness those patterns into reusable modules that stand a greater chance of working well with others.

<comment><USER9> Yeah for all the good points in the article the author flubs these two major takeaways. Trust is required for all human interactions, not just software. But at scale you have to build the tools to enable trust into the system. And JavaScript/NPM has a lot more and bigger built-in systemic risks, including a much greater level of trust required and a lot fewer tools to enable it.

</comment></comment><comment><USER10> As someone with the slightest consciousness for security, this always terrifies me.

The Gradle version in the Ubuntu repos is too old? Just add a PPA from some random guy on the internet. The Gradle wrapper also exists, but you'd need to type "./gradlew" instead, which is apparently enough reason to use the PPA instead.

Need a Gradle plugin? Oh, yeah, just add Maven Central and JCenter as repos. No idea who (/if anyone) audits those, but we'll just trust them anyways.

Need a Docker image? Just go to Docker Hub or Quay and download one that looks good.

Don't quite like Eclipse and the company won't pay for the IntelliJ Ultimate Edition? Just install the Community Edition, with no idea if that Privacy Statement actually means they could phish your SSH keys, phone number etc.

Need a way to transfer files? Google Drive is a great way to do that.

Need an operating system? We have either Windows 10 or Windows 10 for you, which has been shown to transfer encrypted, undisclosed packages to Redmond, even in the Enterprise Edition.

Office suite? MS Office, for which the same is true.

Need to look up some specific issue with security critical software you use? Just type it into Google.

I even once saw someone who typed a password into the Chrome URL bar to show the guy next to them how it's spelled.

With the sheer disregard I frequently encounter for any sensible behaviour, I've really stopped wondering how hacking, industry espionage etc. work. I'm already quite content if it's not just all out in the open.

<comment><USER11> For any electronic device of your choice, search for its manual and look for this notice:

"This device complies with part 15 of the FCC Rules. Operation is subject to the following two conditions: (1) This device may not cause harmful interference, and (2) this device must accept any interference received, _including interference that may cause undesired operation_."

Everything is backdoored, absolutely everything: your hardware, your firmware, the compiler used to build your software, your software, libraries used by your software, your network infrastructure, your crypto, your sources of entropy, the machines you communicate with, everything.

</comment></comment><comment><USER12> Understandability is definitely a nice thing to have, though I believe it's ultimately limited by essential complexity of the problem domain. Also, it's not a solution here, because a malicious actor can make the code very easy to understand in a way in which you gloss over it and not notice subtle bits here and there that add up to an attack.

Still, this is not the main problem highlighted by this (yet another) NPM fiasco. I believe there are two and only two core problems that caused this issue, and that will enable future incidents like this:

Problem 1: some scoundrel violated the commons. The commons have no effective means of tracking them down and punishing them, so that a) they'll deeply regret what they've done, and b) other scoundrels will be deterred from trying. Lack of means of effective policing means various open source communities will keep having such problems.

Problem 2: people don't check their dependencies. Yes, I can already hear all startups screaming, "we can't afford it". Well, sucks to be you, but you'd better hustle and find a way. The licenses of almost all the software you use disclaim any responsibility for anything whatsoever, so if you expose users to that software and that software harms the users, it's _your fault_. You mishandled them. So find a way to vet your software, or buy some insurance against yet another NPM compromise. Or don't, and accept you're taking a risk.

To be clear, I'm not advocating a general "caveat emptor" attitude to software. We've build a civilization in part on systems and regulations that allow us to _not_ vet everything we interact with, and yet be quite confident in our safety. But FOSS is not there yet (Problem 1). It's built on trust, but most communities have little means of protecting that trust. As for companies, I have little sympathy (Problem 2), like I wouldn't have much for any other company in any other industry that said they can't afford to do their basic job right.

</comment><comment><USER13> I don't know about the feasibility to understand all that's going on on your computer with the ongoing stuffing of layers over layers (kernel, userspace, "container", language VM such as node/v8 or JVM, framework, etc.). If anything, I'd expect younger devs to understand less of it all, since they don't learn from the ground up (eg from hardware). But there has always been the option to use interchangable standard components based on POSIX, SQL, etc. as a remedy to become critically dependent and vulnerable. In fact, node.js started as just one of many implementations of the CommonJS module loading mechanism and base API, in addition to being based on one of the most portable languages of all time.

But I guess no amount of education will make the kind of developers go away who think 400+ package dependencies for a trivial app is a good thing, or that you absolutely have to write a proprietary not-quite-JavaScript language compiled to JavaScript via babel, or that node.js in itself is a goal, rather than merely an implementation.

<comment><USER14> Not knowing much about node.js, wouldn't the most logical step now to make a standard node.js library that implements the majority of the functions of those ~400 packages? Vetting one package is easier than vetting 400. I guess that's what Rails did in the very beginning, I keep on discovering in-built magic

<comment><USER15> Node does have a standard library. It's not massive, but there's a lot more available out of the box than is available in a browser.

The tricky part is that lots is npm packages end up bundled into an app that runs in the browser. It's just a guess, but I'd guess that significantly more npm imports end up running in the browser than in Node. So even giving Node a standard library as extensive as Ruby's wouldn't help as much as one would hope.

</comment></comment></comment><comment><USER16> New to web dev. New to node. Looks like a complete mess to me, deserves criticism, as does much of the web dev ecosystem.

Package maintainer should indeed have found someone to pass it onto (see Cathedral & the Bazaar). And that doesn't include the first person he's never heard of stepping up.

BUT this applies to all package managers, maintainers, and OSS _at some level_.

The idea that say a startup has time to audit every line of every dependency is absurd. Even a big business can't do that. The idea that you "don't have to trust" the authors is untrue, in the current workflow. FOSS relies entirely on trust.

I'm not convinced FOSS is even a good idea at this point, but with the advent of widespread cyberwarfare we need to either introduce a sophisticated accompanying trust model, or exclude FOSS when working commercially.

This is a business opportunity. Audit FOSS and sell your audit guarantees in a contract. Offer services to audit more recent versions on the proviso that you can sell that audit elsewhere.

This will have the incidental benefit of encouraging clean software to be written in languages that minimise audit costs, as those projects will get used more.

Some commercial arbitration of FOSS now looks inevitable.

<comment><USER17> > Package maintainer should indeed have found someone to pass it onto (see > Cathedral & the Bazaar). And that doesn't include the first person he's > never heard of stepping up.

WITH NO WARRANTY.

Do you not understand what this part of the licensed mean?

Mainter doesn't have to do shit. That is the point.

You want to start putting arbitrary ethics and morals on these developers? The "Fuck you. Pay me." talk comes to mind.

FOSS works fine like this and has been for a long time.

We're seeing issues now because of nodes lack of a standard library. Not trust and certainly not instead issues with free and open source software.

<comment><USER18> Lack of standard library only makes the trust issue manifest with more hilariously basic libraries, instead of more slowly with the libraries. We've still seen this in Python, the poster child for batteries-included.

<comment><USER17> I think it's been said elsewhere, this is true but the frequency and severity is orders of magnitude less with the languages with good standard libraries.

When the entire ecosystem depends on left pad I think you have a problem.

When the entire ecosystem depends on express it is less of an issue because more eyes are invested in auditing it and changes are more widely reviewed.

You think a nefarious leftpad function would make it's way into express? It could, but it is way less likely.

Updating the dependency to a newer version of left pad isn't going to raise an eyebrow. And that is the issue.

</comment></comment></comment></comment><comment><USER19> Best line in the post:

Software must be made understandable. The essence of FOSS for me can be reduced to one fundamental computing right: the right to refuse to run, on my machines, code that I do not have the option to understand. That is it.

<comment><USER12> To me, those three sentences don't even fit together.

You've always had "the right to refuse to run, on my machines, code that I do not have the option to understand". Nobody is forcing you to run any random piece of code you found on-line. You do that of your own accord. And if you screw this up, and that screwup affects other people, it's your fault. Simple as that.

<comment><USER20> Not only have we always had this right, the rest of the article argues, correctly, that the _option_ to understand the code you run does not solve the problem. It's like having the _option_ to study before an exam.

</comment></comment></comment><comment><USER21> The call for a massive reduction in complexity reminds me of the VPRI "STEPS" project (Alan Kay et al) to build a complete end-user operating system in under 20,000 lines of code. Sadly, it looks like the project is dead or over, and the links I've found pointing to it on vpri.org are dead today.

Until there's some external stimulus, I don't think the industry is going to change. It's a lot cheaper to add new flashy things if you don't care about complexity (or the consequences of it, like bugs, and security). Getting a consumer to care about the complexity of the software in their computer or phone is like asking a Ruby programmer to care about the microcode in their CPU. It's not that we can't understand the problem but it's not a concern until it gets so bad it impacts my level of abstraction.

I'd love to see programs start putting little badges on their webpages that brag about how few lines of code they have, how low their cyclomatic complexity is, or how short their dependency tree is. I'm terrible at marketing but surely there's a way to make this sound appealing.

<comment><USER22> The project completed successfully and wrapped up. Final report (2012) [http://www.vpri.org/pdf/tr2012001_steps.pdf](http://www.vpri.org/pdf/tr2012001_steps.pdf)

Discussion on HN (2016) : [https://news.ycombinator.com/item?id=11686325](https://news.ycombinator.com/item?id=11686325)

I think Brett Victor is one of the people driving the effort beyond that project: [http://worrydream.com/](http://worrydream.com/)

</comment></comment><comment><USER23> > I may be wrong, but in the millions of downloads of event-stream and it's > 1.5k dependent packages, there should be at least 5 companies involved > which, had they spared 1 dev-hour per week each, should be more than enough > to keep event-stream kosher.

This is a really good observation. If you know some important transitive dependency your job depends on is missing a maintainer, tell your nearest supervisor you'll be spending an hour a week taking care of that. Or a similar amount of time helping a direct dependency get rid of the broken transitive one, whichever makes more sense.

<comment><USER24> This might work for the most privileged class of software developers with the most clout, but I'm pretty sure that most devs don't have the luxury of informing their supervisor what they'll be working on.

<comment><USER17> You need to find a better employer.

<comment><USER24> I wasn't talking about myself, but some colleagues I have elsewhere. I pretty much come and go as I please, define the technical direction of the product and get paid handsomely for it.

Devs are still treated like children in many companies.

</comment></comment></comment></comment><comment><USER25> Without assigning blame to anyone, a simple-to-follow best practice would be probably to just never hand over a (personal) project. Make it as deprecated and let the community fork it. If you feel like it, point to the new, maintained fork.

<comment><USER26> Absolutely. I don't see why the author brushed off the maintainer's responsibility so casually.

> lets roll for a bit with the assumption that a small amount of extra care on > Tarr's part could have avoided this mess.

Are you kidding? The bare minimum of not just handing a repository under your name to a random stranger is apparently a hard to fathom concept for this author.

</comment></comment><comment><USER27> Whilst this particular instance focuses on the JS ecosystem and NPM, realistically the general points apply much more widely.

The number of commercial services and pieces of software that are largely reliant on huge piles of OSS is significant.

In contrast to that we're not really seeing those companies focus enough on the security of the OSS that they rely on.

To provide two other well known instances, both Heartbleed and Shellshock sat as vulnerabilities in their respective OSS software for a large number of years. The packages were widely used by commercial software vendors, yet none of them discovered the issues...

</comment><comment><USER28> It should be noted that in npm, examining the source of the package tells you absolutely nothing about whether you should trust the package - the actual blob that you download need not be generated from the same source.

</comment><comment><USER29> Support for tree-shaking in Javascript build tools is improving. This means that unused functions are not included from a dependency when they are not used. This could be a foundation for a more trusted utility library.

Such a library could be made by crawling NPM stats to find out what kind of small packages/functions are most used, and select a subset of these. The code could be lifted from the original packages (with proper licenses and attribution). The package maintainers could be approached if they are interested in helping to maintain this new collection package. The thesis being that such a package can be more efficiently maintained by a group, than each individual maintainer and package alone.

Once it exists, one can post PRs to common dependants to use the new package.

Could it work?

<comment><USER30> > Support for tree-shaking in Javascript build tools is improving.

I agree tree shaking could help a lot. But every time I have tried to implement tree shaking properly in a JS codebase, it is not trivial to solve. If one configuration is not properly setup then the entire library gets inlined during compilation.

Furthermore, libraries like lodash use a lot of inter dependencies so using something like `get` could bring in a ton of stuff that is technically used but totally unnecessary.

</comment></comment><comment><USER31> The common consensus is that building JS apps without an endless list of dependencies is so slow that you're going to get creamed in the marketplace due to inefficiency. Why should we spend $5m re-inventing the wheel when we could spend $2m re-purposing a bunch of other people's work?

Whether or not that's true is largely irrelevant, since the decisions are made based on what people believe, and since the same decision is made every time, there's not much data for the other side of the comparison. When was the last time someone deployed an app with less than 10 (total, not direct) dependencies? Hell, even 100? Some people have probably never built one with less than 1,000.

</comment><comment><USER32> This just makes me think a primary design goal when writing software is to Optimise for Deletion.

Everybody says that they emphasise ongoing maintenance when writing code, but the best way to take that to extremes is to optimise the ability to remove (and replace) code en masse.

<comment><USER33> This looks somewhat similar to good old modularity and decoupling. Does "optimize for deletion" differ in some way from that?

</comment></comment><comment><USER34> Don't forget horrendous build systems. Ever try to build a Google product? I wanted to use Skia for my game's GUI - I never got it to build.

<comment> Const-me I have also evaluated Skia, and came to the same conclusion.

Have been using nanovg instead: somewhat lower level, but at least it builds, and also it's quite simple to use. The main downside it doesn't support ClearType for text rendering, even when using it with FreeType.

</comment></comment><comment><USER35> I don't think that reading through millions lines of code is a sane idea. Therefore I suggest an alternative to author's opionion:

\- select a Linux distribution one can trust, like Debian

\- throw away your Node.JS and switch to PHP. We have frameworks like Symfony made by a company that can be trusted and that has proper code review processes so you don't have to worry that tomorrow there will be a backdoor

Another alternative would be a community code review. Everyone using OSS code can contribute some time for a review of the project they like the same way they contribute the code. Reviewing is even easier than writing a code. Then they sign the lines they have checked. It would also help to find poorly written, difficult to understand code and find unreliable code that can contain vulnerabilities.

The companies using OSS code could be interested in this. They would prefer to use the code checked by other corporations rather than the code that has never been reviewed. And they probably are already doing the reviews privately so it wouldn't cost them anything.

</comment><comment><USER36> So many people here seem to be missing the point by assigning blame to npm or node or whatever specifically.

This situation could happen with packages in any language.

<comment><USER17> Could. Yes. But many orders of magnitude less likely.

This is why languages have standard libraries. It prevents the dependency hell we have with node.

<comment><USER29> Reduces, not prevents.

<comment><USER17> Prevents vs acts to prevent. Sorry, I misspoke.

Fact is. Nobody builds a standard library to reduce dependency hell. They do it to eliminate it.

The standard library uptake, quality and efficiency is all intertwined sure and developers can always go shoot themselves in the foot anyway but, wait, I'm sorry, did you have a point?

<comment><USER29> No standard library contains everything most people need, and sometimes the stdlib version is not the preferred.

Look for instance at Python. Lot of people use requests instead of urllib for HTTP client. No-one uses the HTTP server. Until 3.x no support for async IO or event loops, so we have Twisted/gevent/eventlet, mostly incompatible.

My is only that there are painpoints around dependencies event with a stdlib.

</comment></comment></comment></comment></comment><comment><USER37> I am really rooting for understandable software. I do not consider a software without appropriate documentation to be free (as in freedom).

Lately I met many companies claiming they make "open source", when their software is in fact hardly usable as is, and you would anyway be required to upgrade to "pro" features or "pro" support to get anything useful done with it.

At this point I consider such piece of code _de facto_ closed source. Disclosing the sources or part of them in itself does not bring much value and does not increase the number of careful eyes auditing the code.

I really wonder why they decided to open-source such product to begin with, is it marketing? Are there other advantages?

<comment> 08-15 Open Source is not Free Software. It never was. Open Source is the development model where you open up your source so more people can see and debug it. In practice, it could mean you write commercially important software by employing a thousand monkeys with text editors and then dump the impossible maintenance task onto the "community".

</comment></comment><comment><USER38> > FOSS was never about trust in software owners.

I get what the author is saying, but I think these kinds of originalism arguments are always a bit tedious. Do we really think that the original utopian intentions of hackers in the 80s are going to provide us with magical insight into this problem? The context is completely different from anything they would have imagined.

Open source / free software isn't a gift from heaven that will work out if you just believe hard enough. The situation described is a new problem, and we have to think hard about how to solve it

</comment><comment><USER39> I get annoyed by languages/frameworks that want to download code from mysterious web sites, bypassing the distribution's package manager. Ruby seems to do this, though I might be wrong: that I can't easily tell where the code is coming from is bad in itself. I prefer to know that there's at least a Debian maintainer between me and upstream.

I definitely would notice if Debian itself got taken over!

Perhaps the rule of thumb should be: if it's not properly _in_ Debian, then don't use, it unless you have a very good reason for doing so.

<comment><USER40> Let's not forget how those trustful Debian maintainers packaged openssl 0.9.8...

<comment><USER41> It was 10 years ago...

For people interested: [https://www.isotoma.com/blog/2008/05/14/debians- openssl-disa...](https://www.isotoma.com/blog/2008/05/14/debians-openssl- disaster/)

</comment></comment></comment><comment><USER42> Homesteading the Noosphere by Eric Steven Raymond seems relevant in this discussion. Originally written 20 odd years ago.

"I examine the actual customs that regulate the ownership and control of open- source software."

[http://www.catb.org/esr/writings/cathedral- bazaar/homesteadi...](http://www.catb.org/esr/writings/cathedral- bazaar/homesteading/)

</comment><comment><USER43> I've been saying this forever and it still feels like an unpopular opinion, but stuff like this is why I hate micro modules as opposed to frameworks. A lot easier to trust say, RxJS (with just 1 small runtime dependency) instead of 40 different tiny modules that may depend on other tiny modules. Actively developed frameworks seem less prone to this kind of malice.

</comment><comment><USER44> This is nothing to do with the free software. It's just that NPM ecosystem and culture is horrible.

<comment> c-smile Ah, culture...

There is a law of the transition from quantity to quality by Hegel ([http://www.pnas.org/content/97/23/12926](http://www.pnas.org/content/97/23/12926)).

As soon as number (e.g. of modules in NPM base) reaches some point the overall quality changes dramatically. It is a step function - from good to bad. From enthusiastic acceptance to full rejection of NPM and similar code sharing mechanisms.

<comment><USER45> That is a fantastic read, thank you. It's amazing how many structures and institutions have evolved from that simple concept.

</comment></comment></comment><comment><USER46> OK - that whole talk about making software more understandable instead of churning new features - sounds good. But his rejection of reliance on trust looks like a pipe dream.

What is he proposing in concrete terms? How one should decide that his code is understandable enough? What to do with the recursiveness of libraries that use other libs that use libs ...? The only concrete advice he proposes is the two weeks idea: """ is it possible for a new (but experienced) developer to understand 80% of the part of the codebase they'll be responsible for within their first 2 weeks (80 hours)?

If not, this person is overworked from day 1, """

But is this practical? All code should be understandable in two weeks?

</comment><comment><USER47> This is less about open source, and more about how people consume it. If you take open source as simply one of many available resources, read the code, and make deliberate decisions whether to use it, fork it, modify it, etc, then actively engage with its presence in your codebase, you are fine. On the other hand, if you "npm install <whatever>" as the easy answer to every question, you will get burned: At best by code bloat, at worst by malicious actors.

</comment><comment><USER5> _But no one has time for that, right?_

This is what really blows my mind. Yes, Facebook is the main force behind React. But where are the other companies stepping up to maintain chunks of the JS ecosystem?

If you work at a company using FOSS software, please try to convince your managers that helping to maintain said software is a good use of (some fraction of) your time. It's in your own best interest.

</comment><comment><USER48> Interesting - we in theory, get to trust the code cos we can read it.

But in reality we trust the authors. So in theory we could build a dependnacy chain of signed commits, with a in theory monetary payment going to those whom we trust

So apart from Linus getting a Xmas bonus, it would directly encourage ... what?

</comment><comment><USER49> Wow, beautiful!

Looking forward to the next chapter on trust by review. (And I don't mean 5 stars on some "app store" you've never used before by reviewers you've never met.) Big ups.

</comment><comment><USER50> part of this issue is that it's difficult for maintainers to capture value for their work even when they're successful

i've written a "paid use" license that attempts to capture many of the freedoms of FOSS while allowing a revenue stream if a package is successful. would love any feedback

[https://github.com/db4j/pupl](https://github.com/db4j/pupl)

<comment><USER51> The problem is that people want open source software to be like their own software. That is, it is written like they would have written it, and in such a way that they can go through the source code and understand it and modify it, but without them having written it themself. Necessary for this, I think, is that the software is legally indistinguishable from software they wrote themself.

Many people license their code under a "public domain license". What's interesting is that such a license has no requirements of placing a copyright notice anywhere, and allows someone to freely relicense without modification. This is precisely as it would be if you had written the software yourself.

Your license recognizes the value of freeware as a marketing tool - the more people with their hands on the software, the more likely some of them will stand up and pay for it. But I think the personal ownership aspect is more foundational.

In advancing that, the license I would write would be one that places the software under a free license after some fixed date. You might state, for software released in 2019, that starting in 2024 it will be licensed under the GNU GPL. Until then, it would be licensed under some proprietary license, perhaps the one you propose.

This forces people who use the software to pay for it's development, under whichever terms the proprietary license requires. Simultaneously, it ensures that those paying for it ultimately own the software, and therefore any improvements they make to it.

<comment><USER50> mariadb's Business Source License ([https://mariadb.com/bsl11](https://mariadb.com/bsl11)) is consistent with what you describe, though without any assurances during the proprietary phase

possible that combining the two as you suggest would be the best of both worlds. i need to think about the business implications for the author

</comment></comment></comment><comment><USER52> the event-stream story remind me the true/false story of the color logs : [https://hackernoon.com/im-harvesting-credit-card-numbers- and...](https://hackernoon.com/im-harvesting-credit-card-numbers-and- passwords-from-your-site-here-s-how-9a8cb347c5b5)

</comment><comment> c-smile The article reminds me posters of USSR time that I saw a lot:

"Soviet developers, make your application simpler and readable!"

"Soviet developers, be responsible, do not pass the code to strangers!"

"Soviet developers, read the code of your dependencies!"

"Soviet developers, do all this with a joy and free of charge!"

Replace "Soviet" by "FOSS" above or vice versa for your taste.

While basic ideas (e.g. Communist Party Manifesto as the Commandments it is derived from) are perfect the merciless reality is not. Human nature, sigh.

<comment><USER51> Well, free software _is_ communism, so it's not surprising.</comment></comment>


Ask HN: Is really Y Combinator selection process fair? - <AUTHOR> Now there is a new filter:  "Alumni will review & filter applications". In our case, none of the Alumni or Partners viewed our YC W2013 materials including Founders URL, Video How it works and Full beta, all of them with 0 views.
They didn´t care if we were a Founder and a Co-Founder with good serial entrepreneur and execution history; raised 725K for this startup; executed and developed a full "Fintech" platform ready to launch.
Reading more than 200 applications per day could be overwhelming and finding the next Google between more than 2,000 applications is like finding a needle in a haystack but YC definitely needs to improve the selection process. Ideas:
a) Start limiting the number of applications per batch (Honestly I prefer that each batch have a limited number of applications. With that limit, Partners will review each one. Alumni are very smart but they are busy building their own startups and don´t have the experience, vision, to screen apps like the Partners.
b) If you involve Alumni they really need to review all the applications and all the materials. People spent a lot of time on the applications; at least they deserve the right to be reviewed in full and if they reject an application is because they really make a good job reviewing it.
c) Now you can apply even if you don´t have an idea. Also make a different application process for groups that are more advanced like almost ready for launch or launched.
We were only asking for the 10 minutes interview like all other groups. YC means for us: a) The best mentoring, b) Feedback, c) Knowledge and Networking
YC: You have the right to reject any group but please review the applications in full. Anyway we are continuing with or without YC. This is only a friendly note to the great people (Partners & Staff) at YC. <comment><USER2> I don't mean to be disrespectful but here is my 2 cents:

1\. Limiting applications is a really stupid idea. Imagine if all the bad applications filed early and filled the quota.

2\. YC decides what best/right for the selection process. None of us have a right to question that. By submitting our application, we are agreeing to this condition implicitly.

3\. I am not sure why you consider "watching the videos" as the only form of due diligence to the application. They may have read your application and might have decided just based on that and might have not felt the need to watch the video.

4\. "725k raised ..." - I dunno why many startup founders seem to wear "investments" like a "badge of success". I would have sympathized with you if you had instead written - "725k of revenue and dozens of happy customers". Just because someone decided to invest in you, does not mean everyone else has to or that your idea / startup will succeed.

5\. "serial entre.... " - why do you need YC? go get what you are worth.

6\. "please review applications in full" -- We all sometimes decide to NOT watch a movie, just based on a short 2 minute trailer. There might be no need to read your application in full - you could not grab their attention with whatever little they read.

As I mentioned, I don't mean to be disrespectful - but the tone of your thread is more accusatory than of one respectfully making a suggestion.

All the best!

</comment><comment><USER3> I don't want to sound harsh but if your application read like your message here it's not surprising that you got rejected. Investors want people who are hungry for success, not people who feel entitled to it.

Regarding your actual suggestion, I'm not sure how restricting the number of applicants would help, after all it seems far better to have a first-level filter (i.e. alumni network) than to just impose some arbitrary limit based upon a lottery or a first-come-first-served basis.

YC has commented before that the no-idea applications are essentially an experiment. Historically many YC companies have pivoted significantly over the three months of YC, this naturally carries an implication that the idea doesn't matter as much as good founders, so it seems like a reasonable experiment. There's no a priori reason to assume that teams who have launched are going to be more successful than ones who haven't, they're just at a different stage of their life-cycle.

I believe this is only the second season where they've had no application ideas, so it'll probably take them a couple of years to measure if it works or not, but presumably from the fact they're still doing it the initial indications are positive.

<comment><AUTHOR> Thank you for your point of view, but again, I am not saying that I am entitled for success. The only thing that I am saying in my humble opinion is that applications should be reviewed in full (Alumni network or Partners, etc.) That is because probably applies in our case, we are really bad with words in our application but watching a video or how it works and full blown beta demo could increase the chances... my 2 cents.

<comment><USER3> Get better at words. The internet is largely driven by the written word, from social to ads to the sales copy on your website, being good at conveying yourself in writing is important.

I'd really recommend working on your skills or finding someone (either on a permanent or freelance basis) who can bring written skills to the table.

Forget YC, you can't expect your customers to watch your intro video or to test out your product if your written text doesn't convey the value it will deliver.

</comment></comment></comment><comment><USER4> Unfortunately, very few things are in life are actually "fair". "Fair" is also very relative term. The definition of "fair" means one thing to you, one thing to Y-Combinator and something very different to an applicant who got an interview. There are several hundred people across the world right now who had the wind blown out of their sails like you. While I do not personally know anyone at Y-Combinator, from everything I have read, I imagine this is the best system that they have at the moment and are continually refining it. That being said, like anything man-made, it is not perfect and great entrepreneurs will always fall through the cracks. Prove them wrong and be one of those that fell through the cracks.

</comment><comment><USER5> There's no way for you to know the quality of the applicants who got an interview. Why do you think you're so entitled to an interview? YC doesn't owe you anything. Your suggestions are largely self-serving. There's no way to force alumni or anyone else to spend lots of time on every application, and limiting the number of apps just increases the chance YC will miss out on the next Dropbox.

<comment><AUTHOR> I am not saying that I deserve an Interview, what I am saying is that ALL applications and materials NEED to be reviewed so they really don´t miss the next DropBox like you say.

<comment><USER5> All applications are reviewed. In your case, YC was able to decide your company/team isn't a good fit for them just by reading your app, without needing to see a video or demo.

Why should they be forced to spend an hour on every app when they can make a decision in the first few minutes?

</comment></comment></comment><comment><USER6> To be honest, I'm not particularly bummed that our team Contactable (<http://becontactable.com>) got rejected. If anything - its encouraging us to try to hustle harder, get a prototype to market, obtain paying customers and building a profitable business.

Although I was bummed about not getting through to the next round - I DO NOT feel that I was hard done by. In fact, YC partners clearly thought that there were better businesses to back or a better fit.

... and that's OK. The best thing to do, is to focus more of your energy towards your own startup.

I do not believe any of the processes need to change - if they realise something is broken, YC's partners will adjust accordingly. After all, they are also in business to make money - so if they start picking bad businesses to back, then they will change their application process accordingly.

Life's never fair, so just get over it and hustler harder!

</comment><comment><USER7> YC became a very good brand that attracts best startups all over the world. I believe, you could make good make good portfolio from rejected companies. It could be good market for crowdfunding.

Problem is that not many investors have sellection skill and experience that YC or some other industry leaders have. That's why investors prefer to follow, 'lemming role' is safer and psychologically more comfortable. Difficult to fing reason to be the first investor in the pool.

What would help for everybody in ecosystem - more transparency in YCombinator selection process. Min Scoretable - team score, market score, product score, stage. Startups could opt-out from public scoretable while applying.

This will become point of reference for other investors and crowdfunding platforms and valuable feedback for entrepreneurs. YC as industry leader could bring this public good to the table.

</comment><comment><USER8> Our application didn't receive any hits either. I think they focus more on the people then the app. For example: how long have you guys worked together? How many times applied? I think the question about "hacking the world" plays a big part. As every founder knows, the application changes so much during development- that it's not really about the idea- it's about the parters. You need to have a history with your partners, you need to balance each other, you need to be creative and "think outside the box"(hacking). Lastly you need to show previous success. If they're investing time, money, credibility into you - they want to see previous success to know you have the right drive and you are a "winner". Just my thoughts. Good luck on your application!

</comment><comment><USER9> The description raises a question in my mind.

With $725,000 already raised, what does that mean for YC's investment? Does YC's $17,000 only buy 1 or 2 percent ownership? Or do they still get 7% and the earlier investors get screwed?

Some companies may not fit within YC's portfolio.

In my opinion, Fair != equal

Good luck.

<comment><AUTHOR> Thanks for asking. We have some stocks (Founder stocks + Advisor Stocks) that we will give to YC in case they are interested in us without screwing the angel investors. There are a lot of things that YC adds that money can´t buy and without affecting previous investors.

<comment><USER9> After a bit more thought, I see a potential "product-market" disconnect.

Rightly or wrongly, YC's template is to invest in people more than companies. While on the one hand, a track record of successfully raising capital makes the team more attractive, having raised a substantial amount prior to applying places the team in a position where they are pitching the company rather than themselves.

A team which has to devote time to placating investors has less energy for product development. In addition, a team with substantial outside investment is less able to pivot, and may therefore present itself as less likely to succeed.

I would add that the tax liability for YC under the proposed stock transaction might be several times their normal investment.

Finally, relocating your current venture to Silicon Valley might provide improved networking opportunities and better access to technical capital.

</comment></comment></comment><comment><USER10> If reading individual applications take so long then why don't yc implement a good text to speech app on the back end of HN that reads it for them? Problem solved!

</comment><comment><USER11> Life isn't fair

</comment><comment><USER12> Fair? YC is not some government run charity service. Terms like "fair" or "unfair" don't make sense for describing the selection process.</comment>


Value Of Feedback In Lean Product Development - <AUTHOR> http://blog.neemware.com/2011/11/08/value-of-feedback-in-lean-product-development/

<comment><AUTHOR> Article showing the value of feedback in all phases of Lean Product Development.</comment>


Research questions that could have a big social impact, organised by discipline - <AUTHOR> https://80000hours.org/articles/research-questions-by-discipline/ <comment><USER2> Many of these questions are not well posed. For instance, the question, "What's the average lifespan of the most common species of wild animals?", has a fairly simple answer. Most animals are insects, and most insect larva get eaten. Ergo, the average lifespan is probably measured in hours.

If the question is restricted to only mammals, then you still have fairly big ranges. Small animals may live only long enough to breed, while some larger animals (such as humans) may live for decades.

There are other questions about cultural longevity, well-being as well as broad and specific questions about risk factors. Communicating the desires behind these questions might be more helpful than the questions themselves.

<comment><USER3> You might want to click some of the links or read other content on the site to get more of that supposedly missing context.</comment></comment>


Show HN: Save web page screenshot to an SVG file - <AUTHOR> https://html-to-svg.as-a-service.dev/?url=https://news.ycombinator.com/ <comment><AUTHOR> Code is available at [https://github.com/as-a-service/html-to- svg](https://github.com/as-a-service/html-to-svg)

</comment><comment><USER2> Is there an option for using this for authenticated pages?

</comment><comment><USER3> This is cool... but question... what would you use this for?

<comment><USER4> Link previews like you get in iMessage or Slack</comment></comment>


Dart Hello world test with optimize - <AUTHOR> http://jsperf.com/dart-hello-world-test-with-optimize/2

<comment><USER2> In Chrome:

As is JS ops/sec: 3,163,860, ±3.70%, fastest

JS (from Dart) with --optimize ops/sec: 23,337, ±4.84%, 99% slower</comment>


Scout: Test any browser in your browser - <AUTHOR> http://saucelabs.com/blog/index.php/2011/05/cross-browser-testing-in-your-browser-with-sauce-scout/

<comment><USER2> Awesome. This service is a no-brainer.</comment>


Show HN: Can you spec a random dribbble in 60 seconds - <AUTHOR>

    http://specthis.parseapp.com
 this is a simple app to keep spec writers (product managers and designers for apps currently) stay sharp through a fun  spec'ing exercise.
you are shown a random dribbble image.
you have 1 minute* to give:

  - a 3 word description
  - a 1 liner
  - a 1 para description
  - tags and a name for a hypothetical spec.
 it currently has 500 designs. and it takes me just a one-liner to add many more.
( PS: is 1 minute too much, too less ? )
once i have enough data, i think i'll be able to build an inverted index. ie: given a design pattern or tag => show me similiar designs or "specs".
i was helping a friend of mine train to think like a product manager.
so i built an mvp this weekend http://specthis.parseapp.com
flashcards for GRE/GMAT/TOEFL are well known, but even a google search for specs show practically nothing. mind games for product managers/designers/spec writers are unheard of. perhaps this could even become a github for specs. i have a few 6-7 letter domain names i've soft circled as well.
PS: a major reason for posting here is that i am looking for a designer to collaborate with. if you like the idea, help spread the word. <comment><USER2> App gives an error on facebook login - I sent a link to a screencast of what happens to the email in your profile.

That being said, why use facebook login? I rarely will use a site which requires a facebook login.

<comment><AUTHOR> I've removed fb auth.

check it out now, just enter your email and you should be good to go. I guess i wouldnt be worried about sessions at this stage.

thanks for reporting that & taking time with the screenshot.

~B

</comment></comment><comment><USER3> Left page after pop up blocker blocked what appeared to be Facebook OAuth login.

<comment><AUTHOR> that sucks. i've changed the begin link to open fb login on the main window.

but the "permissions" dialog always seems to open in a popup. thanks for the feedback.

</comment></comment><comment><USER4> Would be great to see what other players have entered. Compare your skills to others. You lose interest pretty quickly without being able to measure your success.</comment>


Show HN: My Open-Source replacement for Reflector. - <AUTHOR>

Sup, HN?
I'm a Mono developer coming from being a Windows developer. One of the things I used every day was Reflector, and since then I've relied on the interface MonoDevelop provides, which isn't all that great all things considered.
So I wrote my own: Mirror.
I've gotten it almost where I want it, but its hit the point where I dont have enough expertise in the world of .NET (and frankly, Comp Sci) to be able to continue much more.
Here's an example of what it looks like, running: http://i.imgur.com/DaTah.png
What I dont have implemented:
- Attributes on anything. They simply dont exist in Cecil's concept of the world. - Getter's and Setter's on Properties. - Class Decompilation - Being Nice (tm) <comment><USER2> Hello Indrora,

Nice work! I'm afraid the link to the mirror is busted. I suggest you upload it to Github (if it wasn't already).

While I don't have great expertise on .NET, I'd be glad to give you a hand.

Also, anything that can leave Reflector and the fiasco around it in the past, is good in my book ;)

</comment><comment><AUTHOR> <https://bitbucket.org/indrora/mirror>

Apparently, the link got lost.</comment>


Help Build the Smart Album - <AUTHOR> http://www.kickstarter.com/projects/thebandfamous/help-build-the-smart-album

<comment><AUTHOR> Remember the ATrack? Remember the Vinyl? We've pioneered the Smart Album. Care to see for yourself? Download our app - The Band Famous - FREE on the iPhone App Store. Have an Android? Hey, me too! This campaign will help us give you our EP "Last Words" and more great music and art for FREE on the Google Play Store, too.

How cool would it be to get our in-app concerts?! If you're living in Minneapolis or LA, and we're doing a concert in NYC, simply open up our app and see our concert wherever you are! You can help that become a reality. Get your rewards today and help us give this platform to the whole world!

Donations welcome and hugely appreciated! Sharing is caring, too.

Every one can have a Smart Album! We're offering super cheap discounts for mobile friendly websites and NATIVE APPS - purchase yours by backing our campaign.

Thank you to everyone who is able to make a donation, and thank you for everyone that is able to help us get the word out.

Norell, Lead Singer of The Band Famous

<comment><AUTHOR> *8-Track (excuse the typo)</comment></comment>


$5k to pitch your business? Who falls for this? - <AUTHOR> http://www.sethlevine.com/blog/archives/2009/11/5k-to-pitch-you.php

<comment><USER2> In Seattle, NWEN does this with their bi-annual angel forum. Also notable is DEMO which is something like $10k-$20k to play..</comment>


How do developers find the time to stay on top of latest technologies? - <AUTHOR> http://programmers.stackexchange.com/questions/177651/how-do-developers-find-the-time-to-stay-on-top-of-latest-technologies/177714

<comment><USER2> come home and spend time working on your pet project using technology that you're learning or want to learn!</comment>


Ask HN: How does LinkedIn's "trending" pulse work? - <AUTHOR> Although I spend a lot of time reading articles on this site, I'm a beginner in terms of coding. I want to know how LinkedIn chooses articles that show up on my feed that for me are labeled "Trending in the Staffing and Recruiting Industry" because they often have nothing to do with the Staffing and Recruiting Industry. For example, today an article from Time titled "Justin Bieber Is Trying to Shut Down This Website" (clickbait) showed up. Is LinkedIn tracking what stories people in my industry are reading in their free time? <comment><USER2> Probably the only answer anyone can give here is "poorly."</comment>


On Facebook, press ↑ ↑ ↓ ↓ ← → ← → B A ↵ and scroll with mouse - <AUTHOR> http://facebook.com/

<comment><USER2> You sure it isn't B A [Enter]? <http://en.wikipedia.org/wiki/Konami_Code>

<comment><AUTHOR> Yeah, sorry -- it's corrected now.

</comment></comment><comment><USER3> Nothing happens for me

<comment><AUTHOR> Sorry, it was "B A". Try again.

</comment></comment><comment><USER4> Pretty cool...I got a specular halo effect when scrolling!</comment>


Why a Universal Basic Income Will Not Solve Poverty - <AUTHOR> http://www.nytimes.com/2016/06/01/business/economy/why-a-universal-basic-income-will-not-solve-poverty.html? <comment><USER2> These numbers are so disingenuous without taking into account a tax rate increase. If you make $100k and pay $20k in taxes now, with a $10k UBI your effective tax bill is cut in half. If you tax rate goes up and you pay $30k in taxes and receive an $10k UBI, then the addition of UBI was net neutral to you.

The reality of a UBI would be the poor and lower middle net more money, the middle middle doesn't change, the upper middle pay slightly more, and rich pay more.

<comment><USER3> I think the idea of "net neutral" will be lost on most people. They will look at their previous years taxes and be upset because they have to pay more.

</comment></comment><comment><USER4> As I see it, "solving poverty" isn't something UBI is supposed to do, at least in the short term. UBI is supposed to reduce the trend of returns of economic gains being distributed disproportionately to the already wealthy; its long- term technology development and resulting productivity gains that cure poverty -- but only if the gains aren't all captured at the top of the pre-gain wealth distribution.

</comment><comment><USER5> The author repeatedly describes work as something done for social status and personal fulfillment. But his conclusion is that UBI will make people not want to work. Which is it, that people work in order to feel productive? Or just to make money?

</comment><comment><USER6> That had some good points, but it grasped for FUD too much of the time.</comment>


PyPy 2.0.1 - Bohr Smørrebrød - c-oreills http://morepypy.blogspot.co.uk/2013/05/pypy-201-bohr-smrrebrd.html

<comment><AUTHOR> Call for donations - PyPy to support Python3! [1] Let's just move on, please.

[1] <http://pypy.org/py3donate.html>

</comment><comment><USER2> For the curious, 'smørrebrød' is a Danish kind of deli offering consisting of rye bread with different kinds of toppings. (Bohr of course referring to the Danish physicist Niels Bohr)

<http://en.wikipedia.org/wiki/Sm%C3%B8rrebr%C3%B8d>

It's very tasty.

<comment><USER3> The usual difference between that and a sandwich is that it is open. While rugbrød (note: rye bread is not exactly the same as rugbrød, which you can only truly obtain in Denmark and Northern Germany.) is the most common, I have seen »smørrebrød« with white bread.

<comment> iso8859-1 My local Rewe here in Hesse has it, I'd say. [https://www.google.de/search?q=ja!+Roggenvollkornbrot&tb...](https://www.google.de/search?q=ja!+Roggenvollkornbrot&tbm=isch)

Since Ja! is the discount brand, doesn't it mean that they sell lots of it? If so, I'd imagine they have this product all over Germany.

And looks like you can get it in Sweden too: <http://www.tjow.dk/Hjemad/slides/t505.html>

<comment><USER3> Neither of those are as rough as rugbrød you get in Denmark. Trust me, I've tried both of them. I've even shopped in Rewe. But they always seem a bit like brown white bread to me.

<comment> iso-8859-1 What is your reference bread? The only difference between Shulstad and "Ja!", that I notice, is that Shulstad has the 1:1 aspect ratio. There's no rye in the bread I linked, so I don't understand how it can be brown white bread to you.</comment></comment></comment></comment></comment>


New Satellite Photos Show Climate Change Is Sweeping Europe - <AUTHOR> https://www.bloomberg.com/news/features/2019-04-09/new-satellite-photos-show-europe-s-changing-climate <comment><USER2> On terrascope.be, there is no such large difference between July 2017 and 2018 satellite images (Belgium, somewhere in the North because images wouldn't load for some areas):

[https://viewer.terrascope.be/terrascope/?language=en&date=18...](https://viewer.terrascope.be/terrascope/?language=en&date=18/7/2017&bbox=2.5988830532184575,50.88935237388327,2.925726314937208,51.05948508356582&overlay=true&compareEnabled=true&layer=CGS_S2_RADIOMETRY&baseCompareDate=2017-07-18T10:13:46.000Z&compareLayer=CGS_S2_RADIOMETRY&compareDate=2018-07-15T10:00:28.000Z)

This may well be before/after harvest or early vs. late July images on bloomberg.com - it's such things that have made me very skeptical about the climate change debate. And of course, some people are quickly downvoting facts they don't like.

<comment><USER3> There _is_ a notable difference between the images you link. Apparently [1] the drought/heat wave in Belgium started on July 13 2018 (and ended on 7 August), so the image-pair you link was near the beginning of the event. The data on the nifty pair-viewer you link to is sporadic, so it's tedious to find other matches.

But another story centered on the same theme already found matches:

[https://www.businessinsider.com/satellite-images-shows- whole...](https://www.businessinsider.com/satellite-images-shows-whole- nations-fried-by-this-summers-heatwave-2018-8)

It shows a bunch of 2017/2018 image-pairs from places like Sweden, Denmark, and Germany with features from the drought.

Surely we are not arguing that there was no drought during that year, or that it's somehow not visible from remote sensing data?

[1] [https://en.wikipedia.org/wiki/2018_European_heat_wave](https://en.wikipedia.org/wiki/2018_European_heat_wave)

<comment><USER2> > Surely we are not arguing that there was no drought during that year, or > that it's somehow not visible from remote sensing data?

We're arguing that there is a difference between thorough scientific methods and carefully picking out selected data points to show a dramatic situation that isn't.

<comment><USER3> It's pretty clear that the 2018 heat event was indeed an exceptional event, especially in Northern Europe. This is not "a dramatic situation that isn't".

Of course articles in the popular press are going to use different narrative techniques ("give them concrete examples!" is the usual advice to science writers) than scientific papers would. So if you want "thorough scientific methods", you'd have to look elsewhere.

This is the closest I've found to an attribution study of to what extent climate change is responsible for this heatwave event:

[http://www.ox.ac.uk/news/2018-07-27-heatwave-made-twice- like...](http://www.ox.ac.uk/news/2018-07-27-heatwave-made-twice-likely- climate-change)

A gloss on the larger significance of the report in the growing area of "attribution" is here:

[https://www.nature.com/articles/d41586-018-05849-9](https://www.nature.com/articles/d41586-018-05849-9)

<comment><USER2> > _an exceptional event, especially in Northern Europe. This is not "a > dramatic situation that isn't"._

Exceptional, yes. Unprecedented, no.

> _So if you want "thorough scientific methods", you'd have to look > elsewhere._

I'd be happy if there was less cherry-picking and more linking to raw sources for verification. If this was about people of particular ethnicities committing crimes, people would cry foul and "racism" at such hand-picked examples.

</comment></comment></comment></comment></comment><comment><USER4> There was a european heat wave in 2003 that killed thousands a day and 70,000 total[1]. If 70K people in the US died from a single large climate change induced event change, people might start to talk.

[1][https://en.wikipedia.org/wiki/2003_European_heat_wave](https://en.wikipedia.org/wiki/2003_European_heat_wave)

<comment><USER5> The heat wave lasted 25 days (using the above poster's dates). That's a run rate of almost exactly 1 million additional deaths per year.

Given the European population of 741 million, and an 80 year average life span, then they were able to attribute an additional 0.001686909582% of deaths to climate change.

That's roughly two out of one thousand signal to noise ratio. [0] According to one study medical examiners disagreed on cause of death in 12% (TWELVE PERCENT!!!) of cases. [1 & 2]

Either my math is bad (definitely possible), or I'm calling bullshit on the numbers.

[0] - my calculation was as follows: 70,000 deaths / 25 days * 365 days per year / 741,000,000 people in Europe / 80 year life expectancy * 100.00%

[1] - [https://www.ncbi.nlm.nih.gov/pubmed/29091542](https://www.ncbi.nlm.nih.gov/pubmed/29091542)

[2] - [https://www.thename.org/assets/2018Handouts/2.3%20-%20McGive...](https://www.thename.org/assets/2018Handouts/2.3%20-%20McGivern%2C%20Lauri.pdf)

<comment><USER5> If you downvoted me, then show your math. At least I put mine out there.

</comment></comment></comment><comment><USER6> Not sure how to feel other than sick about this. I wonder what more it will take to have something actually be done about this, haha.

<comment><USER7> It seems like an issue would be the requirement of massive cuts into freedom - possibly preventing people from pursuing their livelihoods. At the very least, these livelihoods have to be significantly shifted. Convincing people to support or even drive these uncomfortable changes in their lives is more than hard.

Look at car manufacturing. I doubt we will be able to 1:1 replace jobs related to combustion-engine based cars. There are so many parts and corresponding suppliers involved. It all vanishes with electric cars due to their comparative simplicity. From resources mining to car mechanic - many people are directly affected.

Of course new jobs will arise with electric cars, new mobility and computerized driving. But those are not for the drive train engineers, manufacturers and related workforce. Those will be for new, highly trained individuals or appear in a different sector, such as service - and that is if these new jobs aren't automated anyways.

Replacing plastic straws is facing severe opposition because the alternatives are not well liked. For quite a lot of people it is more important to have a non-soggy straw than to let one less bird die.

Many of us are also ready to reduce flying, especially ridiculously cheap flights that make your carbon footprint explode. Others, less fortunate than us, depend on such flights for their only vacation this year.

Are we going to take that away from them in the name of climate by imposing a carbon tax? Should a flight from Northern Europe to Tenerife really cost 90€ while blowing enormous amounts of CO2 into the damaged atmosphere?

We are getting into authoritarianism here at some point...

<comment><USER8> One thing I am finding really nuts is that, in spite of what we now know about climate change, North American drivers are currently thirsting for larger and larger, less fuel efficient, very expensive trucks and sport utility vehicles. Auto manufacturers are currently tripping over themselves to design and produce larger vehicles to satisfy that demand.

Given that, I have a _really_ hard time reconciling the "we just can't do anything, sorry, it'll hurt our freedoms" attitude with the "I don't care about my CO2 output" attitude that is evident in the consumption behaviours of most people I see. It's as if they consider outputting tonne after tonne of carbon into the atmosphere as a point of pride or immutable entitlement.

<comment><USER9> The data shows that the U.S. lowered emissions in 2017 and 2018 more than other major countries. A fraction of the <10% of emissions that personal vehicles make up isn't worth focusing valuable attention and effort toward.

[https://reason.com/blog/2018/05/04/us-carbon-dioxide- emissio...](https://reason.com/blog/2018/05/04/us-carbon-dioxide-emissions- down-europea)

[https://www.forbes.com/sites/rrapier/2017/10/24/yes-the- u-s-...](https://www.forbes.com/sites/rrapier/2017/10/24/yes-the-u-s-leads- all-countries-in-reducing-carbon-emissions/)

<comment><USER8> Our views on vehicles and vehicle fuel consumption are symbolic of how we view our commitment to lowering emissions. People aren't buying huge SUV's because they've analyzed the data to determine that the relative impact of their consumption isn't worth buying a smaller vehicle. They are choosing to spend more on fuel-guzzling vehicles (and spend more on fuel) because their consumption and output is an afterthought.

While total overall emissions (in the U.S.) may be steady or shrinking, the total amount of emissions for transportation is growing. There's no excuse for that. All it tells us is that an overall reduction in GHG emissions _could be even lower_ if people made slightly more conscientious transport choices.

[https://rhg.com/research/preliminary-2017-us- emissions/](https://rhg.com/research/preliminary-2017-us-emissions/)

<comment><USER10> "People aren't buying huge SUV's because they've analyzed the data to determine that the relative impact of their consumption isn't worth buying a smaller vehicle."

Just curious how you know this to be true.

<comment><USER8> It's an assumption. Would be happy to be proven wrong if you know otherwise.

<comment><USER10> Anecdotal only, but I notice my friends with more than 3 kids need a larger vehicle. Also, heavier vehicles are safer for the passengers. And some people need to carry cargo.

I'm sure not everyone has a 'good' reason, but a fair number of people do make a conscious choice.

<comment><USER8> My assertion wasn't I assumed that people aren't making a conscious choice, but rather that they aren't pouring over international carbon emissions data as part of that decision making process.

As far as what families feel they "need", I think it represents a larger societal issue around how we manage vehicle use and ownership. Most pickup trucks I see on the road aren't hauling cargo. And most 7 or 8 passenger SUVs have 1 or 2 people in them.

> Also, heavier vehicles are safer for the passengers.

Yes, for the passengers in that particular vehicle. More dangerous for others on the road who can't afford or are unwilling to purchase a similarly sized vehicle.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Summer of 2017 was dull and rainy, 2018 was scorching heat. So what? This isn't a direct indication of climate change, we have had varied seasons since forever. You didn't take the cool summer of 2017 as an example of debunked climate change either... silly article.

</comment><comment><USER12> Anyone know where the highest res image data sets are available? I tried looking on [https://www.copernicus.eu/en](https://www.copernicus.eu/en) but it's a bit of a maze

<comment><USER13> Although it is not stated in the article, I suppose it is Sentinel2 (with highest resolution 10m for bands Red, Green, Blue and Near Infrared).

The data is available for free and accessible via Copernicus or at major cloud providers.

</comment></comment><comment><USER14> "Heatwaves and little rain led to rarely seen forest fires in Sweden in July 2018."

Rarely seen, as in, seen before, presumably before the current level of climate change.

I wish articles like this would give some context, such as rare: once in 10/100/1000/10000/100000 years?

Also, satellite images in the last several years can't be compared with satellite images 100 years ago because man-made satellites didn't exist back then. So this is more of a snapshot with little context.

How does this compare with the medieval warming period as far as impact on agriculture?

<comment><USER15> > How does this compare with the medieval warming period as far as impact on > agriculture?

It's been so dry in germany that river levels sunk far enough to make so- called hungerstones visible again. These mark historic low levels that are associated with severe droughts and starvation. The fact that we're not starving is a testament to how much modern agriculture improved our resilience, but there's a limit to that.

[https://de.m.wikipedia.org/wiki/Hungerstein_(Wasserstandsmar...](https://de.m.wikipedia.org/wiki/Hungerstein_\(Wasserstandsmarkierung\))

<comment><USER16> I've not understood how this demonstrates unprecedented climate change, since presumably there is past precedent that laid the hungerstones in the first place. This seems to demonstrate this level of warming happened before in the medieval ages, before human caused global warming was possible. Wouldn't this mean hungerstones count as evidence against human caused global warming?

<comment><USER17> Depends, how many uncorrelated rare (in the no global climate change hypothesis) events are simultaneously occurring?

<comment><USER16> Yes, that's a good point. But, then what is our basis of comparison? When the hungerstones were laid was there not similar warming going on elsewhere? Without knowing this, it is hard to draw conclusions from the hungerstones.

</comment></comment></comment></comment></comment><comment><USER18> Bitcoin has earned a lot of the blame here:

[https://motherboard.vice.com/en_us/article/ywbbpm/bitcoin- mi...](https://motherboard.vice.com/en_us/article/ywbbpm/bitcoin-mining- electricity-consumption-ethereum-energy-climate-change)

>one transaction now uses as much energy as your house in a week

[https://www.theguardian.com/technology/2018/jan/17/bitcoin-e...](https://www.theguardian.com/technology/2018/jan/17/bitcoin- electricity-usage-huge-climate-cryptocurrency)

>In November, the power consumed by the entire bitcoin network was estimated to be higher than that of the Republic of Ireland. Since then, its demands have only grown. It's now on pace to use just over 42TWh of electricity in a year, placing it ahead of New Zealand and Hungary and just behind Peru.</comment>