A Technology Freelancer's Guide to Starting a Worker Cooperative [pdf] - <AUTHOR> https://techworker.coop/sites/default/files/TechCoopHOWTO.pdf <comment><USER2> I think that there is real value in thinking more broadly about the cooperative model when building any new business! As a way to align incentives it makes a lot of sense.

I am part of a growing tech worker cooperative called Tribe Works ([https://www.tribeworks.io](https://www.tribeworks.io)). We are a platform cooperative that helps tech workers connect with businesses looking for contractors or direct hires. We were set up as an alternative to "gig platforms" (upwork, etc) and staffing firms, and quickly realized that the real value in our model was in longer engagements. We usually target roles that last at least 3 months so that our members can access healthcare through the cooperative if they are working full time and allow workers to buy in. The platform ties together the functionality of an applicant tracking software (ie jobvite.com) and professional employer organization (ie justwork.com) and we add recruitment process outsourcing as a service on top. We have only just launched our beta platform right now but hoping to fully launch when we reach 301 members (we are about 1/4 of the way there). We have community calls every other week as well for people interested in learning about the co-op.

We are also part of a larger cooperative called the Staffing Cooperative ([https://www.staffing.coop](https://www.staffing.coop)) which is a holding company owned by every worker. Here is a webinar we were recently on describing the holding company structure: ([http://transformfinance.org/investor- resources](http://transformfinance.org/investor-resources))

<comment><USER3> We are an crowdsourced transcription service and are seriously exploring converting into a worker coop. I have been researching worker coops for a month now. How do we get started?

<comment><USER4> Happy to hook you up with someone to advise, but as people are saying would be good to know your location first.

<comment><USER3> SF. We are a fully remote company though.

<comment><USER4> Cool. Found your email, will drop you a line.

<comment><USER3> Hey, do you have any connects to Loconomics?

</comment></comment></comment></comment></comment></comment><comment><USER5> There is another relatively recent tech movement -- Platform Cooperatives. In the worker cooperative case, employees are the members of the cooperative. For platform cooperatives, it's the users that are the members. Examples of platform cooperatives include [https://www.stocksy.com/](https://www.stocksy.com/), [https://www.savvy.coop/](https://www.savvy.coop/), among others. For more details about Platform Cooperatives, see [https://platform.coop/](https://platform.coop/), [https://ioo.coop/](https://ioo.coop/) and [https://start.coop/](https://start.coop/)

<comment><USER6> One of the most potent kinds of coop that I've ever encountered is exemplified by DATEV. It is a cooperative founded by the tax advisory profession in Germany in 1966 to create accounting software which is, to this day, the market leader in Germany for all accounting not having to do with corporations that are big enough for SAP.

In 1966, the potential for computers to be used in accounting had just become apparent, and by thinking about companies and markets the way we now do, you would have thought that the situation should have been a slam dunk for IBM. That's not how it played out in Germany. Instead of individual tax advisors entering into individual deals with IBM, the tax advisory profession set up a coop to buy and operate central mainframe infrastructure (don't know if it was IBM or not), to be used by all the coop's members and, while they were at it, instead of buying software from anywhere (like from IBM), they hired some engineers to write their own software. Personally, I find this an absolutely baffling turn of events. The profession realized what a giant disruption the introduction of computers would be. They realized the strategic importance of maintaining control over software and computer operations. They realized that, by sticking together and acting in a coordinated fashion, they had the power take on a corporate behemoth like IBM at their own game and tell them to go stick it. Absolutely inspiring, if you ask me.

<comment><USER7> The software is horrible though, probably because of that monopoly position.

<comment><USER6> I agree the software is horrible. Somebody should get a new coop going there ;-)

</comment></comment></comment></comment><comment><USER8> Hey. I haven't been able to read past the headline yet (very busy day today) but I just wanted to say I work for tech workers co-op in the UK. We focus on Open Data work.

Happy to chat later (will read later to), but I would also point people towards [https://www.coops.tech/](https://www.coops.tech/) which lists many such co-ops. You can find their chat board at [https://community.coops.tech/](https://community.coops.tech/) Also, in the U.K. [https://www.uk.coop/](https://www.uk.coop/) is a great resource.

Can I suggest anyone asking legal questions states where they are? While the principals are the same, legal options will differ massively between countries.

<comment><USER9> Would be interested in hearing more - I think IR35 changes in April are going to make co ops an interesting option.

<comment><USER10> Ir35?

<comment><USER9> IR35 is a Inland Revenue Rule 35 (1999) ([https://en.m.wikipedia.org/wiki/IR35](https://en.m.wikipedia.org/wiki/IR35)).

It basically prevents one person "contractor" companies from acting like employees but getting paid like a business and so somehow avoiding tax. If the HMRC thinks your contract with BigCo means you are a "disguised employee" then they will ask you for your missed back taxes.

But on April 2020 they will stop asking me for my back taxes and will instead ask the client for whom I work (ie BigCo). As such BigCos across the UK are unwilling to face years of potential back taxes and will from April 2020 do some combination of

\- state every freelancer / contractor working for them is really a disguised employee so that the employee's company must pay the equivalent income tax / NI

\- let go of their contractors en mass

\- push their contractors to major suppliers like Accenture

\- move their UK based work off shore to NYC / Paris / Mumbai

Basically combined with Brexit, UK tech jobs are going to disappear / take a 25% haircut or go abroad.

It's not looking good.

</comment></comment></comment></comment><comment><USER6> I think the upside is mostly to do with doing projects for clients who aren't themselves in the tech industry and who don't really care how their projects are implemented and who implements them.

When doing tech work for tech businesses you will often find that they already operate their own network of tech contractors and membership in such a network basically implies being a lone-wolf freelancer character for a number of reasons (a) They work with people not headcounts. They will do extensive individual vetting to decide who they work with, and after deciding they want to work with you won't allow you to switch yourself out for another personnel resource. (b) They will want to keep each individual contractor's bargaining power in check, so even when they need more than one headcount, they might think twice about picking up a headcount greater than one from something that's already self-organizing as a business entity of some kind.

Also, I feel quite strongly that if, in practice, there is a client relationship that you have 100% ownership of, then you want to make sure that this is also the case on paper, rather than having an indirection where you are 1% of some coop and 1% of that coop's revenue happens to be your client. -- And much of the upside described here can also be realized through a consortium of sole traderships (or otherwise 1-person businesses), rather than through a coop.

<comment><USER11> Yeah, I would think the biggest benefit here would be insurance/benefits (and possibly taxation) related, which doesn't seem to be mentioned at all.

<comment><USER6> If you want to be taxed and treated for insurance purposes like an employee, you can always incorporate as a sole-person Inc or Ltd or GmbH and hire yourself as the sole employee. Granted: There are some overheads having to do with annual accounts etc where it would be beneficial if those overheads could be distributed over more than one employee, but the more you earn the less that will matter in proportion to your earnings.

But, on the whole, you will have more opportunities at saving on taxes as a business than as an employee and more opportunities to "slip through the cracks" of the system when your business is so small that the tax authorities can't be bothered paying as close attention to it as they otherwise would.

<comment><USER12> There's definitely some overhead but it's not terrible. I actually have a startup called Hyke setup and manage mine for a decent monthly fee. My company is a single member LLC which employs me for a "reasonable" salary and then I take the extra profit as a distribution. One huge benefit is the distribution is only taxed at the employee side of FICA taxes (whereas I pay my half and my company pays the same on salary, same as a freelancer normally pays both sides) saving me a decently large amount of money. It more than covers what I pay Hyke and extra fees, even without getting into healthcare or anything.

</comment></comment></comment></comment><comment><USER13> What if we replaced reliance on giant corporations with an actually efficient free market in software, content and services?

GitHub/npm (centralized) has been the closest so far for software, and the Web (decentralized) has been the closest for content. But what if we could go further and implement XANADU 2020?

We would at minimum need a globally distributed utility token to allow value transfers without needing to mess around with merchant accounts and international payments.

Here is a progressively more detailed architecture of what something like that would look on a large scale:

[https://qbix.com/whitepaper/whitepaper.html](https://qbix.com/whitepaper/whitepaper.html)

If you read it, please share your thoughts and feedback - whether you like some things or would want improvements in other things. Especially interested in whether there is something we missed and the system absolutely won't work (eg why would companies pay for open source software if they can just clone it and even distribute their fork and have their fork compete with it.)

I am a big fan of putting my money where my mouth is, so we are actually building this ecosystem.

</comment><comment><USER14> To anyone who has been part of a worker cooperative:

Does the amount of money different people make in your cooperative seem fair? How do you handle situations where one person seems to contribute a lot more to the cooperative than others (say they bring in bigger clients, or they're more skilled)?

<comment><USER15> I'm part of a four-person consultancy and we have a transparent deal on profit sharing for projects, depending on who does what part. We adjust the deal every few years when the nature of work changes, so it's an ever evolving thing, but my feeling is that as long as everything is transparent, and can be changed if someone feels it's getting unfair, people will be happy.

</comment></comment><comment><USER16> I think cooperatives are very important. Open source development is a kind of cooperative effort ... without the formality.

Having said that, human organization issues are often the downfall of cooperatives for highly compensated and highly skilled labor.

One of the reasons programmer cooperatives don't last more than 2-4 years is because the best ones bring in the best clients, and the other programmers start to free ride. Apart from this, the best programmers also often get poached by other organizations ... either through employment or through direct contracts.

In practice, I think the biggest value cooperatives bring in a country like the US is that they can provide healthcare and retirement plans through scale, which would not be available to an independent freelancer.

The explosion of online communities and meetups in the last decade has made the other benefits of cooperatives (like camaraderie, reputation management, client sourcing, and knowledge sharing) less valuable.

</comment><comment><USER17> Holy shit this is awesome, thanks so much. I'm starting a creator collective/technology studio and this is a great resource.

</comment><comment><USER18> I didn't find anything about health insurance in this doc - is it possible to get a group plan for such a cooperative? Individual insurance plans are usually 20-30% more expensive...

<comment><USER19> This is precisely why universal health care is such an exciting proposition! I think if we get it there will be a massive influx of alternatives to traditional job complexes/remuneration models.

</comment></comment><comment><USER20> The document is 10 years old. Many things have changed. I'm not a US citizen (apparently the target group), but somehow I doubt that such an old text would adequately reflect this.

<comment><AUTHOR> I would love to know more, anything specific that has changed which you think will render some of this old text obsolete?

<comment><USER20> Commissioning and procurement have changed a lot here in Germany, accompanied by stricter and even nonsense regulations regarding for example disguised employment (Scheinselbstaendigkeit), a problem even in other jurisdictions (IR35 in GB for example).

As I wrote, I don't know the current situation in the US well enough to deduce more than guesswork from it. Here, at least, it has a great impact on someone's choice of the right organizational form. Cooperatives are not out of the question, but you have to consider some newer factors to do it right.

</comment></comment></comment><comment><USER21> If anybody has already done the ground work and is looking for people to join an existing worker cooperative, please post here as well!

Or if you know of any resources that help you find others with whom you might start a co-op, that would be great. (If that doesn't exist, I might be able to help. It shouldn't be too difficult to spin up an interest form that might help people connect.)

<comment><USER2> I am part of a cooperative called Tribe Works ([https://tribeworks.io](https://tribeworks.io)). We are currently in beta but definitely looking for new members!

</comment></comment><comment><USER22> I was involved, briefly, in the worker cooperative scene in the late 90s in the UK. One was an ISP but the rest I interacted with were non-tech.

I loved the idea but the practice always seemed so far from the ideal. What I saw were one or two people in a cooperative make things happen (whether through initial founding, finding business, doing the boring stuff that make a business actually happen, or simply doing customer work) and then others would put in a similar amount of effort to a normal job but get an equal share in the rewards as the one or two people driving the whole thing.

I'm not saying that typical businesses today are ideal or fare. However, worker cooperatives seemed no less fair than other forms of business; it's just that they were unfair in different ways.

I'm still a fan of the co-op model but it brings with it its own set of challenges.

</comment><comment><USER23> Great to see this posted here! I read this and several books about cooperatives last year with the intention of growing my small software consulting business into a cooperative. If anyone is interested in this topic and wants further reading, let me know!

</comment><comment><USER24> What is the long term growth strategy for worker cooperatives? How do you scale them?

<comment><USER25> A lot of people are saying that you don't have to grow workers coops and they can (with the implication that they should) remain small. A counter example is the Mondragon Corporation, which is a worker coop/federation of worker coops which employs 75,000 people.

<comment><USER26> Also here in Argentina we have Banco Credicoop, which is a credit union with more than 670,000 members.

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

</comment></comment></comment><comment><USER27> Excellent. I've been longing to start a small/lean cooperative for years. Looks like a solid resource. Now if I could just find some partners...

</comment><comment><USER28> cooperatives seem great.

relatedly:

not sure why we don't create 'partner firms' a-la attorneys - the model seems a good fit.

</comment><comment><USER13> Finally, there is talk of economic models in software development!

Valve software is an example of a software developer's "cooperative" though you'd probably call it anarcho-syndicalist, instead of socialist. They wrote a great blog about it:

[http://blogs.valvesoftware.com/economics/why-valve-or- what-d...](http://blogs.valvesoftware.com/economics/why-valve-or-what-do-we- need-corporations-for-and-how-does-valves-management-structure-fit-into- todays-corporate-world/)

The Internet has disrupted many economic models and affected society and even democracy (journalism, social networks). Automation reduces the demand for human labor. We have to have conversations about better solutions.

At my own startup, we constantly explore the intersection of technology, sociology and economics. Years ago, we explored proper compensation models using the socialist (not communist) principle "from each according to their ability, to each according to their _contribution_ "

[https://qbix.com/blog/2016/11/17/properly-valuing- contributi...](https://qbix.com/blog/2016/11/17/properly-valuing- contributions/)

And now, we are working on a utility token to power a decentralized "free market" of web software that emphasizes collaboration and re-use over competition and duplication. Would be happy to get feedback on the actual implementation and economics, as we will be going live with it soon. Here is the link:

[https://qbix.com/whitepaper/whitepaper.html](https://qbix.com/whitepaper/whitepaper.html)

 _PS: to the downvoters: The above is open to feedback and revision. Instead of simply downvoting, why not click the link and read it, and offer a scathing critique? Again, we are trying to make sure this leads to an efficient and fair market in software development, and if we missed something, we would appreciate any feedback that involves words :)_

<comment><USER29> Part of the downvotes might be related to the fact that there's been a lot of skepticism/cynicism/backlash around Valve's allegedly flat management structure. Multiple ex-employees have said that while there are no formal "boss" roles, the company has evolved a _de facto_ manager class with whom one must ingratiate themselves to even have a semblance of job security, let alone materially affect the direction of the company.

[https://www.pcgamer.com/ex-valve-employee-describes- ruthless...](https://www.pcgamer.com/ex-valve-employee-describes-ruthless- industry-politics/)

[https://www.wired.com/2013/07/wireduk-valve-jeri- ellsworth/](https://www.wired.com/2013/07/wireduk-valve-jeri-ellsworth/)

[https://news.ycombinator.com/item?id=20099167](https://news.ycombinator.com/item?id=20099167)

<comment><USER13> OK, I had mostly mentioned valve first out of humility, but I think _our company_ Qbix is trailblazing much more interesting economic models. Please take a look at the whitepaper, and would like some feedback.

</comment></comment></comment><comment><USER30> Important things that are actually accomplishable.

</comment><comment><USER31> This is an interesting idea. I wonder how this will coexist with UBI. Someone tweet this to Andrew Yang!

</comment><comment><USER32> Sounds like a recipe for disaster.

<comment><USER33> " _Please don 't post shallow dismissals, especially of other people's work. A good critical comment teaches us something._"

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)</comment></comment>


How I want to write Node: Stream all the things - <AUTHOR> http://caolanmcmahon.com/posts/how_i_want_to_write_node_stream_all_the_things_new/ <comment><USER2> Forgive me for being "That Guy" but I really think Javascript is ill-suited for this paradigm!

Streams, honestly, are hard to keep straight when the program gets big without a stronger type system. IMHO.

Some really sharp people have been working on stream computing software in Haskell for a while - Gabriel's Pipes package is a good example of generalized stream computing with _strong_ equational reasoning as its foundation.

Maybe if you _really_ want to try and do this in Node you can gain some inspiration from his journey: [http://hackage.haskell.org/package/pipes](http://hackage.haskell.org/package/pipes)

<comment><USER3> Here's the main enlightenment of becoming a node.js guy:

Node follows the unix way. Everything is a stream. It's just Buffers and JS objects flying around. It's really stupid, and sometimes it's nasty. This isn't helped by Javascript's warts.

But there's an enormous upside to this: following the stupid Unix way means that no matter what you need to do with your data, there's an npm module for it. Just .pipe() your stream in and your code is done. This is amazing. And it's possible only because of how bare-bones and loose the Buffer stream API is.

Strong typing has its place, but it would ruin node's biggest selling point. It's hard to realize this without trying it.

<comment><USER4> Yes, and "the unix way" isn't just "everything's a stream", but rather "everything's a _text_ stream." In that regard, node's version of "everything's a stream" is actually a half-step up in abstraction.

<comment><USER2> Isn't it more accurately a _byte_ stream (I don't know, which is why I'm asking)?

<comment><USER5> The default build-in streams found in the stdlib are byte streams (byte chunk streams, to be more exact). But user-level there are object streams as well, those are also mentioned in the docs: [http://nodejs.org/api/stream.html#stream_object_mode](http://nodejs.org/api/stream.html#stream_object_mode) \- so they are kind-of official.

</comment></comment></comment></comment></comment><comment><USER6> If you're doing Node.js, Caolan's async library is pretty much part of the standard toolkit.

I know Caolan's been thinking about this and reworking it for a while, so I'll be interested to see whether it manages to see significant takeup.

<comment><USER7> From Great British Node Conf, maybe two months ago: a speaker talking about promises asked what people use for flow control:

\- promises: about 20% of the room.

\- async: about 80% of the room

For me async.waterfall([list of functions]) is little nicer than 10 chained .thens().

And people advocating promises _still_ keep saying it keeps things flat. No it doesn't, we're already flat because we're all using async. Stop pretending async doesn't exist and isn't massively popular.

And way, way better documented. Q.spawn what? And this is the _best_ promises library?

Stack Overflow question: Simplest fs.readFile example with generators and Q?

Current only answer:

      Q.spawn(function* () {
          …
          var data = yield Q.ninvoke(fs, "readFile", somefile);
          …
      });

Answer from Highland docs:

        var data = _.wrapCallback(fs.readFile)('myfile');

\- What's Q (yes it's a module, but what does it mean? Is it supposed to a misspelt queue or something else?

\- What does 'ninvoking' something do?

\- Shouldn't I just be able to to put the variable declaration outside of the scope?

\- Why do competing Open Source implementations of the same standard exist? Can't there just one reference implementation?

That's not the future.

I might be really ignorant here. I probably am - I could read a shit tonne of docs to work out what this strange beast does and technically someone can probably do a better job answering that Stack Overflow question. But nobody has, because very few people know how to operate the current state of the art generators/promises setup.

From the Q docs: "If you have a number of promise-producing functions that need to be run sequentially"

No, I don't have a number of promise producing functions. Nobody in nodeland has that. I __just have functions __. I could read about turning them into promise producing functions, and calculate whether this abstraction layer is adding value, but then again, I could do productive work with async.

And from the looks of it, Highland too.

<comment><USER8> I have a question about the async library: what does it do if an asynchronous function or a callback raises an exception? The word "catch" doesn't appear in [https://github.com/caolan/async/blob/master/lib/async.js](https://github.com/caolan/async/blob/master/lib/async.js).

I ask because I wrote some Lisp macros (I work in a Lisp that compiles to JS) to implement a few async patterns I need, and making sure that exceptions are trapped and threaded into the callback chain correctly was the most complicated part.

<comment><USER9> It doesn't do anything about thrown exceptions. The correct way to deal with an error in asynchronous code is to pass an object describing the error as the first argument to the callback. Any code that takes a callback is expected to know this and not throw exceptions.

From a practical perspective, it doesn't make sense to try to catch exceptions in asynchronous code, anyway. Once you do something asynchronous, you lose the stack and thus the try block. The way to catch thrown exceptions in asynchronous code is with domains, which something as low level as async would not be expected to handle.

<comment><USER8> _The correct way to deal with an error in asynchronous code is to pass an object describing the error as the first argument to the callback._

Sure, but what if the error is thrown at you as an exception in the first place—which happens a fair amount, because that's how the JS runtime tells you when something is wrong? How do you get from there to the callback way?

What the Lisp macro I mentioned does is generate a separate try-catch around each block of code that runs at a different time and thus might throw an exception that would not otherwise get caught. In that way it catches every exception that's thrown, converts it to an error object, and passes the error back through the callback chain. The async library could do the same, albeit with a lot more code. I'm curious why it doesn't.

 _From a practical perspective, it doesn 't make sense to try to catch exceptions in asynchronous code, anyway._

I don't think that's right. Asynchronous code is just synchronous code that runs at different times. Each block of synchronous code can generate exceptions. I agree that if you don't catch them then, they become useless; but you _can_ catch them then. The reason this is not a "practical perspective" in JS is not that it doesn't make sense, it's that the language doesn't support it. Even the minimum code necessary to catch every exception involves so many try-catch blocks as to obscure the rest of the program. So no one writes such code by hand in JS.

Yet it is, I think, code that one wants, because without it you don't have a consistent error model. You end up having one model for first-class errors—the ones you detect and pass to callbacks before an exception has a chance to arise—and a second one for the dregs—the ones that come from any code that didn't know about or follow the callback convention (which, critically, includes the language runtime). The latter kind of error either crashes the server or gets caught by a top-level handler so it "only" crashes the request it was processing. That's a half-baked system.

<comment><USER9> > Sure, but what if the error is thrown at you as an exception in the first > place—which happens a fair amount, because that's how the JS runtime tells > you when something is wrong? How do you get from there to the callback way?

Its on you to catch that, not your libraries. This shouldn't be terribly common, though. The only thing I can remember having to wrap in a try/catch in the codebase I work on is JSON.parse.

> The async library could do the same, albeit with a lot more code. I'm > curious why it doesn't.

It couldn't, without domains. try-catch wouldn't do it. Domains are something that is not very well understood, in my experience, and expected to happen at a higher level than libraries like async.

<comment><USER8> I don't understand most of this. For example, I don't know why you say that the async library couldn't try-catch every place that an exception might occur (mostly its calls to the functions that get passed in to it). It would be interesting if it couldn't, since then we'd have an example of something macros can do that functions cannot. But it seems obvious to me that it could; you'd just need a lot of try-catches. What am I missing?

As for domains, I don't know what you mean by them, but if they're catching errors at a higher level than the async library, my guess is that they must be some more sophisticated sort of top-level handler; perhaps something that keeps track of which async calls are in progress and attempts to bind exceptions back to their context? Whatever it is, it sounds complicated.

But what I understand least of all is how you guys all seem to write Javascript code that generates almost no exceptions. To me that sounds almost like bug-free code. No null references, for example? I get stuff like that all the time.

<comment><USER9> > No null references, for example?

We write in CoffeeScript, where a null reference check is so astonishingly easy to write that you use them everywhere you might get a null. I'm not sure what other exceptions you're seeing. We do basically no math, so /0 errors aren't a problem.

> For example, I don't know why you say that the async library couldn't try- > catch every place that an exception might occur

Let's build a typical function you might pass to async:

function(next) { request.get(url, function(err, data) { JSON.parse(data); } }

Let's assume the server doesn't serve JSON like we expect - so JSON.parse throws an exception. The only thing async could have wrapped in a try/catch is the main function, but we've fired off a request and then the call stack wrapped up, including the try/catch. Next, an event occurs that calls our callbacks, not going through async at all. That's where the exception occurs. The stack trace generated by that exception doesn't contain any code in the async lib, so it can't possibly have a try/catch active.

Domains are a way of fixing this. You create a Domain and bind callbacks to it - if that callback throws an exception, the Domain instead emits an error event.

<comment><USER8> Ok, thanks, I get it now. In my case a macro transforms the body of each callback to catch exceptions and pass them back as error args through the callback chain. So in your example, there would be a generated try-catch around the JSON.parse(data). I forgot this detail (sign of a successful abstraction?) and it does seem an example of something macros can do that functions cannot.

Re null reference checks, to get behavior analogous to a null exception you have not only to check for null, but also pass back an explicit error if you find it. That's a lot more work than adding in an extra question mark. Null checks that do nothing but not crash are a mixed blessing; 90+% of the time they do what you want, but when they don't, you get a silent failure and a debugging goose chase. I'd be surprised if you told me that that never happens.

I took a look at Node.js domains and they do seem really complicated. If I were working in Javascript instead of having control over the language, I doubt I would use them; I would probably just crash-and-restart as one of the other commenters described. That's not a good solution, but probably the best tradeoff given the alternatives.

<comment><USER9> Our use-case for domains is to allow the process to finish serving its other in-progress reqs before crashing. When an error occurs, we stop accepting new connections in that process, give them 10-15 seconds to complete, and then do the crash-and-restart cycle.

That said, we get very thorough testing from our large user base, and we quickly fix crashers. Our server proc crash rate is almost 0, brought up by occasional spikes on releases.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Really can't wait for "all the things" to stop being used as an acceptable replacement for "everything."

<comment><USER11> +1

</comment></comment><comment><USER12> Most of the things he describes can be done with Dart's async and collections libraries. Compiles to js, works on server side, used in production. Even if someone wants to reinvent the wheel, they should take a look at those libraries and see how it is done there.

</comment><comment><USER13> I use async.map when I need to do a bunch of file operations or something asynchronously and wait for them to finish. I have largely avoided using stream specific syntax because the event model was more familiar to me. I have used ToffeeScript instead of async.waterfall or async. series because ToffeeScript is cleaner.

With these improvements to streams in Highland making things more convenient and broadly applicable I expect to be using Highland streams for certain things.

</comment><comment><USER11> I get that arrays are meant to stand in for more asynchronous sources of data but those things seem so different to me that I don't understand why you'd want a library that treats them the same. If you need to map an array that's taken care of. I know I'm being dense, I just don't get it.

</comment><comment><USER14> I'm curious which features highland provides which RxJS doesn't. From what I understand, composable streams from any data source with backpressure support is pretty much the definition of Rx.

Sometimes simplicity is a feature, too, though.

<comment><USER15> Rx doesn't handle back-pressure or laziness, so it's for only really for handling events.

<comment><USER15> RxJS advocates are unhappy with this comment so I'm going to qualify it a little. Apologies for any misunderstanding...

Rx doesn't handle _automatic_ back-pressure (like Node Streams) but does have mechanisms to avoid overwhelming slow consumers. Rx also has delayed subscription which you can call lazy, but not by turning the stream into a pull-stream (allowing you to sequence actions in the way Highland does).

If any of the above needs further qualification or comment please weigh in on the issue by commenting here... but for now I'll leave it at that. I actually list RxJS in the blogpost because it's a _good_ example!

<comment><USER16> Coming in 2.3, we will have full capabilities for backpressure. We already have window/buffer/throttle, etc. But, I think it's naive to have only one style of backpressure because many are valid. Just an example of RxJS, and what can be done, which includes a style in which you can do several forms of backpressure, and yes, push to pull based models: [https://gist.github.com/mattpodwysocki/9010149](https://gist.github.com/mattpodwysocki/9010149)

Still fleshing it out, but pretty close to calling it complete: [https://github.com/Reactive- Extensions/RxJS/tree/master/src/...](https://github.com/Reactive- Extensions/RxJS/tree/master/src/core/backpressure)

We're more than open to pull requests though if anyone thinks we're missing something here.

</comment></comment></comment></comment><comment><USER7> @caolanmcmahon: consider using methods?

\- We have object.defineProperty() in ES5 to avoid enumeration.

\- You can use user-specified prefixing to avoid future conflicts.

Eg:

        {foo: 1, bar: 2}.hlPairs();

rather than:

        _.pairs({foo: 1, bar: 2});

</comment><comment><USER4> This is highly intriguing, but I must ask why the JS community has this fascination with obscure identifiers like "_". It decreases readability when what should be a logically-chosen descriptive identifier for your class is replaced with a single character that visually recedes into the language syntax. Edit: I've grudgingly given jquery a pass on this because of its ubiquity, but come on, a stream library? Not to mention the fact that a reasonably popular lib already seems to have squatted on underscore.

<comment><USER17> I agree; what I personally wonder is why Underscore and similar libraries don't make use of Javascript's prototype business and add methods to the array and object prototypes? Probably things I'm overlooking here, but, [1, 2, 3].map(stuff) is much nicer than _.map([1, 2, 3], stuff) and the like.

<comment><USER18> Ha ha.

You're describing the state of affairs before Underscore existed, back when functional-ish programming in JavaScript was ruled by Prototype.js:

[http://prototypejs.org/](http://prototypejs.org/)

... which added a lot of useful methods to native prototypes.

While handy in controlled and limited environments, mucking about with native prototypes quickly becomes extremely dangerous and difficult — once you have two third-party modules on the page that expect different versions of your patched prototype method ... once you have a new version of a browser that implements one of your previously-extended functions, but does it differently — you're pretty well screwed. Both of those things tended to happen in large sites.

<comment><USER4> Whereas with _.map, you always know exactly which implementation you're getting, right? :)

<comment><USER18> Actually, you do. You've loaded it, and you can lock it down privately to your library or app with _.noConflict().

You can have ten different versions of Underscore loaded on the page, living in peace and harmony, in ten different third-party modules. Not that you should. But that you could.

<comment><USER4> Well then I guess this _ has a bug because it doesn't have a 'noConflict' method. :)

But to be perfectly fair, you are 100% correct: this is not a technical complaint and perhaps this entire sub-thread is, as has been claimed, "bike- shedding." Since this lib is designed to be loaded via an AMD-style mechanism, users can call it whatever they want, so _ is just as valid an identifier as any other. Except the obvious issue that readers of the code, examples, and any code that follows suit, will end up with this completely pointless ambiguity because _ is ultimately a meaningless name if it evolves to mean simply "some library I loaded." You may as well write sample code like:

var $ = require('http'); $.createServer(...);

I would think people would call that out as ridiculous and confusing.

</comment></comment></comment></comment></comment></comment><comment><USER19> This sounds intriguing. I wish there were some more complex examples. Part of the greatness of Promises is taking a big chunk of pyramid code and turning it into a set of simple steps... I'd like to see how this would handle that.

<comment><USER15> Good idea, I'll definitely post a follow-up with some real code done using async/callbacks and highland/streams. The comparisons usually start to look _more favourable_ with longer examples, due to the Highland API being so composable.

<comment><USER20> Nice. I need to compare code written with highland to code with async.series/.each etc. (but not waterfall, I don't like that dude ;)).

</comment></comment></comment><comment><USER21> I really like Node, but I want a language with sane semantics. What's the best option apart from JS and CoffeScript. TypeScript is awesome, but I'm afraid that there will no good community, because of MS stigma.

<comment><USER22> You can use Haskell for the same semantics if I understand you correctly. Actually coming from Node, Go might be a better fit.

<comment><USER21> In other words I would like to use language that runs on Node, but it's not JS or CS

</comment></comment></comment><comment><USER23> Along these lines, John Resig recently created [http://nodestreams.com/](http://nodestreams.com/) as a way of composing and conceptualizing stream processing. Pretty nifty.

</comment><comment><USER24> This is amazing! And it's something that I wanted for some time.

LazyJS just received stream support, but I'm pretty much sold on to highlandjs.

</comment><comment><USER25> It looks like this whole notion of 'stream' is just a syntactic sugar for javascript guys who lost themselves in a bunch of nested stupid callbacks, which is worse than lisp parens. Instead of nesting whole callbacks, create a stream in the middle; execute first half of callback chain and dump the result into the stream so that next half of callback chain can be executed later.

Why is this so an enlightenment for node guys? UNIX does it right since epoch - simple programs perform simple tasks and connected via pipes. Python has gevent, so you don't even need 'a stream' or other bullshit, you just write the code as-is and greenlets provide the concurrency needed.

The real enlightenment comes from 'programming properly'; you start with C and torture your brain with function pointers and realize why it is a good idea to treat functions as a first-class objects. then you learn some 'proper' functional programming languages like lisp or something to learn how to think in functional way. which is the only guaranteed and proven path to prevent yourself from shooting your own foot by writing 20+ nested callbacks. If you start with binding an anonymous function to a <button>'s click event and think you can do this to do real programming, you'll never get it right.

<comment><USER26> Wise words of wisdom from kimjotki2, the only real programmer on the internet. Bow down, bitches.

<comment><USER27> This is not reddit.</comment></comment></comment>


Ancient Britons 'Replaced' by Newcomers - <AUTHOR> http://www.bbc.com/news/science-environment-43115485 <comment><USER2> > "[The Beaker people] are not prepared to collaborate on enormous labour- > mobilising projects; their society is more de-centralised," said Prof Parker > Pearson. "We don't have a good expression for it, but the Americans do, and > that is: nobody is willing to work for 'The Man'."

No Stonehenge in the new Beaker society. Sad.

</comment><comment><USER3> Acording to the professor the beaker people brought Britain out of the stone- age Brexit it had languished in for a millenium. Way to go professor</comment>


Why Is Gopher Still Relevant? - <AUTHOR> http://gopher.floodgap.com/overbite/relevance.html <comment><AUTHOR> The web is like an operating system that you are locked into using. This prevents alternative operating systems such as Plan 9 from ever becoming useful, because building a web browser is such a monumental effort. Even if a decent web browser were built for Plan 9 it would defeat the purpose of using such an alternative OS because the web binds software to content.

The web has effectively killed innovation in operating systems. A clean and consistent system will be out of reach as long as this web app nonsense continues.

<comment><USER2> I disagree, while writing a web browser would be significant work, it would likely be on the same order as writing an operating functional enough for people to actually want to use it. Porting a browser would likely take less work even (while still being a significant amount of work).

This page talks about what it takes to port webkit to another platform: [http://blog.cranksoftware.com/webkit-porting-tips-the- good-t...](http://blog.cranksoftware.com/webkit-porting-tips-the-good-the-bad- and-the-ugly/)

<comment><USER3> Forgive me, but you should more specifically define the terms you use. As it stands, it looks like by "functional enough for people to actually want to use it" you seem to introduce a circular dependency -- as though an OS is useless unless it's easy to port a browser to it.

The GP post mentiones Plan 9, which is a great example here. There are real people who use Plan 9 every day (I have met some of them!) but Webkit will never be portable to that OS because there is no C++ compiler. This doesn't make the OS non-functional, but it does mean step one to porting a modern browser is "port GCC or LLVM," which is a massive task by itself.

Both Firefox and Chrome source code repositories are in the hundreds of megabytes, even without the required host OS dependencies vendored in. The document you linked to recommends leveraging freetype, cairo, and all kinds of other things that would require serious graphics infrastructure of a sort that's just not feasible.

Modern web browsers are keystones that cap off arches built of hundreds of pieces of very specific software. As time goes by, they require _more_ infrastructure, not less -- c.f. Firefox, where to build the latest version you must also have a Rust compiler that targets your operating system. As the checklist of requirements grows ever longer, the candidate operating systems capable of meeting those requirements grows ever shorter.

Five years from now, I predict the only three operating systems capable of interacting with the web in any meaningful sense will be linux, macos, and windows; bsd and haiku et al will have been left by the wayside.

Ten years from now I predict there will be four operating systems, and one of them will be Fuchsia, because only a megacorp like Google has the resources to accomplish that.

<comment><USER4> > Five years from now, I predict the only three operating systems capable of > interacting with the web in any meaningful sense will be linux, macos, and > windows; bsd and haiku et al will have been left by the wayside.

That is an interesting prediction. What do you think will cause the BSDs to be left by the wayside in such a short timeframe, when they are more than capable of running the latest browsers right now?

Is the browser becoming a systemd module?

I am a little concerned about the trend to push "hardware acceleration" into everything. Graphics cards and their drivers are the biggest source of grief in PCs for me.

</comment></comment></comment></comment><comment><USER5> Gopher might not be popular, and apparently it's relevancy is disputed. But it is still an interesting bit of internet-history. It still has an active community, and a whole lot of information.

There's also a slow movement to add gopherholes to the tor network. A list of the current known ones can be found here; [http://gopher.floodgap.com/gopher/gw?gopher://bitreich.org:7...](http://gopher.floodgap.com/gopher/gw?gopher://bitreich.org:70/1/lawn/onion)

</comment><comment><USER6> I don't get this. It seems to me Gopher basically supports a subset of what is available on the web. All the benefits of Gopher (low bandwidth requirements, no flashy design or interactivity, strict hierarchical navigation etc.) can also be achieved with stripped-down web pages. I see no benefit at all to having a separate protocol.

Gopher is cool as a slice of history though.

<comment><USER7> You can't be confident of getting a stripped-down web page before you click the link. Trivial example: I can click a gopher link and be confident whatever's on the other end is not going to make a noise.

Human vigilance is fallible. Protocol-level enforcement is necessary.

<comment><USER6> Are you suggesting there are some people who _only_ browse Gopher?

<comment><USER7> There are people who prefer Gopher and/or particular known sites. If you can see from the URL that a site will be non-horribly designed then that's fine, and if the only option is HTTP then you put up with it.

</comment></comment></comment></comment><comment><USER8> Gopher comes without the multimedia annoyances of the over-engineered Web and it "lacks" people whose business model is to be on it. I like to browse Gopher every now and then. Several people I know even export read-only versions of their blog to Gopher.

I planned to write a new Gopher app for Android a while ago but I haven't finished it yet. This article reminds me to try again. Thanks.

<comment><USER9> I "ported" my blog to gopher as well (gopher://gopher.conman.org/) but it's not a clean port. The gopher client I use (an extension to Firefox) is not UTF-8 aware and thus there are character set issues. Also, there's some loss from the conversion of HTML to plain text (compare gopher://gopher.conman.org/0Phlog:2017/02/27.1 with [http://boston.conman.org/2017/02/27.1](http://boston.conman.org/2017/02/27.1)).

But it wasn't that difficult to do. And yes, I do see a few people hitting the gopher site.

<comment><USER10> I just tested your blog with OverbiteFF (I guess that's the client you're using), and I had to manually switch the encoding to Unicode (View->Text Encoding.) I see there's an "item type" field in the protocol, it's set to 0 (ie "plain text file") for your blog entries. The protocol doesn't seem to offer anything to specify the encoding to the client, so overbite must default to something like plain ascii.

</comment></comment></comment><comment><USER11> Oh wow, that's a blast to the path. The author also wrote the bucktooth gopher server, and I implemented a new (semi-OO Perl) version of it that supported Gopher+.

There was always something very satisfying about Gopher, how it made explicit the structure and categories of the data, leaving the front-end to present it how it pleased.

<comment><USER12> I would also note that others may find the name Cameron Kaiser familiar because he's the maintainer of the TenFourFox (Firefox for PPC OSX [1] ) and Classilla (Mozilla for OS9 [2]) projects.

[1]: [http://www.floodgap.com/software/tenfourfox/](http://www.floodgap.com/software/tenfourfox/) [2]: [http://www.floodgap.com/software/classilla/](http://www.floodgap.com/software/classilla/)

</comment></comment><comment><USER13> I had no idea what Gopher was and looked it up to understand; this article was helpful: [https://arstechnica.com/tech-policy/2009/11/the-web-may- have...](https://arstechnica.com/tech-policy/2009/11/the-web-may-have-won-but- gopher-tunnels-on/)

</comment><comment><USER14> Gopher is way more friendly for the visually impaired than the modern web.

<comment><USER15> If by friendly you mean 'irrelevant'. There's plenty of easy things that developers can do to their sites to make them more accessible that don't require rewriting them as a gopher site.

<comment><USER14> Yes. There are things that developers could do to make most web sites better for the visually impaired. But that doesn't mean that most web developers use, or even recognize, these best practices.

Gopher, on the other hand, simply only supports textual navigation that is easy to feed to a text-to-speech engine. The developer doesn't need to even think about these issues.

<comment><USER15> Right, but text-to-speech is only half of the problem. Gopher by default just uses plain text with no semantics. Without marking up those documents there's no way to let users jump around within them. Do you honestly expect a visually impaired user to sit and wait while each document they go to is read out to them in its entirety with no heading structure or ability to navigate within the content?

<comment><USER14> I think that argument worked well for the original web. But the HTML spec has accumulated a lot of things to make design easier, but they also make it easier to represent a page without useful semantic structure.

You mentioned tables, but there were many years where people were using tables in HTML for formatting instead of just expressing tabular data. So div tags were added. Now people sometimes use divs to represent tabular data.

Search is a pretty good way to navigate content, and is simple for raw text. An index is an even better way, and is supported quite well by gopher.

<comment><USER15> _people were using tables in HTML for formatting instead of just expressing tabular data_

Yep, and there are algorithms that try to distinguish between 'data' tables versus 'layout' tables for precisely that reason[1][2]. It's unfortunate that they have to exist, but the web has routed around past mistakes.

 _Now people sometimes use divs to represent tabular data._

Yes, and that's wrong and a simple fix. But regardless of whether some ill- informed people do that it's still no worse than Gopher, and when they get it right it's a lot better.

Regarding search, that's great if you have exact keywords for what you're looking for. Less good if you just want e.g. a list of headers on the page so that you can narrow in on the part that interests you.

[1] [https://dxr.mozilla.org/mozilla- central/source/accessible/ht...](https://dxr.mozilla.org/mozilla- central/source/accessible/html/HTMLTableAccessible.cpp#920)

[2] [https://cs.chromium.org/chromium/src/third_party/WebKit/Sour...](https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/accessibility/AXTable.cpp?sq=package:chromium&dr=CSs&q=axtable&l=94)

</comment></comment></comment></comment></comment></comment><comment><USER16> At the time of Facebook, the question should be: _Is the web still relevant?_

<comment><USER17> I'm sure people were asking that when web portals like go.com were becoming dominant, and they'll be asking it long after facebook is dead.

</comment></comment><comment><USER18> On that note, i seem to recall reading that Fidonet is still being maintained.

</comment><comment><USER19> Gopher doesn't support encryption. There is no standard for gopher over tls. This makes gopher irrelevant for encrypted communications. But what makes it great: gopher is simple. You can use curl or even netcat for browsing gopher sites.

</comment><comment><USER20> I used Gopher 1993 in university, but I don't see it relevant today. It's history.

<comment><USER21> Your experience with it is not very recent, then, so it's maybe best to listen to others. :)

</comment></comment><comment><USER22> This made me laugh: gopher://gopher.frog.tips/0/JOB_OPENINGS

<comment><USER23> Browsers won't process that request, so for the uninitiated like me:

$ curl gopher://gopher.frog.tips/0/JOB_OPENINGS

* My first ever gopher interaction.

<comment><USER24> Or: [http://gopher.floodgap.com/gopher/gw?gopher://gopher.frog.ti...](http://gopher.floodgap.com/gopher/gw?gopher://gopher.frog.tips:70/0/JOB_OPENINGS)

</comment></comment></comment><comment><USER25> It's not.

<comment><AUTHOR> The author didn't say "popular" he said "relevant"

The current state of software development has huge issues with needless complexity resulting from poorly chosen abstractions.

Gopher and IRC make it possible to use any client of your choosing, thus keeping innovation and improvements accessible to anyone with an idea.

<comment><USER26> > Gopher and IRC make it possible to use any client of your choosing, thus > keeping innovation and improvements accessible to anyone with an idea.

I agree to the former and disagree to the latter---they are not correlated. In fact, IRC has demonstrated that it might be hard to adapt to new requirements without breaking many things (no matter it's an existing client, a community or a requirement itself). Today the relevance of IRC is mostly due to the existing community and not due to the technical innovation, and casual users wouldn't benefit from that. I don't know much about Gopher but I haven't seen any counterevidence to this observation.

<comment><USER8> The new(ish) IRCv3 standard does not break compatibility with existing clients though. If they don't support all of its features, they just have less things displayed.

<comment><USER26> I know IRCv3 is in progress, and I wish it to be successful, but frankly speaking this has been done 10 years ago.

<comment><USER8> Some of the more recent IRC clients already support most its new features, including v3.1.</comment></comment></comment></comment></comment></comment>


Ticketmaster Processing Fees Will Be Refunded To 12 Years Of Customers - <AUTHOR> http://www.huffingtonpost.com/2011/12/02/ticketmaster-refund-processing-fee_n_1126073.html

<comment><USER2> Seems excessive and clearly obvious to consumers. This case indicates seems to indicate that retailers - Walmart, for example - would need to place signage in front of their products announcing that they make a profit on a sale.

The point of business is to make money. Consumers actually need to be reminded of that?</comment>


Gogland – Brand New Go IDE from JetBrains - <AUTHOR> https://blog.jetbrains.com/go/2016/12/15/announcing-gogland-brand-new-go-ide-from-jetbrains/?mkt_tok=eyJpIjoiWkRZd1pHSmhaV1l3WldaayIsInQiOiJMcmVjOUxRYk5KalY4ak1FcVZMa2NraTd3dzF2aEVPYnUwNUtKdjhBT1NsK281Mm92eGxna2FRdTJhTHBOcFp0c0xPRzN6b1Y1Qk1xazJRc3NIQjZWUkk0cHFOSUs4U3FZc2l3OVNPVFwvUlMxV1JDTUVwOTM4UDNNN1FrRGY2S3gifQ%3D%3D <comment><USER2> [https://news.ycombinator.com/item?id=13184713](https://news.ycombinator.com/item?id=13184713)

</comment><comment><USER3> An actual IDE for Go makes me interested in trying out the language. What is with Jetbrains always going overboard with the syntax highlighting though? do my commas really need to be in orange?

<comment><USER4> Please share a screenshot if possible with a comment of what exactly you don't like. We'll see if we can fix that.

</comment></comment><comment><USER5> go gland?

</comment><comment><USER6> As a rule, I flag outright ads.</comment>


Why the Rampant Fanboyism Around CoffeeScript Worries Me - <AUTHOR> http://www.andrewluetgers.com/2011/09/07/coffeescript-fanboyism-rampant/

<comment><USER2> TLDR: "All these hippies are doing things that don't benefit me! I don't want a new programming language! Whine!"

The part of CoffeeScript hate I find most amusing is all the hate for the fact that it's a language that compiles to JavaScript. "The code it generates is bad!" "It's a leaky abstraction!" Well guess what guys, the C compiler that pretty much every piece of code running on your system went through does exactly the same thing, only it generates assembly. Since you don't know assembly (or anything other than how to animate ads with jQuery), you aren't complaining. But it's the same principle and it works well enough. C doesn't expose all of assembly's features. C doesn't always generated optimal assembly code. And yet, we use it anyway, because it's just so much nicer than the "real" underlying language. (And of course, x86 assembly is not what x86 processors run anymore. But that translation takes place in silicon, so you see even less complaining.)

Complain about actual problems, not about what you can see. If all you talk about is the obvious, you look stupid.

<comment><USER3> If you read the whole article the author is actually not saying that he agrees with those complaints. And yes as an Electrical Engineer I can write assembly code.

<comment><USER2> Right, but there aren't enough people in the world that can critically analyze the output of a C compiler to start an Internet meme that "C is evil".

<comment><USER3> Point taken sir, point taken.

</comment></comment></comment></comment><comment><USER4> I wrote the user-interface for my iPad app in JS (using PhoneGap) initially. Working on a large pure JS UI project sure makes you realize the shortcomings of JS, both fundamental and syntactic. It took a week to convert the JS to CS by hand and I did it hoping that the one-time effort would pay itself off over the next few months of development. Within just 2 weeks after the conversion, I started cranking out more features than I had in months before, and surprisingly with very little new code being written.

CS enabled me to write cleaner, simpler code in 5 lines instead of 30 lines in JS. While I don't care about the LOC as a metric of performance, I do have a limited short-term memory and can't remember the intricate workings of a class I wrote 2 months ago. Being able to recollect how a class functions is significantly easier if you have to read 50 LOC instead of 300.

I don't understand why people worry about being pro or against a language or a variant. Before CS, I managed to write decent JS that made me productive. With CS, I write better code and am more productive. Hence I continue to use CS. YMMV.

Also it's amusing to see this was posted to HN by jashkenas himself.

<comment><USER5> Nit-pick: 2 months is not 'short term memory'. Short term memory is limited to the now. It's limited to things you are actively thinking about.

While I haven't used CS for anything professional yet, I've used it for personal projects and it's been pretty nice. Except for the lack of a great reference guide. I've spent more time Googling than I'd like to.

But compared to what I'd have had to do in Javascript for the same code... There's no way I'd have used Javascript for a lot of it.

CoffeeScript is definitely a competitive language for me.

</comment></comment><comment><USER6> At one point, the author writes:

> OK im done ranting at invisible Brendan Eich now (as if hes going to read > this) :-)

Write a more cogent piece, and he will. I'm amazed at how generous Brendan is with his time. He responds to tweets, and to numerous comments on his blog. When I asked him to look over the part of my CoffeeScript book that deals with the history of JavaScript, he not only did so, he also offered technical corrections and suggestions pertaining to other parts of the book. Just today, he took to HN to participate in a vigorous discussion of Google's forthcoming Dart language: <http://news.ycombinator.com/item?id=2982256>

In short: Rather than using the creator of JavaScript as a strawman in a meandering diatribe (one that's 3,700 words long and yet "only 1/3 done"), you should try to organize your thoughts and engage with him.

</comment><comment><USER7> I love and use CoffeeScript because it removes almost all of JavaScript's cruft, making the true purpose of the code much clearer. Ultimately, removing cruft is all CoffeeScript does—it doesn't fundamentally change JavaScript—but _man_ does it do it well.

That being said, CoffeeScript has bugs[1]. I've run into its bugs before, and there are few things more frustrating than dealing with bugs _in your language_.

[1]: [https://github.com/jashkenas/coffee- script/issues?labels=bug...](https://github.com/jashkenas/coffee- script/issues?labels=bug&sort=created&direction=desc&state=open&page=1)

<comment><USER4> > it doesn't fundamentally change JavaScript—but man does it do it well.

I guess it really depends on our definition of fundamental. Certainly, it doesn't turn JS into Lisp. But it does introduce concepts that while possible in JS, are not nearly as easy and transparent to use. E.g. the 'do' keyword. When I write CS, I think using 'do' and not "let me insert a closure here to ensure variable values aren't overwritten in the loop." Same with comprehension, function binding (=>), and classes in CS.

Syntactically, I can't live without Heredocs because my project involves a lot of HTML generated dynamically through JS/CS.

</comment></comment><comment><USER8> At least it's not an incredibly long and rambling " _one third finished_ " (!!) essay in _favor_ of more terseness. Because that would be ridiculous.

<comment><USER6> Ha, your comment made me wonder momentarily if the essay was a work of post- modern art, subversively advertising the benefits of CoffeeScript through an implausible flourish of logorrhoea. If so: Well done, sir.

</comment></comment><comment><USER9> Seems weak and confused. There are some good arguments to be had around readability, writability and when to focus on what.

Those are not here.

<comment><USER10> Agreed. It really sounds like the author doesn't want to like CoffeScript for reasons along the lines of "CoffeeScript is just some hipster code for people that like the idea of being great programmers"

</comment></comment><comment><USER11> Hey im the author. Its pretty clear im getting murdered here on how long winded yet incomplete my post is. Next time I'll wait till its done to post :-) and edit a lot more. I lol'd at some of these comments. I certainly don't take myself too seriously but obviously have strong opinions about JS and the direction of harmony. I have used the very hot topic of CS as a hook to talk about something a bit more boring, the standards process and where its taking JS. Thanks so much to those that read the whole thing, I'm sorry it made it to HN before I finished it. Seeing as how I've had all of 5 visitors to my blog I wasn't expecting to get too much visibility to it. It was more a way to organize my thoughts and stop accosting my co-workers at lunch time with my long winded rants. But I am still working on it and will post the other parts and a much shorter min version once its done.

</comment><comment><USER3> Well written, though a tad [ok, way too] long. Having had TJ reject a Coffeescript related pull request of mine on a project of his I have experienced his and the Learnboost teams distaste for Coffeescript.

My problem with CS is the way it is taught and demonstrated, with every example trying to outdo the last in how much syntax they can leave out. It makes the code "pretty" but unnecessarily complicated. Otherwise I am a fan of reduced boilerplate, comprehensions and the like. Just don't expect me to remove () just because I can.

<comment><USER9> Poorly written and quite long winded. By the time the author arrives at his second argument he's lost steam.

</comment></comment><comment><USER12> Maybe the author should just, you know, not use CoffeeScript. I have a problem with preferential statements framed as empirical statements as well.

"CoffeScript make you more productive!"

Not if I'm wildly proficient in Javascript and hate Ruby.

Horses for courses, Andrew. Some mechanics prefer Mac tools, while others prefer Snap-On. The only one that is wrong is the one who claims they built a better motor because of the brand of tools they used.

</comment><comment><USER13> I like the idea of CoffeeScript. But so far, for me, it's just not _better enough_ for me to use it over plain JavaScript. The reason I use C over assembly is b/c there is such a HUGE difference. If C were only marginally better I wouldn't bother with it either.

<comment><USER4> What kind of JS projects do you have? CS is certainly overkill for form validation but if you have 50+ JS files that all need to talk to each other, CS can help make things cleaner and succinct.

<comment><USER13> Don't think I've got anything quite to the level of 50+ files, but I've done some smaller scale javascript only applications where the only thing done backend was a restful database wrapper.

I agree that it can help a bit, but I've tried it, and I didn't notice enough of a productivity increase to bother adding a compiler step.

I'm the type who would use and occasionally has used assembly (this was embedded stuff mind you), so I might not be representative.</comment></comment></comment>


It's called "Ship" not "Shit" - <AUTHOR> http://blog.heyimcat.com/its-called-ship-not-shit/ <comment><USER2> The one thing people seem to forget: MVPs are supposed to be _experiments_. You do an MVP to figure out whether it's worth your time to build a product for a particular market (i.e. whether there is "product-market fit"), or whether you should pivot to something else. You make them minimal so you can afford to do more of them, because it's unlikely your first one will work. You make them viable because, if they aren't, your experiment won't tell you anything (people won't use it, even if they need what it does.)

If you already know your product is something people want (e.g. something a bank would just give you a business loan for), you obviously don't need to do an MVP, because there's already product-market fit. Starting a pizzeria? Front-load your investment and make a really great pizzeria; buy huge ovens, etc.

If there's literally nobody serving your market, such that it's unclear whether it's even a "need" or not—please don't spend years building the perfect solution to the "problem." Find out if it's a problem first. Build a prototype. Show it to people. Get them to say they're willing to pay you for it. That's what an MVP is.

(And, as soon as you've found your product-market fit, and decided which product you're going to build? Stop thinking of that product as an MVP. It's a real product now: make it good.)

</comment><comment><USER3> I remember reading once that part of Apple's success was owed to their shunning of lean principles, that they only ever ship complete, mature products. I would say that couldn't be further from the truth: the original iPhone was about as minimum-viable as a category-defining hardware product could be.

It did only a few things (web browsing, media playback, email) better than anything else on the market, and left out nearly everything else that wasn't critical to that core functionality (Exchange support, software ecosystem, _copy and paste_ ). If anything, the original iPhone was a demonstration of lean principles applied extraordinarily well: A bare minimum of functionality executed at eye-poppingly maximum quality.

<comment><USER4> The difference with Apple is that even when they do minimum, they polish that minimum offering very well. I know exactly the kind of stuff the article author is talking about, and most of it undercuts whatever ideas are being tried out.

<comment><USER5> Exactly. The iPhone might have been a minimum-feature product, but it surely wasn't Minimum Viable Experience.

</comment></comment></comment><comment><USER6> This reminds me of my workplace.Unfortunately at my work-place people tend to confuse MVP with agile and TDD and then let all the bugs fly around pre- production and viola we go live with known bugs all around and hence depreciating customer confidence.

Quality is often overlooked here, b/c someone else proved that it can be done in 20 days and everyone wants it done in the same 20-days ,no-matter how bad the product goes out of shape :)

With time, this pattern only seems to worsen as there is less money being made day-by-day!

</comment><comment><USER7> An MVP is an ugly lean-to (not even shack - [http://en.wikipedia.org/wiki/Lean-to](http://en.wikipedia.org/wiki/Lean-to)), it is 100% functional. Building it means getting airdropped into a completely unknown forest with an axe and nothing else (in this analogy the unknown is your market, and only an axe because you have no programmer resources except what you can wield by hand for a few hours), a few pieces of tarp, and 8 hours until freezing night temperatures set in. And maybe wolves.

It's not a minimum viable house, minimum lovable house, or whatever else. It literally is the absolute smallest thing that can POSSIBLY meet purely physical requirements such as protection from wind or holding some warmth so that you can, ahem, not die, and which you have any hope of building with no resources, and from nothing, using nothing. This is why it is absolutely crucial to know how long it takes to build, and why people focus on it.

In the market, it is the absolute smallest thing that anybody can use to achieve anything.

It doesn't matter what this designer thinks of MVP's, because when a designer starts getting involved, you are way outside of MVP territory. This author is an interior decorator criticizing a survival guide.

To the author: I don't know if you program, but if you want to experience the meaning of MVP, try coding something up enough for anyone to achieve anything using it. I guarantee you will not miss the time you spent not getting the design (aesthetics, love, etc) right.

On the other hand, you will die in the cold if you have nothing but a beautiful photoshop mockup to look at. That is the meaning of MVP.

</comment><comment><USER8> This reminds me of the Humbug in The Phantom Tollbooth, who is described as "[someone] who always managed to be the first with the wrong answer" and later tries to argue that it was the question itself, not the answer, that was wrong.

It's a shockingly good lesson that I seem to re-learn every six months or so. Being first is never a virtue in and of itself. MVPs that sacrifice quality for speed (instead of sacrificing scope) always end up as painstaking rewrites at best, and slow slogs to failure at worst.

Something I think most miss is that taking on this technical debt is ok when you don't know which direction to go [0]. Get something to market to _learn_ , not to be "first" or "right".

[0] [https://www.youtube.com/watch?v=pqeJFYwnkjE](https://www.youtube.com/watch?v=pqeJFYwnkjE)

<comment><USER9> As an aside, this reference makes me happy. The Phantom Tollbooth was one of my favorite books when I was younger, just brilliantly written. So many good lessons about life (the Humbug being a great example). Another great one that is somewhat applicable here is Canby, the regular visitor to the Island of Conclusions, who attempts to be as much as he can be of all things (hence his name), which leaves him not very much like any of them, instead of picking one thing and mastering it.

</comment></comment><comment><USER10> Is this really a problem in the design/startup community or does it just appear to be so as judged by the loudest bunch? I'm not _in_ the community so maybe I'm just not exposed to it directly, but these criticisms are awfully similar to what was happening before the first DotCom bust.

<comment><USER11> There is really and truly a problem. I've worked full-time for several start- ups (I'm working full-time for one now) as well as consulted for several more. I've also networked with a lot of startup founders and know many other people in the industry. From my limited experience it seems endemic - the kinds of people who flock to this apparently easy money are the kinds of people solely focused on winning the startup lotto quick. Not the kind of people focused on building good businesses. This means you get all sorts of short-sighted approaches to things. When those are inevitably frustrated by complicated realities (eg. when business isn't as easy as people were led to believe by movies and books) you then see founders/managers scramble to justify these bad practices. I've watched companies loop like this until all their funding went down the drain and then the founders go and do it again somewhere else. It's one of the big myths that needs to get busted - Adam and Jamie we need you! I'm trying to do my small part on the daily.

<comment><USER12> It sounds like people are trying to built something that just good enough to be bought by Facebook, Google, Microsoft or Yahoo so they can bailout, perhaps give a few talks and may rake in a few thousand Twitter followers.

<comment><USER5> That's _exactly_ what they're doing. It's called "an exit strategy", and apparently any self-respecting startup ought to have one.

A lot of things about the products we see become clear when one realizes that the primary focus and goal of a exit-seeking, toilet-paper[0] startup is to get bought for a lot of money, period. The product itself is a lie, it doesn't matter what happens with it - its only task is to attract new users fast - i.e. be growing, which is a proxy for "we could be profitable in the future". If the startup maintains this growth long enough, there's an increasing chance that someone will come and buy the company. The product gets killed, founders write some audacious blog posts in which they thank their (former) users for giving them the opportunity to have those coctails at the acquihire party ("it was our journey, we couldn't make it without you..."). Everyone is happy, except the users, who get screwed. Again. Live. Die. Repeat.

Of course most of the toilet-paper startups won't sustain growth long enough and will just disappear somewhere along the way.

I sometimes wonder why we (as users) keep tolerating this. People lying in our faces that they care about us and our problems, that the product is really meant to help _us_. Fool me once, fool me twice... but we've been fooled since the dot-com and we still haven't learned.

[0] - [https://news.ycombinator.com/item?id=8319102](https://news.ycombinator.com/item?id=8319102)

</comment></comment></comment></comment><comment><USER13> MVP is about cutting out non critical features, not quality. Without the quality you just end up being slower at iterating and the whole process falls apart.

<comment><USER5> But it ends up cutting out on quality, because people are used to put up with quite a big amount of crap. If it weren't the case, a whole great deal of _business models_ wouldn't ever panned out.

<comment><USER14> Has anyone _ever_ produced a maximum viable product?

Or even tried to produce one?

</comment></comment></comment><comment><USER15> All you really need is a long view. You can ship something with, say, two features now, but done in a way that _anticipates_ the other 10 features you'll implement later. Planning should take a while. And when it's done you can ship bit by bit without screwing up your timetable or the product's integrity.

</comment><comment><USER16> MVP, MLP, MUP or whatever you want to call it needs to create value for at least one person.

Value + People

The product needs to increase the number of people extracting value from it, increase the value your product creates or both.

Facebook creates some value for a billion people, thats why it is valuable to the tune of $203.58B.

The question is what is the smallest amount of value you can create with the smallest input for one person to test your idea that you know can scale to as many people as possible or continually increase the value for that one person.

And your product doesn't need to be code initially.

</comment><comment><USER17> I firmly believe that MVP culture the writer is referring to comes from Venture Capital, as a way for VC's to ping the market state faster at the cost of individual startups.

In aggregate they get more data and more likelihood to get find a single success faster, but you as an individual startup are far less likely to find success.

</comment><comment><USER18> catchy title and this was a great reminder of finding the balance between speed and quality. Many answers that I was looking for have been presented through user growth and interaction. Without getting my app up there, it would be very difficult to come to that conclusion. I have also found that building a solid foundation can save time in the future even though it may cost more time currently.

A super simple example would be writing lines of code. Making sure all the tags line up properly and everything is commented out will allow the app to flow more efficiently in the future. Go-fast/efficiently</comment>