Node.js has jumped the shark - <AUTHOR> http://www.unlimitednovelty.com/2011/10/nodejs-has-jumped-shark.html <comment><USER2> Am I the only one that considers all of this ranting about Nodejs to be a little bit strange?

I would have never expected a post that was obviously a troll to prompt this much of a reaction on both sides of an issue. That so many of these rants and counter rants made it to the front page of Hacker News is somewhat discouraging.

I have been playing around with node for a few months, and I have tried to stay completely out of this "conversation". With that said, I would like to contribute just a few points:

Bad programmers will be bad programmers regardless of the tools that they use. If they use node and fail to write code that is completely non-blocking, then that is what we call a teachable moment. There is no magic button, all technologies have downsides and tradeoffs.

People keep talking about how nodejs is not good for computationally intensive tasks, but v8 is not a slow environment. Am I the only one that puts computationally intensive tasks into a queue to be taken care of by a pool of seperate processes? I am only just getting into web programming, and it seemed fairly obvious to me that you would not put something like that into your main event loop.

Also, if you find that you must put something computationally intensive in your main event loop, then you should use something like node-proxy or nginx to proxy those requests to a number of "nodes".

Over and over again, I have seen that people complain that node is not a good multithreaded environment. Well, yes... That is the tradeoff of using something that is closely tied to the concept of the event loop.

If you are using node because you feel comfortable with threads and you need threads, then you are making a serious mistake. If you are a new programmer and you are using node because someone told you that it is cool, then you are making a serious mistake. If you are using node because you have a problem that can be solved or addressed with an event loop and you understand the tradeoffs inherent in this approach, then you are doing the right thing.

To use nodejs effectively will often require rethinking your approach to fit the tool that you are using.

<comment><USER3> I think this post is about ridiculing the childish behavior of the Node.js fandom. I have to agree that I've never seen anything quite like this before except the Church of St. Jobs. I always thought that we software engineers are reasonable people. But apparently a subset of us aren't.

However reluctant I maybe to join in this time-wasting back and forth. I'm just glad that someone has taken the time to point out just how inexperienced the crowd and ridiculous the whole situation is. We have enough technology in the world already. We don't need another one that makes making mistakes so much easier than before.

Lastly, I'm extremely disgusted by the misleading tag lines Ryan Dahl put on Node's front page. Programming isn't easy. It can only be easy for so long. Scaling is even harder because it actually requires deep knowledge and insight into how computers and networks work, something that I very much doubt that many of the current Node.js crowd understands. If your solution to your multiprogramming problem is to spawn more Node.js processes, maybe you've picked the wrong tech.

<comment><USER4> I've seen it from the following communities: PHP, Ruby, Perl, Python, Java, C++, C, C#, Haskell, Emacs, Vim, Common Lisp, and Scheme.

People are tribal. Some people are attracted to tribes, become attached without really knowing why, and start having the strong urge to fuck with the other tribes. Apparently this was good for the survival of the human race. Perhaps it's a bug now that we should consciously compensate for, like the desire to eat a box of doughnuts. mmm.... doughnuts... Good when you were a caveman. Bad when you sit in front of a desk for 16 hours a day and sleep for the other 8.

What's the alternative to scaling an application by running multiple copies? Scaling an application by running multiple threads? Exact same thing. The only advancement over this model is when the runtime can automatically parallelize your code, and you actually scale linearly when it does that. In the mean time, if you use a database server and not an in-memory database, guess what, you're "using queues" and "scaling by starting processes". People do it because it's easy and it works.

<comment><USER5> __People are tribal. Some people are attracted to tribes, become attached without really knowing why, and start having the strong urge to fuck with the other tribes. Apparently this was good for the survival of the human race. Perhaps it's a bug now that we should consciously compensate for__

That this tribal behavior occurs among software engineering is a rather disappointing fact. Computers are pretty much the edge of technology in many aspects, technological achievements by Mankind should be the prove that we're able to use our brains in more advanced ways than basic instincts and produce great achievements like modern software.

This flood of programmers that prefers to join a tribe instead of enjoying the good things from many different 'tribes' just makes me wonder how many of us are really devoted to do something useful/positive.

<comment><USER6>
      > That this tribal behavior occurs among software engineering
      > is a rather disappointing fact.

It occurs amongst software engineering _humans_. All humans get this to some degree, it's basic ingroup/outgroup psychology.

We're all humans here. It's nothing to do with "devoted to doing something positive" or "using our brains in more advanced ways." It's just the reality of being an evolved ape, and the lack or presence of this trait doesn't make anyone any better/worse than anyone else.

<comment><USER4> Yes, thank you for writing this. We are all humans, even if we don't want to be, and we have to think about our actions in the context of our genetic programming. In the case of tribalism, even though it's a strong feeling, we have to ignore it because it doesn't get us anything in programming language debates.

The best attitude to have is one of acceptance and an open mind, because the right programming tool applied to the right problem can make solving that problem orders of magnitude less difficult. You can have programmer friends even if you don't unconditionally hate the enemy. In fact, it seems, most people don't care about who you don't hate.

</comment></comment></comment></comment></comment></comment><comment><USER7> It seems we now have three camps:

1\. "Node is the magic bullet."

2\. "Node sucks."

3\. "Nothing is that simple. Learn you some computer science."

#3 is the correct answer, but I'd like to see this point explored in more detail. The current back-and-forth isn't productive. What would be productive is if we had an informed discussion of what Node is good at, what _not_ to do with it, and how it compares with other tools and approaches.

Specifically, I'd love to hear opinions on some of these points:

* Node is opinionated about threads. Negatively so. See <http://nodejs.org/#about> . Do you agree with these claims?

* Non-blocking IO doesn't solve every performance problem under the sun. Far from it. But what problems does it solve exceptionally well?

* Is Node a breakthrough in computer science? Events and callbacks have been around for ages. What new ideas does Node bring to the table?

* Why exactly is Node supposed to be so scalable? Is scaling to more machines easier with Node than with other approaches? How about scaling to more cores on the same machine? Does Node provide any special support for distributing a task across multiple workers and possibly over the network, e.g. with something like MapReduce?

<comment><USER8> #3 isn't even necessary -- you're telling someone to go learn calculus when all they really need is basic algebra, at most.

2-3 hours spent on layman's summaries of the practicalities of modern CPU architectures (special attention to cache coherence, what fun), user vs. kernel space and switching between them, select() and its cousins, and TCP would do most of the people involved in these debates a world of good.

<comment><USER7> I'd venture that 2-3 hours is far too little for someone to learn the topics you list from the ground up. But I'm just nit picking :). Your point is well- taken.

But one big problem is that these are unknown unknowns for many people. Suppose a new but intelligent programmer finds Node and wants to decide whether it's good for some new project. How would that programmer know what to look up? How would s/he know that, e.g., user vs kernel space is even a relevant concern in the decision to use a single-threaded, event-based framework?

</comment></comment></comment><comment><USER9> All right guys, this is getting absurd.

I am having a ton of fun using NodeJS to _actually build stuff_. It's fast, it's scalable, it's maintainable, it's great.

Yet another pants-on-head troll has decided that NodeJS is a crime against his tech religion? _I don't fucking care._

<comment><USER10> Actually, this is getting pretty funny. Don't bring your logic and reason to this and ruin for those of us who just bought a bag of popcorn.

</comment></comment><comment><USER11> This is the worst rant I've read in a while.

It starts with lambasting the fact that Ted Dziuba didn't intend the Fibonacci example to be the one role model of comparing Node.js and other languages, and then the Node.js community (or at least a few members of it) rallied around showing that Fibonacci was actually fast in Node. I agree with this. We should be talking about the big picture, not just single implementations.

Then, it goes on for 4 paragraphs about how slow Node.js was with Fibonacci.

Wasn't it the point that Fibonacci _wasn't_ the point? If the point is to show that Node.js is inefficient with computation, and Fibonacci was just a dumb example, why was the rest of the article about the dumb example mentioned previous?

<comment><USER12> I thought the point of this article was to generate a cliff notes version of the last week of arguments, coming from the side of someone who thinks node is cancer. Why are we even discussing this?

<comment><USER11> Yeah. I really want to see this discussion taken in a direction where we're _actually_ talking about Node.js and its computational (non-?)efficiency, instead of this needless back-and-forth.

</comment></comment></comment><comment><USER13> Best part of the post was where someone suggested he increase his heap size to 1GB to get a fibonacci algorithm to run.

       After pointing this out, a member of the Node.js
       community (post now deleted) suggested I might have an
       obsolete version of Node with a 1GB heap limit and that
       I recompile without the 1GB restriction so that this
       retarded algorithm can continue eating up all my system RAM.

<comment><USER14> It is curious that an array with 1 million doubles would take anywhere near a gigabyte in V8. 1000000 * 8B is about 8MB. Even with 5000% overhead for the data structure itself, that's only 400MB. Where did the other 600 MB go?

<comment><USER15> Call stack?

</comment></comment></comment><comment><USER16> Author seems to have missed that node-fib is a joke.

Ted Dziuba is clearly a person suffering from profound intellectual insecurity, and a lack of technical acumen. We should offer him our sympathy rather than enable his self-destructive behavior by praising his "previous trolling" activities.

This article, like the poor sad unfortunate Mr. Dziuba himself, seems to be combatting a strawman: the idea that Node.js users and developers are advocating that it be used for everything. It's a fun platform to use, and pretty good for a lot of tasks, but any grownups close to the project (and there are a few of us) are quite vocal about the fact that it is targeted at a very specific use case: IO-bound network programs.

People get excited about the programs they use, and want to see how well it can do things. When your hammer is fun to swing, you want to see what happens with you hit stuff with it. Ted Dziuba has previously advocated using xargs instead of Hadoop for parallel map-reduce, so I would have thought he might understand that sometimes you use the tool that you understand (if it works) rather than something else, even if that other thing might be objectively better for that particular task.

I don't know what node users articles like this or Ted's are talking about. I've been using node almost as long as Ryan, and totally love it. I don't know how we could be more clear about what node is and isn't good for.

At NodeConf, in the Committer Panel, someone asked, "What _isn't_ node good for?" We all rattled off a variety of things. The node community is actually pretty sane. We just laugh at stuff like this, since it's so ridiculous, and make jokes like node-fib.

<comment><USER17> > Ted Dziuba is clearly a person suffering from profound intellectual > insecurity, and a lack of technical acumen.

Perhaps, as the one responding to a criticism of a piece of software with personal attacks, you are the one that is insecure? I can understand how, as a fanboy of something that was criticized, you would now take it upon yourself to hurl insults on the person who has wronged you so. This is the internet after all!

> We just laugh at stuff like this, since it's so ridiculous, and make jokes > like node-fib.

Actually, you opened this comment by personally attacking Ted, because he insulted some software you happen to be a fan of. I think the most likely reason that you would contradict in such an obvious way something you just wrote is that you don't have a great deal of working memory. Looking at your code on github (<https://github.com/isaacs>) seems to confirm that theory.

<comment><USER16> > I can understand how, as a fanboy of something that was criticized

Can you define "fanboy" for me, please? I don't know what it means.

> Actually, you opened this comment by personally attacking Ted

I wasn't attacking Ted. Actually, my heart really does go out to him. I mean, he's a human being, right? Could you imagine living with such a crippling psychological disorder? Just think of it. The pain, the emptiness. The worst part is that he's almost certainly too proud to ask for help. It's tragic.

> I think the most likely reason that you would contradict in such an obvious > way something you just wrote is that you don't have a great deal of working > memory.

Sorry, I lost you like a third of the way through that sentence.

<comment><USER17> How is saying that someone has a psychological disorder not attacking them?

<comment><USER16> Your comment is indicative of the anti-mental-health sentiment in our society: that diagnosing or treating mental health issues is an admission of failure, rather than a sign of courage and responsibility.

You should check your priors, and maybe help create an atmosphere where people with these problems don't feel like their only options are denial or self- destruction.

<comment><USER17> Since you're giving out free diagnosis over the internet, would you mind doing me?

<comment><USER16> I'm just saying we should be supportive of Ted's recovery, rather than enable him, that's all.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> tl;dr;

Don't use JavaScript for numerical computation. Don't block your IO loops for CPU intensive stuff.

commentary:

I've never met a Node hacker who would ever do any of those things. This post should be called "Straw man Node.js n00bs jump the shark."

I've written web apps in a wide variety of dynamic languages, and you know what, I've never done anything CPU intensive in the request response loop, ever. This has nothing to do with Node, fibonacci in PHP is just as bad an idea (although it might take you a little longer to realize it, as you've probably got lots of PHP threads running behind your Apache).

<comment><USER3> If you've been following this argument from the beginning (I'm very sorry to say that I have), you'll notice that Ted's point is not that you _WILL_ do CPU bound tasks in Node, but that Ryan Dahl's misleading statements on Node.js's front page is absurd. Of course no one with any sense will put CPU bound jobs on the same process/thread/event queue as the one processing the request. But you do have to realize, it is exactly that no one will ever do the above that renders Node's existence rather pointless. Threads/processes or events, you'll still pass off the heavily computational stuff to a different processing queue. Events or threads, when that single process starts topping out, you'll still have to launch another process. What makes Node.js different from any other technology that have come before? Nothing except that it comes with a server and it's written in JS. If you like the Node REPL and JS, that's fine, just don't propagate the urban myth that's on Node's front page. I think this is Ted's point IMHO.

</comment></comment><comment><USER19> This only proves that many in node.js community and some trolls outside of it don't really understand programming at the event level, BUT insist on writing about it.

First, you shouldn't judge anything by the worst of its kind.

Second, why I keep seeing related stories piling one misunderstanding on top of another on Hacker News?

</comment><comment><USER20> Hmm, sounds more like reddit is the thing that has jumped the shark :)

Most people using Node I've had contact with are firmly in the 'right tool for the job' camp. No one sane does CPU intensive tasks inside the event loop... that's what delayed job processor stuff is for.

<comment><USER21> That's my takeaway as well. Who cares how long a webserver takes to do a Fibonacci loop anyway? The point of a web server is to process lots of relatively small requests quickly and concurrently. Testing node.js with a Fibonacci loop is like testing a Ferrari by seeing how much weight it can tow.

<comment><USER22> Testing Ferrari by seeing how much weight it can tow would actually get you pretty useful performance metric.

Point of this whole thing is that you cannot reasonably do complex computations in Node. While most "Web 2.0" applications probably does not need to do that in response to request, there are also many web applications that actually do something that might be reasonably called complex cpu-intensive processing in response to user request (although most such things are hard to scale). So it really boils down to "right tool for the job" - and for many practical (but maybe un-popular) problems, Node simply is not the right tool.

<comment><USER23> This is a serious question, because I honestly don't know the answer. What purpose does node serve in more complex(i.e. non-static page) situations?

Should it just be the intermediary between the users and your database process? Heck, should the database process also handle all the formatting of the data as well as the queries? That is fairly CPU intensive(and doesn't scale well at all), especially if you're getting to larger data sets.

</comment></comment></comment></comment><comment><USER24> I'm just tired of this, it's beyond dumb.

I remember the spectacle of the Java hype machine and the dot-com 1.0 hype machine. In comparison the node.js hype doesn't even register on the meter. Moreover, I don't see a rash of people misusing node.js to the degree that is prevalent for pretty much every other web technology out there. Are some people going to misuse technology? Always. Is the node.js community out there trying to proselytize to the world, selling node as the solution to every problem on the planet for every developer on the planet regardless of whether it makes sense? Not in the least.

This is a faux-controversy.

</comment><comment><USER25> And the point of this is?

You use Node.js for writing evented programs using Javascript. It is awesome for that. It is better than PHP, and a bunch of other solutions, for actually handling web clients. Heck, it brings us back to the days where we can handle the C10K problem without much work! And it's friggin Javascript!

All these politics are missing the point. This blog post is missing the point. Things SHOULD be simple. There SHOULD be an insanely fast evented solution to do things. And there is. Get over it.

<comment><USER26> I'd never heard of the C10K (<http://www.kegel.com/c10k.html>) but I love scaling issues and this looks to be some fascinating reading. Thanks!

 __EDIT __Interesting annecdote... Cal Henderson is the author of "Building Scalable Websites"<http://www.amazon.com/gp/product/0596102356> and has worked in "the trenches" as the lead engineer of FLICKR and developer at B3TA.

Apparently his newest company <http://tinyspeck.com/> is using node.js for their game engine.

Assuming he's planning on scaling to a reasonable size, that seems to be a pretty resounding endorsement that there's at least something going for it. I mean ... that guy's got a bit of experience in working at scale.

</comment></comment><comment><USER27> I'm very glad the node.js community got trolled so effectively. It's been clear for a long time that these most of these advocates are not grounded at all in reality, and it was very entertaining to have them revealed in their ignorant zealotry. Evented solutions have been available in every modern language for some time. They aren't used that often though because they have serious inherent limitations!

I understand the appeal of node.js. It makes the web stack feel much less complex, and I like to reduce complexity as much as the next guy. But in the end, node.js is just a thin wrapper on top of a simple C library. In the end, it really only excels at solving a small, narrow, niche problem.

</comment><comment><USER28> I use node.js for long-lived connections (sending/receiving large amounts of data, or long-polling). This is a task to which it is ideally suited. Putting CPU-intensive operations inside a HTTP handler is something that is _obviously_ not going to work in a single-process, single-threaded event- driven framework. Ted's complaining because node.js is unsuitable for something that it's not intended to be used for.

Defending CGI, in my opinion, also hurts his credibility. The "good old days" weren't so good. Spawning a new process for each request? Re-establishing database connections every time? That shit only worked because there were three people on the internet at the time.

<comment><USER29> _> Defending CGI, in my opinion, also hurts his credibility. The "good old days" weren't so good. Spawning a new process for each request? Re- establishing database connections every time? That shit only worked because there were three people on the internet at the time._

Apparently the server behind SQLite.org and Fossil-scm.org, which gets 250M requests/day, spawns a new HTTP server for each request. There's no database, though.

[http://firstname.lastname@example.com- scm.or...](http://email@example.com- scm.org/msg02065.html)

<comment><USER30> fossil-scm.org uses SQLite database (in WAL mode), and the website is the repository itself.

[http://www.fossil- scm.org/index.html/doc/trunk/www/selfhost....](http://www.fossil- scm.org/index.html/doc/trunk/www/selfhost.wiki)

<comment><USER29> Oops. Thanks.

</comment></comment></comment></comment><comment><USER4> This article is terrible. It boils down to "Ted stirred up some shit in the node community, which I like to troll because I wrote my own programming language and see node as the enemy. As a result of the shit-stirring, people that don't know much about programming defended node. Meanwhile, I wrote my own programming language that nobody uses because nobody is as smart as me, the creator. What's up dawg?"

OK. You have to realize what the community is and isn't. The community isn't every person with a blog. Those people are fanbois; and they exist everywhere.

You've got to filter the noise out. Don't submit every article about something to HN. Don't tell your friends "hey, read this article about a guy memoizing fib, completely missing the point that it was an example CPU-bound algorithm". This is all noise, people that don't know what they're talking about talking.

So, is accidentally blocking an issue in node? YUP! Is leaking space in Haskell something you should worry about? YUP! Is passing a string to a function that requires an int something to worry about in Ruby? YUP! Should you lose sleep at night worrying about whether your Java application is leaking memory? YUP! Should you have nightmares about input data causing your C program to write to memory it didn't allocate? YUP!

Why do you think writing working software is difficult? Because we all have phenomenal tools but are just morons? Nope, we're all morons and we have shitty tools too. All programming languages suck. So you must use them for their strengths, not their weaknesses.

Node.js' strength is that it was designed from the ground up to do everything that can be done asynchronously asynchronously. This is mostly due to the standard library and a bit of C, rather than something intrinsic to the runtime or language. The problems it runs into are CPU-bound computations. People are afraid to split applications into many processes and have some existing tool "scale" them as necessary. As a result, node.js does not work for them, because it doesn't have Java-style threads, which is the hammer they want to use to drive in their screws.

Anyway, I don't really even like node.js that much, but it just feels worth pointing out that no other language solves the denial-of-service problem. If you use preemptive multitasking, you eventually run out of memory for threads. If you use an event loop, blocking starves the other handlers. If you use multiple processes, your process table fills up. The question is: how are you going to deal with it. If you write a thread-based application, you have to figure out how to collect blocked threads (and hope the OS schedules your collector thread). If you write a process-based application, you have to figure out how to collect hung processes. If you write an event-based application, you have to figure out how to ensure you never block. In the end, all three problems are equally hard. It's just that node makes it easy to make 100000 connections hang without killing your Chrome session with your blog editor in it. Write a CGI script in C, use mpm_prefork or something, hit Apache with a million connections, and watch the OOM killer annihilate your system.

Programming is hard. Let's stop blogging.

<comment><USER10> > You've got to filter the noise out. Don't submit every article about > something to HN. Don't tell your friends "hey, read this article about a guy > memoizing fib, completely missing the point that it was an example CPU-bound > algorithm". This is all noise, people that don't know what they're talking > about talking.

>... Programming is hard. Let's stop blogging.

The problem with this sentiment is right now too many programmers equate popularity with quality. Their only esthetic is "X number of people follow the project on github". Combine this with the relative inexperience of most programmers and we've got a situation where you can easily flood the market with shitty technologies that only work because everyone believes in them, not because they actually work.

I'm not really talking about Node here, but more your assertion that "this is all noise and us serious real programmers should ignore it". The sad reality is, real serious programmers should speak out about shitty popular technologies before every job requires "20 years Node.js experience".

I'd love for the state of the art to be defined by the state of the art, but sadly, it's currently defined by the best marketing and propaganda. Answering that propaganda with criticism _and_ writing better software is the real answer.

<comment><USER31> Didn't a similar event occurred a few years back (in HN as well)? Like around 2006-2007 with Ruby on Rails and the framework war? Big waves, big disagreements, flame-wars.

Good prediction though Zed, I'm seeing ghetto Ruby (Rails related code) lately.

Then it becomes the language wars between newer dynamic/functional languages.

Now it becomes Node.js vs the rest of the world. Are we going to see crappy JavaScript code soon?

PS: At the very least, Rails brings real productivity value to the table (cause all other frameworks sucks back then).

<comment><USER32> _crappy JavaScript code soon_

Is there any language in which a larger quantity of crappy code has _already_ been written?

<comment><USER31> Good point. Should've put "Server-Side JS code" maybe?

</comment></comment></comment></comment></comment><comment> ryan-allen I think the way we talk and reason about tech has jumped the shark.

* JavaScript is a nifty little language. * V8 is a nifty little VM. * Node is a nifty little project. * Isn't it lovely that Ryan Dahl had an idea and like, actually did it! He doesn't write ranty blog posts (often), he writes code for people! * There are worse things to rant about. Things that come to mind are the GFC, the US Govt. Bailout, indications it didn't work, education, unemployment. Lots worse things than Node JS.

P.S. If you ever deployed a Rails app to production then, well my friend, the joke really is on you!

</comment><comment><USER33> Jumped the shark posts have jumped the shark.

<comment><USER34> "Jumped the shark" considered harmful.

<comment><USER35> "Jumped the shark" posts are an antipattern.

<comment><USER36> "Jumped the shark" joke comments are the sort of thing HNers vote down.

<comment><USER37> Is """'"Talking about being down-voted before you voice an unpopular opinion" posts have jumped the shark' is dead!""" the "Considered Harmful"-Killer?

<comment><USER36> I think that's what happened. I guess my meta joke was misunderstood...

<comment><USER38> jokes are not appreciated

</comment></comment></comment></comment></comment></comment></comment><comment><USER39> Besides entertainment value doesn't all of this back and forth reduce down to the age old "use the right tool for the job in front of you"?

Node.js as it currently stands isn't the best solution for applications that will involve CPU intensive tasks. Perhaps at the outset of a project you don't know when and where those types of tasks will pop up so basing an entire architecture on it might be risky.

However, it seems to me that regardless of the above, there are tasks Node excels at and it would be silly to dismiss it as a technical solution all together. I'm building browser based games with it and love working with Node. The bulk of the logic is in the client and Node serves as the glue that allows people to play games together from different clients. Nothing I have read gives me pause about this implementation.

</comment><comment><USER40> I'm pretty sure the only sane way to implement CPU intensive tasks in Node and browsers are web workers. Not sure about the state of web worker support in Node but the resulting code should be straightforward. Even so, the speed of JavaScript is limited, so any serious number crunching will be a pain in the ass.

Node and browsers are seldom used for CPU intensive tasks for now, so it's not a priority.

There are alternatives that handle node's current warts elegantly, can do serious number crunching painlessly, but just don't have the cool factor.

</comment><comment><USER41> Javascript integers can only reliably represent values up to 2^53, as they are implemented by 64-bit floats [1]. This means that fib(73) and below are correct, but fib(74) and onwards are almost certainly going to be wrong.

The one-millionth fibonacci number, fib(1000000), has 208988 digits when written as a decimal. It takes about a minute to compute fib(1000000) with python 2.6 and write it to file.

I am completely missing the point, but this does amuse me. Framework/language pissing match descends into performance benchmark battle where no-one cares about correctness?

1\. [http://www.jwz.org/blog/2010/10/every-day-i-learn- something-...](http://www.jwz.org/blog/2010/10/every-day-i-learn-something- new-and-stupid/)

<comment><USER42> Minute is too long:

      $ time curl -s http://localhost:1597/sicpfib/1000000 >sicp.out

      real    0m1.856s
      user    0m0.000s
      sys     0m0.000s

      $ wc sicp.out
           0      1 208988 sicp.out

<https://github.com/zed/txfib>

</comment></comment><comment><USER43> I have a question about Node.js I hope it's legitimate.

If I have a endless loop in some method that is supposed to generate some part of some webpage of my webapp will it stall the whole app until I restart the server?

From my tests it seems so.

What additional facilities are required to be used so that single bug won't kill the whole app for all users?

Rant mentiones putting nginx in front of node.

UPDATE:

It seems that there is a tool called monit that can restart your server when it stalls:

<http://howtonode.org/deploying-node-upstart-monit>

</comment><comment><USER44> Isn't it the point of all this madness that jumping the shark for these small and trivial problems is fun and thought provoking?

<comment><USER45> Jumping the shark is the moment when something, such as a TV show, or in this case a community around a web framework, begins to decline in quality beyond recovery, so "jumping the shark for these small and trivial problems" really doesn't make sense.

<comment><USER46> No, "jumping the shark" is a single event so monumentally stupid that the show can never recover from it.

Node.js didn't jump the shark. It has some stupid users, but what language doesn't? That he got stupid answers from the community doesn't mean Node.js itself is bad.

</comment></comment></comment><comment><USER47> I remember having debates like this about the TRS-80 in middle school. These guys need to give it a rest, srsly.

</comment><comment><USER48> I decided to take it a step further and add fibonacci generation as an Express Middleware.

<https://github.com/nuckchorris/express-fibonacci>

</comment><comment><USER49> I'd like to point out that by the time this article was posted, and thanks to some constructive discussion about the approach, the node-fib "project" on github has been updated with a much faster recursive approach which doesn't use loads of memory and doesn't resort to memoisation, but still doesn't block the loop and serves almost as many requests/sec.

My point here, and in writing the lib in the first place was that naive implementations are naive in any language/vm. I lump splitting an algorithm across the loop into the same band as deciding this task should spawn a thread/worker. And using child processes as workers is still an option in node.

</comment><comment><USER50> I don't get why all these back and force rants get upvoted.

</comment><comment><USER51> Geez, so many generalizations and false arguments. Some of you could use a basic reasoning class (possibly Philosophy 201 or something of the sort).

</comment><comment><USER52> right tool for the right job. solving real problems is hard. unix, microsoft, beos python, java, brainfuck whatever. experts tend to be overspecialized and one dimensional. pundits have their own agenda. religion closes the mind's eye. forget about your preconceptions and embrace the world around you.

</comment><comment><USER53> Does the same criticism applies to code written with Greenlet/Gevent (see for example Brubeck web server)?

<comment><USER54> Yes, not yielding control from a function in any evented framework will block the main event loop.

In programming languages that support coroutines, yielding a sleep every few loops will release the event loop. In languages without coroutines like javascript you will need to write your algorithm in CPS to release the event loop.

</comment></comment><comment><USER55> Huh. Just write the algorithm in say c, and have node do a callback when the algorithm is complete.

</comment><comment><USER56> I don't see how discussions like this signify the decline of NodeJS. Quite the opposite. Lots of people are thinking about how to do this kind of computation the right way, within the context of NodeJS.

Honestly this discussion has kind of highlighted how bad almost all other platforms are and how much room for improvement there is.

<comment><USER57> Actually what I have found it has highlighted is just how many of the Node advocates completely and _utterly_ fail to understand their competition. I really, really wanted to think it was just a few isolated people, but the evidence suggests that the meme that Node is actually some sort of multiprocessing breakthrough has spread further in the last few months, rather than dying out.

So let me lay it out for you: Node's multithreading is _primitive_. There are in fact other languages that can simultaneously do long-running computations _and_ serve web pages at the same time, because they are _not_ single-threaded under the hood. That is a _Node_ limitation, not a fundamental computing limitation. Many of those other environments can also trivially use multiple cores within the same OS process.

We are discussing the limitations of Node with regard to long running precisely because it is a limitation that Node in particular has, and that there are other environments that do not have it. We are discussing this limitation precisely because the casual presumption you make in your last sentence that Node is the epitome of programming platform, and therefore if it has a problem then everything else must suck too, is false.

I am staggered at the degree of ignorance of other platforms being displayed by the Node partisans here, because it's not "well, OK, that's nice but in practice I don't care", which I would disagree with but would at least consider debatable (and I mean that quite honestly), but rather just a continuous talking past the Node partisans entirely, with little evidence that they even understand what is being said. I say this from experience over the past couple of days, where it's pretty clear the Node partisans seem fundamentally incapable of considering the concept of "environment that does not have the fundamental limitations of Node".

Several of you seem to be expressing confusion about why some of us aren't coming around to seeing the light. To you all, I'd recommend this essay: <http://www.paulgraham.com/avg.html> Hint: _Node is blub_.

Let me be clear about my motivation in writing this, and generally trying to tamp down on the Node hype. First, it's bad for Node. I've seen this cycle before, and as fun as the ride up is, when it is predicated on false claims it tends to explode at some point and the whole thing goes down in flames. (A process that may now be starting.) Second, those of you who only know Node and think it is the epitome need to have it explained to you that there are in fact other tools that are more useful in these cases, so if you ever encounter those problems you can use the right tool for the job. Otherwise, you'll blow untold manhours trying to force a old paradigm to do something you could have done in a more modern one much faster and more effectively. I don't hate Node; I hate the hype, and the damage it is doing to a large group of people by lying to them about what the competition does.

<comment><USER58> _how many of the Node advocates completely and utterly fail to understand their competition_

I agree, but as someone who is generally excited about Nodejs, I see it as necessary growing pains. These kinds of criticisms and back-and-forth and flamewars, if a language or platform is having them, it doesn't make it fade into obscurity, it forces it to mature, either technically or socially. It also has the benefit of bringing it's most ideological advocates down to earth. I feel as though I watched this whole process with Rails, which went from The Greatest Thing Ever(tm) to simply another framework with some big advantages to go with it's known disadvantages.

And now it's happening with Nodejs, and I think that's ultimately a good thing.

<comment><USER14> As somebody who got into Ruby shortly before Rails (because I'd heard it was a "modern Smalltalk") and was writing JavaScript back when DHTML was the new shiny thing, that's my perspective too. The evolution of Node.js reminds me a lot of Rails. It lent an air of legitimacy to a language that a lot of people used to look at sideways if at all, and it's rather overhyped by an influx of people who were plagued by the problems it solves, but it is fundamentally pretty good even when you drill past the hype.

</comment></comment></comment></comment><comment><USER59> Bulldonkey. Javascript on client side will continue for the foreseeable future which means those developers would want to use the same language to do server- side. Just because it hasn't taken hold, doesn't mean it won't.

</comment><comment><USER60> Another boring, silly "jumping the shark" post

</comment><comment><USER61> The man is butthurt about trolls trolling trolls trolling a man who's butthurt about bad software.

All I have to say: the cycle continues.

</comment><comment><USER62> I finally decided to do some research into what Node.js actually is and it turns out that it is just another web server. Seriously? That is what all the fuss is about? Its main feature seems to be that it has an event driven loop. Yay, an event driven loop, is not like they have not existed for a really long time. Whomever is marketing this thing must be a marketing genius.

On the other hand, the real appeal might be that it allows a lot of programmers that only know JavaScript or that feel most comfortable with JavaScript to do sever side programming with JavaScript. Something that as far as I know wasn't available before which is why this thing has become popular.</comment>


A taste of CoreData – A graph framework - <AUTHOR> https://yageek.github.io/blog/2018/02/19/a-taste-of-core-data-0-a-graph-framework/ <comment><USER2> Since about 20003, I have made a bit of a career of removing CoreData and its predecessor EOF from applications.

Every time it has been a huge success in terms of simplicity, performance and reliability.

Replacing EOF happened in a feed-processing application[1]. We just processed everything in memory and persisted the incoming feed, which we wanted to do anyway for auditing. In that instance it wasn't so much a planned removal, but rather that we never came around to implementing the DB component.

Next up was a desktop application, Livescribe Desktop. It was using an atomic store, so there wasn't really any point to CoreData. Chucking it meant removing a lot of code and crash-sites.

For Wunderlist 3, we rewrote the storage layer to simply use a bunch of JSON files (our CTO used to shock people at conferences with that little nugget), and the "In-Process REST" ideas from [1]. So our persistence solution was essential [NSJSONSerialization dataWith...]. The day after we launched, I was shocked at the number of crash reports, but my colleagues informed me that they had 10x the amount the last time. With millions of users, you get into a lot of edge cases. Oh, ours was also the fastest of the clients.

Oh, I also gave a talk at UIKonf '17 about making a public transport data (sample) application 1000x faster by moving from CoreData/sqlite to a custom data representation.[2]

[1] [https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_...](https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_11)

[2] [https://www.youtube.com/watch?v=kHG_zw75SjE&feature=youtu.be](https://www.youtube.com/watch?v=kHG_zw75SjE&feature=youtu.be)

<comment><AUTHOR> The purpose of the post is just to provide some general information about the different concepts provided by CoreData. The framework first lacks of a clear documentation I would say. Regarding reliability, if the rules are respected, I would consider CoreData as a reliable framework.

Regarding speed, I would say that CoreData is far lower than other low level approach. It is up to the developer to estimate the needs in term of speed/performance.

The biggest advantage of CoreData, according to me, would be the integration with the UI libraries, but this is only my opinion :)

I guess you gave the same talk at appbuilders last year right?

</comment></comment><comment><USER3> Kudos to OP for braving through CoreData. I've been using it on and off since it was released, and it's an awfully cumbersome and error-prone framework. And as Apple adds more complexity to iOS, CoreData gets exponentially worse. I'm 200% convinced today that it's far better to just store your users data in a more traditional cloud database instead. _Especially_ with syncing, which Apple made ridiculously, unnecessarily hard to get right.

<comment><USER4> >I'm 200% convinced today that it's far better to just store your users data in a more traditional cloud database instead

What would you recommend? Firebase, Realm or something else for small project that might or might not get off the ground?

Personally I've found the hardest thing tapping in iOS development there doesnt seem to be culture of writing out tutorials / problems people had and how they fixed them. Doing webdev you find countless similar issues people had and how they fixed them with simple google search. Lot of docs are in objective-c as well which kinda pushes you to study two languages instead of one.

I tried React Native for a while but it's ridicules how fast stuff get deprecated and the feel is far from 'Native'.

<comment><USER5> What specifically are you having trouble finding tutorials for? I've had little issue finding ios tutorials for most things.

This particular bit is far better than it used to be, back when Apple platform development meant Mac apps written in Obj-C and AppKit. Back then, your best hope were a handful of blog posts and mailing list threads. If your issue wasn't there, you had to figure it out on your own.

Today there are tutorials for Swift and UIKit springing up all over the place. It's quite a change.

</comment></comment></comment><comment><USER6> NSPredicate. Back in the day I fought through the CoreData only kinda SQL thing and eventually got a result but... These days I'd just shove it on SQLite and get 10x the performance for 10x less effort. God DAMN that was hard work.

[https://developer.apple.com/library/content/documentation/Co...](https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/Predicates/AdditionalChapters/Introduction.html#//apple_ref/doc/uid/TP40001789)

<comment><USER7> Well, that's a common misconception, but far from the truth. If you actually care about performance, you'll soon find out that performance wrt. database work is all about high-level optimizations: You want to reduce the times you hit the database (both reads and particularly writes).

And once you're getting into that busyness, Core Data will allow you to create way faster coder in less time. Core Data will get you 10x the performance for 10x less effort.

<comment><USER2> Hmm...parent is actually correct. What you write is true with very _slow_ databases, particularly when talking to enterprise databases over a network.

"Fortunately", CoreData is so slow that as long as you stay within that universe, your view will never be invalidated.

Outside, however, computers are blazingly fast in general and I/O throughput is also incredibly fast. My _laptop_ can read/write 2 GB/s. That's a lot. Moby Dick is around 1.25 MB. This means that you can write this whale of a book, in its entirety, 800 times per second. That's a lot. But I repeat myself...because it's worth repeating.

CoreData helps you optimize/minimize the size of transactions. Except for a very few cases, that's the wrong thing to optimize, as all our storage has amazing throughput and not-so good per-transaction and seek costs. Getting 1 byte from disk is almost as expensive as getting 1 megabyte, and having a bunch of smaller transactions is almost always a loss compared to one large transaction.

</comment></comment></comment><comment><USER8> I've been using CoreData in a big project but the multithreading has been crashing my app a lot. Can anyone recommend me some alternatives for a simple, lightweight, 100% local data storage for iOS?

<comment><USER9> I've always felt that mastering CoreData's multi-threaded APIs are a trial by fire. Tutorials and recommendations only got me so far and I had to stumble my way through to truly master it. At the end of it all, I got a bigger feeling of appreciation for the complexities involved in multi-threaded synching of data and its persistence.</comment></comment>


"Come back with an idea that you can do quickly and that you can take public or get acquired within 12 to 18 months." - <AUTHOR> http://www.fastcompany.com/magazine/32/builttoflip.html <comment><USER2> This is from 2000, Feb 2000 no less. I don't know of anyone saying this kind of thing today.

<comment><USER3> There are people that have this mindset, although I don't think it means that we are in a bubble. There are always people looking to get rich quick. The fact that it's so easy to start a Web Venture today means that there will be more of those kind of people in this space. <http://money.cnn.com/magazines/business2/business2_archive/2006/10/01/8387088/>

<comment><USER2> Investors are certainly looking for companies that can go public or get acquired. Arguably only those, in fact. What's changed is that no one now would expect that in 12-18 months. That was just Bubble craziness.

<comment><USER3> If that wasn't your goal, if you just wanted to start a business because you wanted to run your own business, should you look for other types of funding? Are you basically out of luck with most professional investors?

<comment><USER2> Yes, few professional investors would be interested. No matter what they claim about wanting to build long-lasting companies, the structure of VC funds requires them to have exits.

Interestingly, though, you'd also be out of luck with a lot of potential employees. The more ambitious ones want options that might make them rich. Without any prospect of an exit, you lose all the hotshots to competitors who offer such a prospect. That's why big, private tech companies are so rare.

</comment></comment></comment></comment></comment><comment><USER4> 'Build to flip' is a fine idea. Of course you still need to make a good product, but I don't think 'build to last' is right for every company or every idea. A world with 100 new HPs every year would be top-heavy.

The ecosystem needs a few big companies with billions of capital and global reach, but there's nothing wrong with building up a good small idea and selling it off after a year or two to be integrated into something larger.

<comment><USER3> I agree with that. There is nothing wrong with selling your company, but if you start your company hoping to sell it for millions in a year, it seems like you're just setting yourself up for trouble.

<comment><USER4> Well, yes, the 12-month selloff strategy is probably uncommon for good reason.

I suppose most ideas require more than a few months to create real value.

</comment></comment></comment><comment><USER5> It seems like if you are building to flip you might get lucky, and at certain times (like 7 years ago) that's easier than others. But "build to last"/"build to work" are on the same side of the coin as "make something people want": the odds of succeeding and making money are better if you are aiming to build something great that's actually worth acquiring.

</comment><comment><USER3> I read the first half of the article thinking that this was written today instead of 7 years ago, it sounds very familiar

</comment><comment><AUTHOR> The attitude to have a an exit strategy is pervasive here. It could be because it's been advocated in Paul's many essays. But ask yourselves, do you just want to start a web startup? Is it just about the web, or would you start any kind of startup/company (tech or not)?</comment>


Ask HN: What would you build on top of an "open" Google index? - <AUTHOR>

What if Google opened its index and created a search market place? Are there domain/location specific apps that can be built around/on top off those returned results? <comment><USER2> The cost would be a huge factor. If it's free, I wouldn't build anything, because that's a recipe for "Oops, Google deprecated our business model."

If it's not free, there's still a concern that Google could borrow your business model.

Basing your business model entirely on the content from a third party service has shown, in recent years, to be a nearly complete disaster.</comment>


Twitter Music App Goes Live Today - <AUTHOR> http://techcrunch.com/2013/04/18/twitter-music-app-goes-live/

<comment> k-mcgrady Playing with it now and it seems pretty good. The trending chart is obviously full of the usual suspects (Psy is #1 right now). The emerging chart is actually quite good. I haven't heard of anyone on it but already heard a few good songs. The suggested chart (based on artists on you follow which the app finds automatically when you link your Twitter account) is also quite good. It's finding me tracks by artists I know but haven't heard in a while and a few new ones too.

The play interface is a bit clunky. I've already accidentally switched to the next track and there doesn't seem to be a way to seek so when I went back I had to start the previous track from the beginning again.

The app makes sharing what you're listening to pretty easy and includes a link to the track on the music service you've linked your account with (Spotify or Rdio).

Search is a bit funny. It says 'search for artists' but really just returns a list of twitter users matching your search term. I could see twitter introducing some sort of artist account. It can't be that hard to verify an artists authenticity through checking if they have music on Rdio, Spotify, or iTunes.

It seems like it could be a good service and is soemthing that will be useful to me immediately but they do have a few things (mainly the playback interface and search) to work out.

Edit: The website is now live: <https://music.twitter.com>

<comment><USER2> Not sure about the app, but on the web interface you can seek inside a track by clicking around the disc image.

<comment> k-mcgrady Thanks for the tip, that works in the app too.

</comment></comment></comment><comment><USER3> Well that now makes the second Twitter product without an Android launch strategy. The first, Vine, looks like it'll flame out by the time they ever toss a half broken app across the corporate firewall. Are they running out of cash or something? Their competition doesn't seem to be having a problem with supporting more than one platform.

Edit: I'd also like the point out the irony of hitting "Play Full Tracks", picking Rdio, then immediately being presented with a Facebook logo and login option but no Twitter SSO. /facepalm

<comment> k-mcgrady >> "Well that now makes the second Twitter product without an Android launch strategy"

They do have the website which works fine on mobile.

<comment><USER3> That's a piss poor Android strategy.

And as a side note I'm still getting this on Android:

<http://i.imgur.com/Ox0BwML.png>

Hopefully it's just a cache issue.

<comment><USER4> I'm getting that on iPad as well. I guess the site is not ready.

</comment></comment></comment></comment><comment><USER5> ... in _some_ countries.

        Right now, the service is available in the US, Canada,
        the UK, Ireland, Australia and New Zealand. Over time, we
        will bring the service to Android as well as to more
        countries.

[http://blog.twitter.com/2013/04/now-playing-twitter- music.ht...](http://blog.twitter.com/2013/04/now-playing-twitter-music.html)

<comment><USER6> Woohoo! For once Australia and New Zealand aren't 3 years later. Well done Twitter (and We are Hunted).

<comment><USER7> I wonder if it is because Twitter Music is from buying We Are Hunted which, if I recall correctly, was an company from Australia.

</comment></comment></comment><comment><USER8> I'm disappointed by the description (but I never used wearehunted; if I had I probably wouldn't be surprised). I was really hoping for an easy way to _share_ individual songs over twitter (in a way that doesn't require me or the people that might listen to the songs to have external accounts). Right now I use embedded youtube videos which has gaps in coverage, quality, etc.... Twitter might have the resources and influence to pull something like that off.

The flip side being that if it's easy for people to share songs, and there's an easy way to play a stream of songs w/in twitter, then you get "discovery" from curated playlists.

<comment><USER9> I think <http://toma.hk/> is the closest to that right now. It would be great to link up with something like <http://musicbrainz.org/>

</comment></comment><comment><USER10> A lot more details on theverge.com: [http://www.theverge.com/2013/4/18/4238138/twitter-unveils- ne...](http://www.theverge.com/2013/4/18/4238138/twitter-unveils-new-music- service)

The service WILL launch today - iOS app and website. It will work with Spotify, Rdio and iTunes.

I hope at least one of two things happen - they somehow support Xbox Music (ZunePass), but I doubt that will happen since it isn't web based and probably has no interface...OR Rdio gets more music.

</comment><comment><USER11> Q: do most people really have the data plans on their mobile devices to be able to listen to music all day? I'm in Canada and we certainly do not.

<comment><USER8> Yes: I have wireless in my office and house (and no data plan for my iphone).

<comment><USER4> So what's the point in listening to music in your iPhone at home?

<comment><USER8> I plug it into my radio speaker through the aux in cable in my living room.

</comment></comment></comment></comment><comment><USER12> Bands now have a strong reason to get very spammy on twitter. Hope it doesn't go the way of MySpace, which ended up being LinkedIn for people who want to promote their band. (there was a lot of other things wrong with MySpace, but when it just became a bunch of bands spamming each other, anyone who wasn't a band had little reason to be there anymore)

</comment><comment><USER13> Can you play full songs from Spotify on the app with a standard Spotify account? Since the Spotify app only allows full catalog access on mobile devices with a premium subscription, it seems strange that they would allow the Twitter Music app to do this.

</comment><comment><USER14> Why all the hype about Twitter Music app? I just don't get it. Can someone please explain?

It seems to me like Google Drive all over again, nothing new to see but since its a big company launching something, hype!

<comment> k-mcgrady Have you played with it? Until today all we really new was 'Twitter is launching a music app/service'.

</comment></comment><comment> mkr-hn It won't let me connect my Spotify account. I'm going to assume it's from so many people trying to do the same thing. Looks interesting from what little I can do with it without the connection.

</comment><comment><USER15> still not exactly sure what it does. it pulls music from other services based on trending stuff on twitter? who would want that? so much hype for nothing...

</comment><comment><USER16> Not live. Techcruch did not get paid properly I guess

</comment><comment><USER17> Not live for me, what does everyone else find?

<comment><AUTHOR> Yeah I think Twitter originally announced only that it would be going live _today_ ([http://gma.yahoo.com/twitter-music-app-launches-for- iphone-a...](http://gma.yahoo.com/twitter-music-app-launches-for-iphone-and- web-listen-and-discover-trending-music--120539705.html)) and Techcrunch has paraphrased that poorly.

 _Edit: added 'Today' to title to clarify._

</comment></comment><comment><USER18> Crappiest launch ever?

Public facing landing page for about a week that asks you to sign in then just does nothing, not even an error?

Can't even be arsed looking at it now after that mess.

<comment> k-mcgrady From the blog post:

"You can download Twitter #music from the App Store today, or enjoy the web version, which will be rolling out over the next few hours: music.twitter.com."

So the web component will be rolling out later today. The app is available and working.

Edit: It's now working for me <https://music.twitter.com>

</comment></comment><comment><USER19> Amazing app....i am lovin it</comment>


ASK: Seriousness of Recent China's Internet Hijacking - <AUTHOR>

Yesterdays Newshour coverage on the 18 minutes mass diversion of internet traffic was a surprising information to me.
After the report I kept wondering how serious the problem really is or just another media panic hype.
Any thoughts?<p>http://www.pbs.org/newshour/rundown/2010/11/china-internet-hijack-experts-take-questions.html <comment><USER2> Seriousness? Well, I suppose that depends on the intent...

It's pretty well known that any BGP node can redirect blocks at will, if they're trusted by their neighbors (or enough of them, anyway).

If it was an intentional "proof of concept" attack, then I'd guess it worked pretty well. It's not too hard to invent what Bruce Schneier would call a "movie plot" scenario where the Chinese government redirects all the traffic that they want to themselves, with the average internet denizen completely unaware (because all of the major browsers trust the Chinese government's CA, which means that they can produce signed, trusted certs for any website that they want), basically committing an internet-sized man-in-the-middle attack.

Of course, there are some practical issues to get around, plus doing that would probably (hopefully?) be considered an act of war...and that's ignoring the ramifications to China's current economic model, which (while I'm not an econ guy) tells me that they don't want to screw up by enticing a global embargo of cheap plastic crap.

So basically, what's the intent? If it's malicious, it's serious. If it's not malicious, then it's really no different than any of the other few times this sort of thing has happened.</comment>


World Scientists' Warning to Humanity: A Second Notice - <AUTHOR> https://academic.oup.com/bioscience/article/doi/10.1093/biosci/bix125/4605229 <comment><USER2> "We must recognize, in our day-to-day lives and in our governing institutions, that Earth with all its life is our only home." It's definitely all to easy to fail to appreciate and comprehend this simple fact.

<comment><USER3> It depends on how thoroughly ensconced people are in the virtual worlds of business and work, and how denatured they have become by urban living. Out here in the bush, both our utter reliance on the living planet, and its precipitous decline, are starkly obvious.

</comment></comment><comment><USER3> RIP our dying planet.

I am assured by the business lobby that the 16,000 signatories are assuredly warmist alarmist leftists with little understanding of the serious work of men in suits. I am left oddly unmollified.</comment>


The NES turns 30: How it began, worked, and saved an industry (2013) - <AUTHOR> https://arstechnica.com/gaming/2013/07/time-to-feel-old-inside-the-nes-on-its-30th-birthday/ <comment><USER3> In the US it saved the industry. Outside of the US computer games and mini computers were selling fine, and gaming was going through its own golden age (especially in the UK). Hell, even Japan offered more competition for the Famicom than the US did for the NES.

America is not the only place in the world, and the video game crash was not a worldwide phenomena.

<comment><USER4> I've always felt like this as well. The "great video game crash of 1984" was very much an American phenomenon. It affected many of the consoles of the era _in America_ , which were getting long in the tooth and were quite underpowered, especially (but not only) the Atari 2600. I get rather fed up of hearing people refer to it as a universal, industry destroying event.

The crash occurred because the market was flooded with cheaply made, poor quality, simplistic games, which were about all many of these consoles were capable of running. People became bored of them.

There's basically no comparison between these consoles and the NES. The NES was vastly superior and hence allowed the creation of much more involving games.

By contrast the early to mid 80s in the UK and Europe looked quite different: here it was the 8-bit computers that ruled the roost. These had more memory, and often better graphics and sound capabilities. Again, this allowed for the creation of more involving games. As a result many of the machines - <USER2> perhaps the C64 the most - had great libraries of games. And of course they were programmable and affordable, which made them vastly more interesting to homebrew hackers on a budget. (Apple and IBM machines were considerably more expensive.)

<comment><USER5> I am curious if we are ever headed there again. Unity, Unreal, GameMaker and all the others are super amazing in that they let almost anyone make a game. Unfortunately they also allow cheap clones and shoveware to the point there are apparently 20000-40000 new games shipped per month, mostly on iOS and Android but even Steam is at or around 1000 a month.

Not that there is anything to be done about it it's just when the barrier was higher it forced at least a small increase in "average" quality

<comment><USER6> Every Unity game I've played seems to suffer performance problems of some description, or completely shits the bed when you try to add mods.

I've basically just learned to stay away from Unity games at this point.

<comment><USER7> It's not Unity, it's the developers. Unity can perform very well if enough care and effort is taken to understand it. The problem is a lot of Unity developers don't take the time to learn it's mechanics or just don't understand programming all that well. If you were to attach Unity's profiler to a majority of the Unity games out there, which I'm sure with some you could because they're probably built with the autoconnect profiler set to true, you'd probably see a monstrous amount of garbage collecting occurring. Not understanding update cycles or the performance implications of newing each update is what I've seen be the true source of performance loss in Unity, in general. Unity also has a GetComponent<T> because they need to access a class attached to a Unity GameObject, but instead of caching that reference to the gameObject they just do the GetComponent each frame or each method call, which has a performance impact because Unity needs to filter through all the active GameObjects to find either the first one or all of the ones that have said component. Stuff like that is why Unity games run so poorly, the engine is almost to accessible.

</comment></comment></comment></comment></comment><comment><USER8> I find notions of 'saving' things, particularly industries, to be disingenuous. If the NES flopped, or never existed, it's not like the console gaming industry would not exist. There is clearly a market for it and so we would simply have different names to recall as the 'saviors' of the industry. This is also why companies failing is not a bad thing, nor something that should aim to be avoided.

For instance with our massive automotive bailout. If these companies went out of business it might have been a rocky few years, but clearly there is a demand for vehicles and this would have created a vacuum enabling new companies, perhaps with more innovative ideas, to take their place. Instead we propped up a failing industry for no apparent gain. It could have even been detrimental in the longrun. Not all automobile companies were failing -- Hyundai-Kia were booming for instance. And had we let the dinosaurs go extinct it's entirely possible that today most cars being sold would have been much more fuel efficient. Instead, as soon as gas prices dropped we ran right back to giant gas guzzlers. Ford, for instance, even recently announced they've decided to stop making all passenger cars... except the Mustang. So what happens the next time gas prices spike? Deciding to save the company has predictably incentivized myopic behavior.

<comment><USER9> Ford was the only US automaker that didn't need to be bailed out.

Besides, people who buy Mustangs aren't that sensitive to gas prices.

<comment><USER8> No, they didn't receive the TARP funds. Instead they received a $5.9 billion dollar loan from the taxpayer for the stated purpose of developing more fuel efficient vehicles - and, without which, they likely would have gone bankrupt. It was granted with a subinflation 0.25% interest rate and has still not been paid back.

</comment></comment></comment><comment><USER10> NES was mostly an US phenomenon I guess.

In Europe we were focused on ZX Spectrum and Commodore 64, depending on the country, and then moved into a mix of PC, Atari and Amiga.

In Portugal the only games console that some kinds cared about were the Sega one's.

<comment><USER11> The Master System only really caught on in Europe and Latin America; in the US and Japan the NES was far more successful. They also had Japanese PC games, but they were on different, Japan-only machines that were capable of displaying Japanese characters and had a much larger portion of indie games and pornographic games.

<comment><USER12> In Mexico I never heard of Master System, my first console was a NES and it was not until the SEGA Dreamcast and PlayStation came out that I knew of other consoles. Nintendo had a monopoly over here.

<comment><USER11> It may just be Brazil.

</comment></comment></comment></comment><comment><USER13> The NES is very significant.

But without it the Amiga kept gaming going happily. It was a great system. I remember the first time I saw an NES and the comparison to the Amiga wasn't great.

The Amiga had a lot of great games in the 1980s too. Kick Off, Speedball, Xenon, Marble Madness, Bubble Bobble, Populous, F18, F16 Falcon, the Lucasarts Adventure games.

<comment><USER14> The Amiga CD32 was going to dominate the industry but had an IP suit against it.

When the Amiga 500 dropped below $300 in the USA it entered video console territory.

<comment><USER15> That's not at all how I remember it - the CD32 was a last ditch effort, and one which whilst trying to maintain some sense of heritage (mainly in the awful styling - even at the time I wondered what they were doing) entirely misplaced the value of the Amiga in teenagers minds: creativity and piracy, neither of which were to be found.

For me the CD32 was a final confirmation that the haydays of my beloved Amiga were past.

At that point, I'd already seen Comanche running on a lowly office PC and knew that things were fast changing.

</comment></comment></comment><comment><USER16> Atari basically created, and then almost single-handedly destroyed the entire American console industry.

Despite their early success it was so poorly ran. Management was horrible. They were releasing piles of shit as games, like Pacman and ET. Programmers left the company in droves because of poor pay and treatment. Atari poorly handled the third party developer situation.

Their hardware was terrible. The 5200 and 7800 were flops. They couldn't get any traction in the home computer business.

<comment><USER17> Bugs aside, ET actually isn't a bad 2600 game at all. A lot of the crap it gets is purely meme driven.

<comment><USER18> And the bugs have been fixed:

[http://www.neocomputer.org/projects/et/](http://www.neocomputer.org/projects/et/)

</comment></comment></comment><comment><USER19> It would be great if we could stop glorifying Nintendo as if they were the only valid actor from some kind of dark ages of video games. It was just so NOT the case, having lived thru that time.

<comment><USER20> I feel like in the US it was. I still remember the first time I saw Super Mario Bros. at my friend's house. It's hard to overstate how mind blowing that game was to me as a kid after being exposed to mostly single-screen arcade and console games prior to that.

<comment><USER21> Same clear memory for me too. We had a BBC Micro and some great games but Mario still stood out.

</comment></comment></comment><comment><USER22> Interesting.

I distinctly remember a BIG gap in home video game systems between the death of Atari 2600 in the early 80'a and market acceptance of the NES in the mid- late 80's.

Ice hockey was a game we played religiously.

<comment><USER23> > Ice hockey was a game we played religiously.

Reminds me I have / had a small graveyard of Ice Hockey cartridges. I got my start programming in the mid 00's doing homebrew NES dev, and Ice Hockey was a readily available, cheap cartridge with the NROM PCB layout

I still feel a little guilt for taking all those poor cartridges out of the world, and keep an old Ice Hockey PCB sans CHR and PRG ROMs on my desk as a totem / reminder.

</comment></comment><comment><USER24> For those interested in the cultural and technical history of bringing the Famicom to the West, I can highly recommend "I am Error" by Nathan Altice. [https://mitpress.mit.edu/books/i-am- error](https://mitpress.mit.edu/books/i-am-error)

</comment><comment><USER25> This discussion about how dominant the NES was in which countries reminds me of a question I've had for a while. Is there hard data on the popularity of each game platform (computer or console, home or handheld, etc.), globally or for each country?

I think the best way to measure it is by software sales. You could also include hardware and accessories, but that would inflate the share of some platforms because of uses beside gaming (productivity and the Internet on computers, or Blu-ray playing on the PlayStation 3).

</comment><comment><USER26> Does anybody have recommendations for books or documentaries that evoke the general vibe of this era?

<comment><USER27> The Ultimate History of Video Games (2001) is amazing, if that's the angle you are looking for. Over 600 pages of great stories and information about the industry. I've read it twice and still think there sre things in there I haven't fully digested. I have a few other video game books pushed in the early to mid 2000s, but this is the only one I'd actually recommend. There are a lot of newer books, but they seem to approach video games from a more sensationalized space. One exception I would make are the works of Brian Bagnall, who writes about Commodore/Amiga. I haven't read his books but I hear they are amazing.

For documentaries, not exactly the same, but I enjoy the Bedrooms to Billions series (feature films, 2 are out) and to a slightly lesser extant Viva Amiga (2017) and the 8-Bit Generation series (feature films, 2 are out). These can be a bit more computer-focused though. I do not recommend Video Games: The Movie (2014), it feels like a VH1 special with little actual information.

<comment><USER28> I agree with you that Video Games: The Movie was trash.

</comment></comment></comment><comment><USER29> Wow that thing looks an aweful lot like an MSX. Both the console, the cartridge and the joystick</comment>


Looking out for number one - <AUTHOR> http://plus.maths.org/issue9/features/benford/ <comment><USER2> Interesting article, and a phenomenon I hadn't thought about before. One thing the article didn't really focus on that struck me as a more intuitive way of understanding the phenomenon is that 1 is the first digit hit when the order of magnitude is increased (and 2 the next). So assuming for example a particular sample rarely goes above a given number, say 250 for argument sake, that means a large sample of the results are likely to be between 100 and 199, majorly skewing the results. Even if x was 700 a first digit of 1 would be far more common than 8 or 9. At the next order of magnitude the same logic would apply.

<comment><USER3> Benford's Law applies to distributions which vary over orders of magnitude, and locally flatly in the log-space. It obviously doesn't apply to adult male heights, which follow a (69, 3) normal distribution, thus 6's and 7's dominate. In the log space, this distribution is not "flat" over an order of magnitude; it's a steep "bump". However, incomes, urban populations, file sizes, and natural disasters (measured in dollar-cost or fatalities) do follow such distributions, and hence we observe Benford's Law.

To a person with some statistical background, I usually explain Benford's Law in the context of town and city populations. Obviously, there's great variation in the populations of chartered cities, from as low as 10 to over 10 million. I note there is nothing "natural" about normal distributions other than the fact that they emerge from the addition of a large number of (finite variance) variables, a process that approximately describes the determination of adult height from genes. Then consider the variables that determine a city's population. Being near water might increase the population by 50%. A strong economy over a decade might lead to 40% growth. Oppressive taxes might decrease the population by 20%. It doesn't matter what these numbers actually are; the point is that the population is the _product_ rather than _sum_ of such variables, so we get an approximately normal distribution _in the log space_. Variation in log-population goes from as low as 1.0 to over 7.0, which means we can expect approximate flatness over [4.0, 5.0). Then, approximately 30% of cities between 10,000 and 100,000 people will be between 10,000 and 20,000, which is [4.0, 4.3) in the log space.

I like the fixed-point/scale invariance explanation of Benford's Law better though, because it's more intuitive than the one I use. Still, it's not completely satisfying. It doesn't explain why Benford's Law applies to _all_ of the distributions to which it applies, such as file sizes, urban populations (inches and dollars are purely arbitrary units, while numbers of people or bits are not) and fatality figures in natural disasters.

<comment><USER4> To be clear: are you saying denglish's rationale is incorrect? (I ask because it _feels_ legit, but, alas, that doesn't mean it is.)

<comment><USER3> His rationale is not incorrect but incomplete.

Essentially, he's arguing that since the Benford distribution of leading digits is the sole fixed point under the scaling operation, it's the most natural distribution to expect in large collection of measurements. Since units of measurement (e.g. dollars, meters, miles) represent arbitrary quantities, and the data set could be examined using literally any unit of measure (a unit of measure being a scaling operation, e.g. meters -> feet multiplies each datum by 3.26), a sufficiently large set of measured data (e.g. an almanac) can be expected to obey Benford's distribution.

Benford's Law is also not true of specific distributions that are very tight. Consider IQ. That the mean is 100 is completely arbitrary, but the standard deviation of ~15% is not. Observed ratio IQs in healthy children are log- normal with a multiplicative standard deviation of 1.15-1.16; in other-words, the 85th-percentile 6-year-old will have the cognitive maturity of an average 7-year-old, a fact that is independent of the unit of measure. (Adult "deviation IQs" are a different matter entirely, as they are "forced" to conform to a normal distribution, e.g. a person who scores in the 99.0th percentile will be "assigned" a z-score of 2.33, corresponding to an IQ of 135.) Obviously, with 50% of IQs having a leading digit of 1 and almost none having a leading digit of 2 or 3, this is not a Benford distribution. You could use a different arbitrary scaling factor, setting the median to 50 instead of 100, but then leading digits of 5 and 6 would be overrepresented, with virtually no 1s or 2s. The issue, of course, is that normal IQs are very tightly distributed in the log-space and don't span nearly an order of magnitude, so we will never get a Benford distribution no matter what scaling factor we choose.

The other problem with the OP's argument is that it doesn't apply to figures like fatality figures in natural disasters, or sizes of cities, neither of which involves an arbitrary unit, but both of which exhibit Benford-esque distributions, due to the _multiplicative_ rather than _additive_ compilation of the variables involved. An additive compilation (e.g. sum) of a large number of variables (e.g. height from genes) exhibits a normal distribution, for which Benford's Law does not apply. However, a multiplicative compilation (e.g. product) of a large number of random variables will have a log-normal distribution, and if the variation of X is over many orders of magnitude, its distribution will be locally flat enough (in the log-space) that Y - floor(Y), where Y = log X, will be approximately a uniform choice out of [0, 1), leading to the Benford distribution.

</comment></comment></comment></comment><comment><USER5> Maybe I just don't understand why this is a big mystery. Suppose you have a range of numbers from 1 to some value between 1 and 100. If that value is picked randomly, you have 8/10 chance of including the teens, 7/10 chance of including the twenties, etc. until you have a 1/10 chance of including the eighties, and an increasingly low chance of including the nineties. Then you choose a number from that range - what are the chances it begins with 1? Far greater than if it began with 9, since numbers that begin with 1 are included 8/10 of the time.

Does this make any sense? Is there something I've missed?

<comment><USER6> That doesn't have much to do with the age of the captain...

</comment></comment><comment><USER7> This is the kind of stuff that makes maths and science fascinating. This is why I want to go back to school to study maths and/or life sciences. But, I have a lot of catching up to do since that last science and math class I took in high school...

What particularly struck me about the article is that I want to apply Benford's law to pi, see if it works, and if it does not, determine if there is variance at different lengths. Then try it on pi*r^2 ...

<comment><USER3> The digits of pi are conjectured to be "random" in the sense of being both uniformly distributed over {0, ..., 9} and possessing no n-ary serial correlations for any n, but as far as I know, this has not been proven.

Benford's Law only applies to leading digits, and only for numbers following a certain class of distributions.

It's important to note that the "Law" is not an innate mathematical property of _anything_ , but an observed phenomenon with mathematical underpinnings. It doesn't apply exactly to _any_ well-defined, real-world distribution ("physical constants" is not a well-defined distribution) but it applies _approximately_ to a good number of them.

Benford's Law is exactly true on 10^X, where X is a random variable, chosen with uniform probability, from [0, 1). It's also true with X chosen from [0, n) for any integer n, because the leading digit of 10^X relies only on the non-integral part of X. When X is chosen from some other distribution that spans many orders of magnitude (say, N(4, 1)) the distribution of the fractional part (X - floor(X)) is _approximately_ a uniform random variable from [0, 1), so Benford's Law is approximately true.

<comment><USER7> "The digits of pi are conjectured to be "random" in the sense of being both uniformly distributed over {0, ..., 9} and possessing no n-ary serial correlations for any n, but as far as I know, this has not been proven."

This is why I find the concept interesting. I want to see the conjectures and theories /in person./ I love mathematical theory, in general, but my knowledge is very shallow. I more-or-less understand the properties of pi that you described, but I want to test them. I also want to test the properties of Benford's law to see how they work and how they can or can't be applied. This looks like the perfect opportunity to do exactly that.</comment></comment></comment>


Ask HN: Where should I submit a press release? - <AUTHOR>

I wrote a press release for my startup. What do I do with it? <comment><USER2> In my opinion: throw it away.

More constructively, what are you trying to accomplish? There are few goals that a press release will help you with. It may help with some vanity links in Google News if you search for your name, but that's about it. If you want press coverage or user attention, a press release is almost certainly not going to help.

<comment><USER3> Ditto this. It's likely not to get you any press of value. Write some personalized, targeted emails (or get intros) to press instead. Tell a compelling story (tie into an existing narrative if you can) and keep it short and to the point.

</comment></comment><comment><USER4> The most clever press-releases I've seen in recent-months have taken the form of guest-articles / guest-posts on places like TechCrunch. Of course it can't be a hard sell (no overt plugs). But they _can_ be an opportunity to demonstrate your knowledge of [insert-your-vertical] and come off as an expert in that field. Somewhere in the post the magazine will reference who you are and where you work, and that alone might do more benefit than any traditional PR syndication service would.

More info:

[http://venturebeat.com/guest-posts/](http://venturebeat.com/guest-posts/)

[http://techcrunch.com/2012/09/27/guest-column- column/](http://techcrunch.com/2012/09/27/guest-column-column/)

</comment><comment><USER5> Agreed with everyone else here: don't submit that press release anywhere!

Short emails, 2-4 sentences, to the right journalists will be much more effective.

Check out our primer on how to write emails to journalists: [http://muckrack.com/daily/2013/11/21/how-to-write-email- subj...](http://muckrack.com/daily/2013/11/21/how-to-write-email-subjects- lines-journalists-will-actually-open/)

And if you still don't believe us on press releases, read the article I wrote for the PRSA that questions the press release's value, and debunks that it will help with SEO or social: [http://comprehension.prsa.org/?p=6202](http://comprehension.prsa.org/?p=6202)

</comment><comment><USER6> Ex-journalist here...

The question you want to be asking is "Who should I submit this to?", not 'Where?'. Which writers, bloggers, journalists etc have shown relevant interest to your startup's sector or pain point in the past? Write to these people individually, thanking them for having shown such an interest (link to a great article they've written, especially if you read and enjoyed it at the time) and introducing yourself, your startup, and the newsworthy angle you have decided for in your release.

Keep the email punchy. And if you do get any kind of response, even if it's to decline to write you up, be ever so grateful and make it clear that you would be happy to provide expert opinion on this topic if they ever sought it in the future.

</comment><comment><USER7> I was just wondering the same thing about my startup (www.nucleusintercom.com), and came across this great primer: [http://www.publicize.co/beginners-guide-to- pr/chapter-4-pres...](http://www.publicize.co/beginners-guide-to- pr/chapter-4-press-release-submission-websites/)

<comment><AUTHOR> Thanks for the link!

It lists both free and paid submission services. Are paid services worth it?

<comment><USER8> I don't think either will be a catalyst for anything significant - there's just craploads released every day and it's unlikely anyone will notice yours unless you, your startup, or your investors are notable enough that journalists are specifically watching for them. It definitely won't be worth paying for.

</comment></comment></comment><comment><USER9> Sadly the only thing submitting a press releases did for me is to ensure that I get weekly spam from press release companies, and individuals willing to fix my SEO and boost my sales.

</comment><comment><USER10> What was the goal of the press release?

It can have some good uses if you can get them wanting to ask more which would hopefully lead to a story.</comment>


Show HN: cdgo – Quickly cd into dir nested in $GOPATH or ~/workspace/ - <AUTHOR> https://github.com/EngineerBetter/cdgo-cli <comment><AUTHOR> It's a tiny little utility, but handy for when you're switching between Go projects in your $GOPATH and other projects in ~/workspace, or for when you can't remember who made a Go project or what website they hosted it on. It's mostly written in Go, so is quicker than just a Bash function alone.

<comment><USER2> Curious how often the speed of Bash has been a problem in this sort of application.

</comment></comment><comment><USER3> zsh plugin for doing exactly the same, but not bound to GOPATH only:

[https://github.com/seletskiy/zsh-favorite- directories](https://github.com/seletskiy/zsh-favorite-directories)</comment>


June Jordan and Buckminster Fuller Tried to Redesign Harlem - <AUTHOR> https://www.newyorker.com/culture/culture-desk/when-june-jordan-and-buckminster-fuller-tried-to-redesign-harlem <comment><USER2> It's interesting how one generation's vision of utopia often becomes the dystopia of the following generation. In his time, Le Corbusier was heralded as the genius of modern architecture. Today, his buildings seem vaguely dystopian (to me, at least) and remind me of the recent 2012 Dredd movie.

[https://duckduckgo.com/?q=dredd+movie+building&t=osx&iar=ima...](https://duckduckgo.com/?q=dredd+movie+building&t=osx&iar=images&iax=images&ia=images)

Fuller probably envisioned the shape of his buildings as futuristic and naturalistic, but to me, they look like nuclear power plants. Icons (as in a simplified, recognizable image) end up playing an unexpected role.

From the countries I've visited, I'd say Berlin (especially Prenzlauerberg) and Tokyo had the most pleasant version of urban design. With Berlin, most apartments have balconies, streets are wide enough to let shops expand onto the sidewalks, and public transit works extremely well. Tokyo mixes commerce with residential in a way that American cities get completely wrong.

There is also a city in Poland, Łódź, which also has a geometrically appealing layout: it's essentially a single long street with two concentrations at either end. The city itself is still recovering from the 90s and is fairly run-down outside of the center, but the conceptual simplicity has an appeal that's hard to describe.

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

<comment><USER3> > It's interesting how one generation's vision of utopia often becomes the > dystopia of the following generation. In his time, Le Corbusier was heralded > as the genius of modern architecture. Today, his buildings seem vaguely > dystopian (to me, at least) and remind me of the recent 2012 Dredd movie.

That structure in Dredd reminded me of Corbs Ville Contemporaine (aka 'A City of Three Million Inhabitants') design. Interestingly, the objective was to bring back a green landscape without sacrificing urban density. Almost everywhere there isn't a structure there would have been park. Manufacturing, Business, Recreation, and Habitation each occupied it's own zone. One of Corbusier's plans could fit 800-1200 residents/hectare.

It's an interesting observation on our vision of a utopia; Paul Rudolph enjoyed a meteoric rise in popularity in the 60's & 70's, now many of his structures (in the U.S.) have been dismantled. Luckily some past endeavors age well, e.g. Neave Brown was awarded the Gold Medal by RIBA for Robin Hood Gardens several years ago, Trellick Tower is still standing, etc.

<comment><USER4> > Interestingly, the objective was to bring back a green landscape without > sacrificing urban density.

Yeah, it was one way to do that, for sure. But there are other ways that many people would think are far better. Here's a typical street in a neighborhood that is presently at about 30,000 people/mile^2 (11,000 people/km^2):

[https://firstname.lastname@example.com,-87.6643239,3a,75y,2...](https://email@example.com,-87.6643239,3a,75y,238.24h,90t/data=!3m7!1e1!3m5!1sGHmLhAxFppoH4m9vIirLbA!2e0!6s%2F%2Fgeo0.ggpht.com%2Fcbk%3Fpanoid%3DGHmLhAxFppoH4m9vIirLbA%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D230.20157%26pitch%3D0%26thumbfov%3D100!7i16384!8i8192)

</comment></comment></comment><comment><USER5> Here's an alternate source that's much better and has better (but not enough) images: [https://ny.curbed.com/2018/1/10/16868494/harlem-history- buck...](https://ny.curbed.com/2018/1/10/16868494/harlem-history-buckminster- fuller-development-rezoning)

I don't really understand why this is the case, but a large percentage of stories about architecture, urban design, urban planning, development, etc. are written with thousands of words and no maps, diagrams, or pictures. The fuzzy black and white scribble on this one doesn't count.

Why do writers bother penning these? Architecture and it's assorted offshoots are visual media, and spending a bunch of words to describe it is about as useful as writing an essay to say what the Mona Lisa looks like.

<comment><USER6> You can write an article about something from afar, but can't photograph it. Leaves you trying to find Creative Commons images or licensing something. Writer isn't paid enough to do that, I'm guessing.

</comment></comment><comment><USER7> Corbu got a few things right but he was off the mark when he said a house was a machine for living. A house cannot provides all the necessities for living, it must be integrated into a community. Monolithic buildings like this are an extension of his incorrect idea, they are the monoculture of urban design much like the suburb. We should take the good idea of simple and easy to manufacture buildings and use them to create human scale spaces that fulfill our needs as a community.

</comment><comment><USER8> If you look at page 341 these would be solarpunk if drawn today.

They are thin and constructed over existing buildings. But with ramps so you can drive a car up.

[https://s3.amazonaws.com/arena- attachments/2397578/dc67d37c8...](https://s3.amazonaws.com/arena- attachments/2397578/dc67d37c83d910d2f027d855f42805a8.pdf?1530916557)

</comment><comment><USER9> That was a terrible idea. Apartment buildings with 45,000 people each? Most with no exterior windows?

<comment><USER10> Someone went to Kowloon walled city and said "Cool".

<comment><USER9> There are parts of Shenzhen that look like that.[1] But with better structural soundness. Here's a ground level view.[2] (That's a full sphere video; you can change the view direction, including looking straight up.)

This meets most of the criteria you see the "strong towns" people plugging for. Walkable streets. Convenient retail. Few cars. Very low speeds. Excellent land utilization. No space wasted on parking. Affordable.

Of course, the people who write those articles wouldn't live in a place like that themselves.

[1] [https://firstname.lastname@example.com,114.0656082...](https://email@example.com,114.06560828,20.66510478a,1105.83450886d,35y,75.7406347h,0t,0r)

[2] [https://youtu.be/e-2n_HksLh0?t=220](https://youtu.be/e-2n_HksLh0?t=220)

<comment><USER11> > This meets most of the criteria you see the "strong towns" people plugging > for. Walkable streets. Convenient retail. Few cars. Very low speeds. > Excellent land utilization. No space wasted on parking. Affordable.

> Of course, the people who write those articles wouldn't live in a place like > that themselves.

This is like suggesting that people who value having their own backyard are being inconsistent by not moving into the remote countryside. There's nothing inconsistent in promoting a certain set of values within desiring those values taken to the _extreme_.</comment></comment></comment></comment>