When Zuckerberg Asserted Control, Instagram's Founders Chafed - <AUTHOR> https://www.nytimes.com/2018/09/25/technology/instagram-cofounders-resign-zuckerberg.html <comment><USER2> I'm not sure that Facebook using Instagram as a way to funnel people back to Facebook is a great strategy. Companies need to be willing to cannibalize themselves or someone will do it for them.

I don't know if Zuck had the foresight at the time, but Instagram has obviously been an amazing hedge against apps like Snapchat. People like Instagram and Snapchat partly because they are less formal than Facebook, most users don't even know that Facebook owns Instagram, my girlfriend is always shocked (and a bit annoyed) when I tell her.

I think it'd be smart to simply enhance Instagram's ad platform and be willing to cede Facebook MAU over to Instagram, at the end of the day the dollars all go to the same account.

If people start to become dissatisfied w/ Instagram because of "Facebook- ification" that may open up a market for a new competitor.

<comment><USER3> I saw some usage data in a quartz article, that I can't find, earlier this week. Facebook was the most popular social media platform across teenagers, millennials, generation x and baby boomers.

The real interesting data was in teenagers though, their most popular platform is Snapchat, but none of the platforms had managed to make more than 40% of teenagers create an account with them.

I think this is interesting because it shows that Facebook isn't really sucking that much worse than Instagram and that Instagram isn't going to save Facebook on its own.

From a more anecdotal perspective, I think the integration was smart. I'm not very active on social media, but I do use Facebook to arrange events with my friends that live in multiple cities. Because I see people sharing Instagram posts on Facebook through the integration, I've considered creating an account. Of course I've also considered leaving the platform because Facebook keeps doing the wrong thing.

<comment><USER4> I'm guessing that data was based on simply having an account? Because I feel like teenagers all have a Facebook account, but few actually use it with any frequency.

<comment><USER3> It was, twitter, Instagram and Facebook were lower than 30% and Snapchat was around 40%. For teenagers.

For millennials Facebook was above 80% with Instagram and Snapchat sitting above 60% and twitter somewhat lower.

I mean, having an account isn't as interesting than usage, but when less than 30% of teenagers have an account, they probably aren't using it a whole lot.

I wonder where they went though, the article didn't say anything about that. Discord maybe?

</comment></comment></comment></comment><comment><USER5> > As Instagram kept on growing, Mr. Zuckerberg believed there were ways it > should help Facebook grow and improve Facebook's "user engagement." That > included small tweaks, like automatically sharing Instagram "Stories" videos > to Facebook without clear signs indicating the videos were taken on > Instagram.

That's a little sneaky. I had started to notice more stories when I opened FB, and it was always the people I'm also friends with on Instagram. I hadn't realized that they may be coming from Instagram.

> Earlier this year, Facebook also removed a shortcut link to Instagram from > its "bookmarks" menu inside the Facebook app, a small but significant source > of traffic that flowed from Facebook to Instagram.

What would the point of this be? Why would FB want to shut off traffic to another one of their properties?

<comment><USER6> > What would the point of this be? Why would FB want to shut off traffic to > another one of their properties?

They make waay more money off of facebook ads than they do from instagram ads. And they're seeing people dumping Facebook in favor of just using Instagram. They're trying to staunch the bleed.

<comment><USER7> Exactly. Facebook just isn't "cool" anymore, no one posts to facebook like they do with snapchat or Instagram, so why not?

</comment></comment></comment><comment><USER8> Second-to-last paragraph really makes the article:

> And their departure, despite its suddenness, does require some perspective. > Both Instagram founders stayed on for six years after being acquired — much > longer than entrepreneurs usually do after selling their company and long > after they had received their full payout in stock.

Dog Bites Man After Unusually Long Delay

<comment><USER9> A dog that waits that long to bite is probably starting to get abused in some fashion.

</comment></comment><comment><USER10> Good for Zuckerberg. He bought it, he owns it, and he can do whatever he wants with it. I don't get the sympathy for the Instagram founders. They sold it and made a quick fortune. Detach, drop out, and have some fun.

</comment><comment><USER11> One thing omitted from the Instagram genesis story is that they effectively stole the Hipstamatic "filters" feature and added a basic timeline a la Twitter. Sharing to Twitter fueled their growth from that point. And the rest is history!

<comment><USER12> Around the same time as these there was another app that made you drag a depiction of your photo around a mock darkroom to "develop" it with those "filters".

<comment><USER13> Wasn't that the app that had the genius idea to make your photos more "important" by charging you an in app purchase for "film" so you would only take pictures of things that mattered?

</comment></comment></comment><comment><USER14> Doesn't "Probably not, he said. At least, not as quickly." and "Perhaps. Eventually." mean essentially the same thing?

<comment><USER15> IMO its a different tone. The first says "no. well... maybe..." [I don't want to undercut the value of the property] whereas the other says "yes. well... maybe..." [I don't want to appear unappreciative of the resources of the company that owns mine].

<comment><USER16> To be annoyingly precise, the second says: "Maybe, well... yes."

<comment><USER15> Fair! :) I see how you read it that way; to me perhaps is corporate speak for a noncommittal yes, and eventually is a way of making it even less committal by specifying a long timeline. I mean, anything could happen eventually, it just depends on when you mean.

</comment></comment></comment></comment><comment><USER17> I've made some comments here previously about how Facebook has been ruining Instagram by making it into Facebook, and it looks like the founder agrees.

</comment><comment><USER18> I believe Instagram's founders just rode the train until it was not fun anymore.

<comment><USER19> Exactly. No worries all around.

</comment></comment><comment><USER20> "Mark Zuckerberg was asked if Instagram could have hit one billion users if it had not been bought by Facebook.

Probably not, he said. At least, not as quickly. [...]

Kevin Systrom and Mike Krieger, had a slightly different answer to that question.

Perhaps. Eventually.

We will never know who was right."

What if, Instagram had merged with Snapchat instead?

<comment><USER21> Facebook would have leveraged its user base and clout to smother them in the crib.

This is why they ought to be one of the first targets for anti-trust regulation. Any company that can leverage its market size to kill competition, irrespective of the quality of their product, needs to be taken down a peg.

Google and Amazon should be close behind. And Apple needs to be put on notice.

It's not even that those 3 companies are bad actors in themselves (thought they are and aren't in various respects). It's that their investors need to know that lock-in and megalomania as business strategies aren't acceptable.

<comment><USER20> While you're not wrong from a regulatory standpoint, I think consumer product- wise both Instagram and Snapchat were among the strongest challengers to Facebook as far as insurgent social media networks went. If they had merged- well, the leadership would be dysfunctional, but it would have been very entertaining to see Facebook on the defensive.

<comment><USER21> > I think consumer product-wise both Instagram and Snapchat were among the > strongest challengers to Facebook as far as insurgent social media networks > went.

Maybe. I feel like one of the issues with a lot of start-ups is that the engineers who build them and happen on the ideas don't have the business instincts to outmaneuver bigger, well-funded challengers. And when they bring on VC funding or people into their companies who do have those skills, they inevitably push them to the same sorts of unfriendly monetization and invasive schemes that the big players have. Very few people have the political acumen to tell investors to STFU the way people like Jobs or Bezos were able to, so they're just open to predation by VCs.

</comment></comment></comment></comment><comment><USER22> It's a lot easier to stand for your principles and say no to $850M if you already own billions...

<comment><USER23> Indeed, how much of a moral stance is it when you only make it on the last billion?

<comment><USER24> It isn't a moral stance. This is PR.

</comment></comment></comment><comment><USER25> Do we have a name for tech that encourages compulsive use over any kind of deeper value? Candy tech? Sugar tech?

<comment><USER26> Yes, there's even a book about it: "Hooked" by Nir Eyal.

</comment></comment><comment><USER27> What do you really expect when you sell your company?

<comment><USER28> This is certainly the question in general, and I'd like to know specifically what they thought the first six years at Facebook should look like.

</comment></comment><comment><USER29> I'm not on FB. I also haven't used Instagram for a while. How has Instagram changed in the last few years?

<comment><USER30> That's an interesting question! For $2500, I would be happy to curate a post for my 17,000 Instagram followers featuring your question in the text of a post of myself near a slightly off-trail vista at a remote yet recognizable exotic location.

<comment><USER29> So you're saying it's a bunch of people trying to earn money endorsing merchandise and places?

</comment></comment></comment><comment><USER31> When you sell it. You take the money and it's not yours anymore. Doesn't matter what's said, this is just how it is. This shouldn't be confusing.

<comment><USER32> Agreements and contracts can dictate otherwise.

</comment></comment><comment><USER33> Zuckerberg: Take the money.

Acton: I'm not taking it.

Z: Just take it.

A: No!

Z: Look, I don't give a fuck, but the boys'll feel better.

A: Fuck their feelings!

Z: [Brian], we're a team.

A: A team? You guys are fucking insane. I'll go back to the Valley, I'll [create messaging apps]. It can't be like this.

Z: It is. I'm sorry, but it is. It's ugly, but it's necessary.

A: I became a [developer] to put away dealers and criminals, not to be one.

Z: You sound just like me. I know what you're going through and feeling. You're scared.

A: I'm not.

Z: Yes, you are. Everyone goes through that the first time. I did. The sooner you match what's in your head...with what's in the real world...the better you'll feel.

Z: In this business...you gotta have dirt on you to be trusted. When all this is behind you, a whole other world will open up for you.

Z: I walk a higher path, son.

Z: I have the keys to all the doors.

<comment><USER34> Is this a joke?

<comment><USER35> It's the transcripts they'll recite during the canonization of St. Acton, patron saint of "After I get Mine".

<comment><USER36> Lol at the flak being hurled at this guy like we wouldn't all do exactly the same thing, were we in his position.

<comment><USER35> Not true, I would have stuck it out for another year for the extra $850 million.

<comment><USER15> I mean, that's a lot of zeroes. I was going to say commas but that doesn't really reflect the magnitude right :P

</comment></comment></comment></comment></comment></comment><comment><USER37> Side note: For anyone interested, the third picture down[1] in the article is a fairly high resolution photo of a computer monitor where you can see Xcode and some very neat Objective-C code.

[1]: [https://static01.nyt.com/images/2018/09/25/business/25INSTAG...](https://static01.nyt.com/images/2018/09/25/business/25INSTAGRAM04/merlin_45856561_88d6defc-30be-44f9-acf5-9aef8849cb09-superJumbo.jpg?quality=100&auto=webp)

<comment><USER38> I wonder when this picture was taken. The iPhone design in the simulator, the old Gmail favicon, the old OS X scrollbars all indicate this being several years old.

Wouldn't be surprised if this code has been rewritten multiple times since.

<comment><USER39> Their code is using manual reference counting so it must have been taken before ARC was introduced on WWDC 2011.

<comment><USER15> Not necessarily; for the same reason many companies haven't jumped on Swift (specifically, not wanting to run all your hundreds of thousands of lines of code through a potentially buggy translator all the time), people didn't immediately jump onto ARC either. If I recall, that migration was far from painless. I remember some serious regressions introduced when I bit that bullet. Since all your code changed at once, tracking it down was hardly entertaining. IMO could have been anywhere from 2012 to 2013...

This code also appears not to be using automatically synthesized properties. On the left screen, they're directly accessing Ivars and their Ivars have trailing underscores rather than leading (the default when synthesized). I suppose they could be doing this anyways, though it wouldn't exactly be standard industry practice.

On the right Xcode screen, though, the code does use property syntax, so potentially ARC, although one doesn't imply the other.

</comment></comment></comment></comment><comment><USER40> Duh, he owns the company. You sold it.

FB needs to show xx% growth or else it's toast. So they start looking under couch cushions for pennies...</comment>


Epic Games founder says Microsoft's patches will make Steam progressively worse - <AUTHOR> http://www.pcgamer.com/tim-sweeney-thinks-microsoft-will-make-steam-progressively-worse-with-windows-10-patches/ <comment><USER3> This is something that has long been feared. It's also rather like the Y2K problem in that as long as people make a noise about it, it can be prevented - but preventing it leaves all the complainers looking alarmist.

It's also why Valve have invested in the Steam Machine. At the moment it's not a serious competitive prospect, but it's there ready as an escape valve.

After all, only one company can get a 10-30% cut of games sold to run on Windows, and Microsoft don't see why it shouldn't be them.

Microsoft do phase things out, but only slowly, with long migration times for business users.

<comment><USER4> A Steam Machine is just as bad as a Microsoft Machine.

<comment><USER5> Bad in what way(s) in particular?

<comment><USER4> Steam is just as bad as the Microsoft store is what it boils down too. Centralized control over games you've paid for. It doesn't matter who it is, it's not good.

</comment></comment></comment></comment><comment><USER6> Former Softie, worked in Windows for 9 years from Vista to Win8, mostly on the Shell and UI platform teams. For Vista and half of Win7 development, I was the PM owner for our UI platform (comctl32, DirectUI, Visual Styling, and High DPI). This is my opinion, I don't speak for the company -

During my time there, I did not see any anti-competitive practices the author is speaking of. Those days are long gone. I know first hand we were committed to compatibility and growth of the platform, new and old. That being said, it's clear that building on Win32 is painful and not cheap. Win32 is great if you want direct system access and complete control over _everything,_ up and down the stack. This works well for large enterprise applications and games. The tradeoff here is that you must roll your own everything and work hard not to do stupid shit.

During the Vista days, we saw that the Windows app ecosystem was struggling because we didn't have a good platform story. You had to choose between Win32 and .NET. If you're a native developer, it was Win32. Win32 didn't provide a great app and UI framework (have you ever tried to owner draw a control or do fluid layout?). This is why many app developers during that time built their own app and UI framework, used MFC or leveraged a 3rd party framework. I was only familiar with the app platform so I can't speak to the options for building a game. I'm sure it was limited as well.

Microsoft introduced many platforms since Vista - WPF, Silverlight, XNA, Win8 Apps (Windows XAML and WinJS), and UWP. I'm sure there are more :) Even with all of those new platforms in the mix, Win32 is still alive and well.

I believe UWP is a huge win for developers. You don't need to roll your own _everything._ For the companies that want complete control, Win32 is still there. It is true that certain things are only available to UWP developers. There is no malicious intent, it's really only about priorities. The new thing comes first. The developer community needs to speak up if they want something. Microsoft will listen.

<comment><USER7> While i don't believe a word Sweeney says until he sources his claims, your post has a few self delusions as well.

> Microsoft introduced many platforms since Vista - WPF, Silverlight, XNA, > Win8 Apps (Windows XAML and WinJS), and UWP. I'm sure there are more :) Even > with all of those new platforms in the mix, Win32 is still alive and well.

Not "Even with". More like "thanks to this chaos and the uselessness of those platforms".

> I believe UWP is a huge win for developers.

Without specifying which developers, that is meaningless. Last i heard a game dev can't even control vsync.

> The developer community needs to speak up if they want something. Microsoft > will listen.

This is the worst part. Speak up WHERE? Speak up HOW?

"Listening" is not "reacting when a blogpost gets reposted everywhere". Listening is taking the time and place out of your day to make sure that the person has your undivided attention.

</comment></comment><comment><USER8> This is nonsense on stilts. There aren't UWP versions of half of Office, and the ones with UWP versions aren't as full-featured as the Win32 versions. There's no UWP version of Visual Studio. Look at the revenue from those two things, look at Microsoft's gaming revenue, look at Valve's revenue... what is the evidence that Microsoft is willing to sabotage their Windows, Office and Visual Studio product lines all to get a rounding error's worth of additional profit?

<comment><USER9> It's a very long term thing. It'll probably happen because new APIs will be on UWP and not on Win32. I think VR might be the "next thing" that'll only get in-OS support in UWP.

<comment><USER10> Windows' thing has always been backwards compatibility (not counting programs with questionable code in the first place), and the entire OS is win32 as well.

They'd practically be telling all their casual, professional, and enterprise userbase to not update. Their prior support for win32 has locked them into it, even if they want to leave it

<comment><USER11> > Windows' thing has always been backwards compatibility

I think they are realizing that it's holding them back and I suspect they will be less afraid of breaking things in the name of progress.

When I updated my laptop from Windows 7 to Windows 10, it just uninstalled the things it thought was incompatible (a Cisco VPN client was the big problem).

In fact, the sneaky and slimy strategy that they used to get people to update to Windows 10 feels almost like contempt for customers that don't want the things Microsoft is pushing.

Is the PC gaming market a big one? Is there an opportunity here for Linux to become a gaming contender?

<comment><USER12> There certainly is an opportunity, it's just still very questionable how things will play out.

Current state is that 25% of the Steam library is Linux-compatible. That's about 2500 games, so definitely enough to keep you entertained, unless you're the type of gamer who always has to play the newest AAA titles.

With Vulkan slowly picking up adoption, this will probably increase even more rapidly in the future, too.

Next thing is that Vulkan as well as DX12 make it so that drivers for graphics cards will be much smaller and therefore the resulting drivers will be much less likely to be broken, which has been a big problem on Linux in the past.

But Nvidia has now pretty good Linux drivers anyways and AMD has recently started investing more resources into it. Among other things, AMD open-sourced their drivers, so now the Linux-community can help to fix up their drivers instead of maintaining an own driver.

I also figure that the growing machine learning market gives a good incentive for Nvidia and AMD to have good support for Linux, so that should translate back to the desktop, too.

The only problem is that all of this can serve as reason to not avoid Linux, but unless Microsoft really does continue making such great arguments against using Windows, we won't really see many people change operating system...

<comment><USER11> > 25% of the Steam library is Linux-compatible

When a title is Linux-compatible, does that mean it works flawlessly? Does it use Wine?

<comment><USER12> It means that the developers marked it as Linux-compatible on Steam.

I don't know, if Valve requires anything for that, but it's specifically _not_ the percentage of titles which you can get to work through any combination of black magic. It's the percentage of titles where the developers offer you support, if it doesn't work on your system.

And I know that some of those games do use WINE internally for the port, but it's properly pre-configured in a wrapper and should work just as well as a native Linux-game. So, you don't need WINE installed separately on your system for those.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> Oddly enough Steam isn't that great for developers either. It takes a huge cut, it takes cut of all microtransactions, it bullies developers into price fixing and sales, and it abuses it's de facto monopoly to ransom developers that want to publish on Steam.

For consumers it ain't that great either, the curation process on steam is non existent, it does not force developers to maintain compatibility, the search option is very bad and you can not filter games based on release year (you can only see the year they released on steam and I've seen people buying 15 year old games by mistake). Steam ties you into their DRM (you can also use a 3rd party DRM if you want) and their API's.

Saying that Steam is somehow the champion of open gaming on Windows is silly, it's a monolithic monopoly that does pretty much my way or the highway moves all the time. So far I haven't seen any evidence that MSFT has any interest in killing Win32, but maybe it should, if UWP can become a better platform at the end I don't see any reason to stick to Win32 when developing applications. All our mobile platforms have a single store, Apple has it's own store, based on the few UWP games that have been pirated you can install UWP applications without using the store, MSFT can in the end support 3rd party distributors. And if it doesn't well TBH considering that Steam hasn't been a champion for consumers for a long time, I don't really see it as being a "bad" thing, and if Microsoft makes them worry maybe they'll get their shit together again.

<comment><USER14> How does it ransom developers? That's a bold claim.

</comment></comment><comment><USER15> Sweeney provides this as Microsoft's alleged strategy to get rid of Steam:

"Slowly, over the next five years, they will force-patch Windows 10 to make Steam progressively worse and more broken. They'll never completely break it, but will continue to break it until, in five years, people are so fed up that Steam is buggy that the Windows Store seems like an ideal alternative. That's exactly what they did to their previous competitors in other areas. Now they're doing it to Steam. It's only just starting to become visible. Microsoft might not be competent enough to succeed with their plan, but they're certainly trying."

What previous competitors is he talking about?

<comment><USER16> There used to be a saying "DOS ain't done 'til Lotus won't run" (although that's now largely regarded as apocryphal/inaccurate), and the memos around the "AARD code" [1] are fairly damning.

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

<comment><USER17> That happened 25 years ago, and even the guy who wrote the code has been dead for eight. I don't think it's a solid data point for predicting what Microsoft is going to do tomorrow.

</comment></comment></comment><comment><USER18> I don't really understand why it bothers game makers? Either it's Steam that takes a 30% cut or it's Microsoft?

Sure you can sell your games standalone and I doubt that will never change but most games benefit on being on a platform like Steam or Microsoft Store. For me as a consumer, I like that there is competition.

<comment><AUTHOR> The thing is that if one day Microsoft decides to phase out the Win32 platform and leave only UWP, right now the _only_ official way to get UWP apps is through the Microsoft's Windows Store. So the competition you're talking about would disappear because there would be only one way to get Windows software, the Microsoft way. It would be impossible to have competing App Stores, similar to the situation right now on iOS.

Seems far-fetched but I can see Microsoft slowly deprecating Win32. It would be similar to when Apple deprecated Carbon, only slower: they'll stop adding new features, they'll tell developers to avoid it for any new development, etc. Won't happen overnight though as they're too much legacy software out there, but it could happen in the span of several years, a decade or so. Right now what I'm saying is fiction but it's a possibility any store developer like Valve and customers too should have in mind.

<comment><USER19> If Microsoft ever deprecates Win32, they won't sneak it overnight. Anyone can integrate UWP into their store today if they want, and they would have plenty of time to do it. This is a company that still supports Windows XP from 2001 with special contracts. It seems strange to compare this theoretical point in the future where Win32 is deprecated with who supports it right now. It's a good point that it's important to have platforms that no one company controls, but this fear of UWP seems unjustified when it's open to anyone.

<comment> squeaky-clean We're comparing it to this theoretical point in the future because that's literally what the article says.

> "The risk here is that, if Microsoft convinces everybody to use UWP, then > they phase out Win32 apps. If they can succeed in doing that then it's a > small leap to forcing all apps and games to be distributed through the > Windows Store. Once we reach that point, the PC has become a closed > platform. It won't be that one day they flip a switch that will break your > Steam library – what they're trying to do is a series of sneaky manoeuvres. > They make it more and more inconvenient to use the old apps, and, > simultaneously, they try to become the only source for the new ones."

<comment><USER19> What I'm responding to is "if one day Microsoft decides to phase out... right now the only official way..." If they ever decide to phase it out, it won't matter what support UWP had mid-2016, it will matter what support it has when the phase out happens. Also, it's officially sanctioned right now to sideload downloaded programs not installed from the Microsoft store. Microsoft has publicly promised never to close the platform, and they aren't so powerful that they can afford to go against their development community like that. There's nothing at all indicating that Microsoft is going to shut out competing app stores and sideloading. The only evidence is that some people feel that Microsoft wants to do that.

</comment></comment></comment></comment></comment><comment><USER20> There are so many "what ifs" to get to his feared state. It's hard for me to imagine Microsoft phasing out win32 (especially after the disastrous results on WinRT).

<comment><USER3> While Win32 is hard to phase out, DirectX is more flexible and crucially not critical to business users of Windows. There was already a mini-version of this fiasco when DX11 launched for 7 but not Vista. Microsoft could quite easily say that e.g. DX16 would require UWP, distribution through the Windows store, telemetry, ad insertion, whatever.

(Let's not also forget the disaster that was Games For Windows Live)

<comment><USER21> Agreed, and it's still here; you can only get DX12 with Win10.

That hasn't kicked up as many waves yet because the tech has been slow to adopt.

<comment><USER22> Also because DX11 is still perfectly serviceable for most applications - <USER2> DX12 is considerably more complicated.

There are still new games being developed on top of DX9 today.

<comment><USER23> In any case, surely no game developer is going to make DX12 a hard requirement to run their PC games any time soon.

Even today, Steam's hardware and software survey puts DX12-capable hardware at around 70% of their users but nearly half of those aren't running on Win10. That's after a year of Microsoft literally giving it away and it being the default OS you get preinstalled on most new PCs in stores. The pattern of adoption hasn't been entirely surprising either: a fairly rapid shift over the first six months or so after 10 came out, but then a much slower shift since then.

It's going to be a long time before anyone running a modern GPU on Windows 7 can't run the latest PC games with decent results.

</comment></comment></comment></comment></comment><comment><USER24> Steam and games are the only reason I'm going to build a brand new VR capable Windows rig. Without that I don't really need Windows in my life.

</comment><comment><USER25> I'm confused, can't Steam just release as a free Universal App?

Also, with Steam's push towards Linux support this would be a dangerous strategy for Microsoft. Gaming is what drives a lot of people to Windows over other platforms. If Microsoft actively makes Steam unusable on Windows there's no reason to think people won't just seek out a better platform for Steam.

<comment><USER26> I don't think MS will allow a Univeral App that installs other Universal Apps. Just like Apple, they'll have a list of restrictions on what these apps can do. After all, a sandbox app that can arbitrarily install any other app is not very sandboxy.

<comment><USER27> There's nothing wrong with allowing one app to install another, but the key is, if you can't leave the sandbox, you request the OS do it for you. Android apps are sandboxed, and can install other apps, but you get an OS interstitial asking if you want to do it.

Similarly, a UWP app could conceivably be allowed to trigger the install of another UWP app, but it would pop-up a Windows box, not unlike a UAC elevation prompt, showing the app name, publisher if properly signed, and requesting the user permission to go forward with the install.

<comment><USER26> You make a good point, in the Android world you can manually install the Amazon Underground application and grant it the ability to install it's own apps. I don't believe there's a similar side-loading method on iOS, however: Apple has take steps to prevent this.

IMHO, I expect Microsoft to release a solution more like Apple's App Store and less like Google. Clearly, Epic Games' founder has the same concerns. He's also expressed concern with Microsoft only allowing something like Steam to be installed via side-loading, which he thinks provides a barrier to entry that is too high. I tend to agree, it's easy to slowly make side-loading more and more difficult as time goes on, or to make more and more critical APIs unavailable to non-UWP applications.

<comment><USER27> Steam is only available via sideloading now. You have to go to a website and download the installer and run it manually. This is how Windows has always worked. UWP will allow the same, but is simply a more secure application format which can't easily contain malware. The only difference is Microsoft now also offers an app store.

</comment></comment></comment></comment></comment><comment><USER27> Note that at the last Build conference, Microsoft made a specific point to demonstrate a UWP app with SteamWorks compatibility on stage. But, you know, clearly they're actively using UWP to kill Steam.

[http://www.develop-online.net/news/universal-windows- platfor...](http://www.develop-online.net/news/universal-windows-platform- adds-support-for-mods-and-steamworks/0218598)

I'm rate-limited, so to respond to the person who commented here:

"Embrace, Extend, Extinguish": You might notice if you read the linked Wikipedia article, this is from 1995. Also known as 20 years ago, when almost everyone involved has since retired. Or died. I was in elementary school when this strategy was used by Microsoft. The person who said the phrase in a meeting, Paul Maritz, left Microsoft 16 years ago. Babies born during that meeting are legal adults today.

<comment> ctrl-j Microsoft has been known to use Embrace-Extend-Extinguish as a strategy. So this means _nothing_.

[https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish](https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish)

<comment><USER28> The most recent examples on that page are nearly ten years old. I was a "Micro$oft" hater in school, too, but I don't see any other indication that they're relapsing apart from the accusations made in this news article -- certainly not any more than Google or Apple.

</comment></comment></comment><comment><USER29> _over the next five years, they will force-patch Windows 10 to make Steam progressively worse and more broken._

Linkedin lists Valve as having between 200 and 500 employees. Putting a team of engineers to work on removing the dependency on Windows32 seems like a reasonable alternative to a course of inaction dedicated to letting Steam full into suck.

My intuition is that Microsoft is even likely to work with a partial potential competitor like Valve when it comes to something like this because anyone who is using Steam on Windows...well they're using Windows and Microsoft has an substantial interest in not having Windows suck for the people who use it.

To me, this kinda' sounds like Valve announcing that it's not really going to spend any more money on evolving the Steam code base.

<comment><USER30> The non-Win32 apps are signed and distributed by MS through their own store. All apps delivered that way pay a toll to MAS. That's what Steam wishes to avoid, since they collect the toll right now.

<comment><USER29> Universal apps can be sideloaded. [1] There may be a market for a service that skins the process in an end user friendly way. That market is probably larger than just games. An analog might be Github over Git.

Whether Valve should invest in developing technologies to keep Steam relevant is a business decision. This appears to be announcement of Valve's intent. I would not be surprised if paying off the technical debt incurred by Steam does not meet the investment model of Valve's controlling interests. The Windows ecosystem is littered with technically obsolescent cash-cows: e.g. Laplink.

[1]:[https://msdn.microsoft.com/en- us/windows/uwp/packaging/packa...](https://msdn.microsoft.com/en- us/windows/uwp/packaging/packaging-uwp-apps#sideload-your-app-package)

<comment><USER12> Is sideloading of apps unrevocable?

<comment><USER29> Because Microsoft is primarily a B2B company and makes a lot of enterprise sales, I suspect that from a practical perspective removing it would require an impractically radical shift in its business model and sales channels.

Before Bring Your Own Device, there was bring your work home. Windows is to a meaningful degree a business class product sold to consumers. Removing sideloading from normal Windows would make Windows less attractive as a standard platform for enterprise if people cannot use line of business apps on any old device.

Of course, that doesn't make it irrevocable. But revocation seems unlikely to me.

</comment></comment></comment></comment></comment><comment><USER31> This is completely unfounded and tinfoil hat levels of conspiracy.

If they stripped Win32 out of Windows, it wouldn't only impact Steam, but Microsoft Office, Visual Studio, Photoshop Suite, Chrome/Firefox, iTunes, their shiny new Linux tools, etc would also be out.

This goes against the ethos of Microsoft. Criticise them all you wish, but they're absolutely obsessed with backwards compatibility and always have been. They know the ONLY reason Windows is popular is because you can throw in a piece of software you purchased in 1999 and it will "likely" still work. If they dropped Win32 entirely, then Windows is interchangeable with a Chromebook.

Heck up until 64x one of their test cases was if Doom (released in 1993) still ran. They only stopped because 64x doesn't support 16 bit.

<comment><USER32> "Project Centennial: Bringing Existing Desktop Applications to the Universal Windows Platform"

[https://channel9.msdn.com/Events/Build/2016/B829](https://channel9.msdn.com/Events/Build/2016/B829)

<comment><USER33> In that video they also say that sideloading can be done via double-click (no PowerShell cmdlets or whatever necessary like in Win8; not sure how certification/signing will play into this), and they also state that it'll be fine to monetize an UWP app on other stores than the Windows one. If they're actually honest with this and I haven't missed anything, UWP might well be the best thing that's ever happened to Windows.

<comment><USER32> I agree.

On top of that I really like that WinRT is basically COM+ Runtime reborn and that Visual C++ finally feels like C++ Builder for GUI RAD tooling.

And that .NET Native also got developed in the process.

</comment></comment></comment></comment><comment><USER34> > That's exactly what they did to their previous competitors in other areas.

Are we to take this to mean that Tim Sweeney is admitting that Steam uses undocumented Windows APIs? Because that's the only way Windows patches have broken existing software before.

</comment><comment><USER35> I rarely hear complaints about the closed-platform monopolies enjoyed by the App Store and Google Play, on their respective iOS/Android platforms. Can someone make a case for why a similar app-store monopoly on Windows is any worse?

<comment><USER36> Google technically does not have an app-store monopoly on Android. A sizable chunk of apps on my phone are from F-Droid.

Google just makes sure that most Androids have the Play Store, and then it's just the network effect: bigger audience -> more attractive to developers -> more apps -> more users.

<comment><USER37> > Google just makes sure that most Androids have the Play Store

I smell monopoly. They have powers to affect most of a market. Whether Google is abusing that power (thus, illegal), I'm not sure.

</comment></comment></comment><comment><USER38> It is hard to get through the speculation here. Does anyone have actual evidence that this is happening? (i.e. not some memo that one person wrote to some other person 20 years ago)

</comment><comment><USER39> Sorta like how the web gets progressively worse with each modal pop up ad.

<comment><USER36> Not quite. You can block ads, but you can't block broken APIs. ;)

</comment></comment><comment><USER40> Odd to see an article complaining about MS's "closed" ecosystem after all the work MS is doing to open source things, provide tight Linux integration, etc.

<comment><USER41> Microsoft has over 100 kiloemployees in a myriad of different business divisions. Not all of them do things the same way. I'm not sure there is _any_ corporation of that size that act completely coherent to the outside.

</comment></comment><comment><USER7> > Now they're doing it to Steam. It's only just starting to become visible.

{{citation}}

That is a bold fucking claim. Exactly how has this happened to Steam already? They don't bother to provide any reference or clue.

</comment><comment><USER42> Apparently Microsoft isn't allowed to evolve Windows with objectively better API's.

Have fun with your GetLastError, fifteen parameter functions, and poorly documented flags. But hey, at least it doesn't have much security, so I can download game mods from some unknown source that have full access to everything on my PC.

<comment><USER43> >> so I can download game mods from some unknown source that have full access to everything on my PC

I think that's more on you than the OS.

<comment><USER44> Rule 1 of software development should be: Never blame the user, when the situation could have been avoided through code.

Especially in this case. Isolation has been one of the main drivers of operating systems. Isolation between users, so they can't change each other's files etc. maliciously . Isolation between processes, so they don't accidentally corrupt each other. At least since the first computer virus in the wild in 1982 it should have been clear that software can also potentially be malicious and needs to be isolated from having the same rights as the user executing it.

The only reason why executing arbitrary x86 code in ring 3 is dangerous are the syscall interfaces the operating systems offer.

<comment><USER42> Which is why UWP has a capabilities-based sandbox.</comment></comment></comment></comment>


White House Raises Encryption Threat in Silicon Valley Summit - <AUTHOR> https://theintercept.com/2016/01/08/white-house-raises-encryption-threat-in-silicon-valley-summit/ <comment><USER2> It could be that I'm missing something totally obvious here but ...

Apart from the obvious reasons of why it's a bad idea to add backdoors or outlaw encryption the discussion somehow never addresses the obvious result of what were to happen if the US were to regulate / outlaw encryption: namely it would be devastating to any US tech companies who generate a large part of their income outside the US.

Would you still trust gmail/amazon or even US based ERP that is backdoored if you're a Asian or EU based company? Why is this not discussed I wonder.</comment>


Pause, We Can Go Back - <AUTHOR> http://www.nybooks.com/articles/2017/02/09/revenge-analog-pause-we-can-go-back/ <comment><USER2> I'm one of the people that this article (and book) romanticizing The Analog should appeal to but my overall experience with the digital revolution has been a net positive. This applies to both digital photography and digital music.

I had a collection of vinyl records & cassettes growing up but I've gotten more enjoyment and revelations from listening to Foobar software accessing thousands of flac/mp3 files instantly on demand. I can jump from pop to classical to jazz without the tediousness of manipulating analog media. Digital has allowed me to _appreciate music even more_.

The vast majority of articles of analog-vs-digital seem to favor analog and it downplays how digital can engage people in ways that analog can't replicate.

As an example, the first time I heard the Star Wars soundtrack was on a reel- to-reel tape machine.[1] Analog nostalgia. However, with digital technology, a skilled person with a computer workstation can use virtual instruments to recreate the orchestral arrangement one instrument at a time.[2] The listener can then hear the gradual build up of how all the various parts interact and _appreciate the music even more_ than the old analog tape. That demonstration is not economically possible with analog. Sure, one could make a 24-track analog tape of isolated parts but typical listeners will not have the money to own a 24-track player at home. Also, David Das in the video is experimenting with various combinations of articulations, tempo, and volume and that combinatorial explosion exceeds the capacity of 24 tracks.

[1] [https://www.google.com/search?q=star+wars+soundtrack+reel+re...](https://www.google.com/search?q=star+wars+soundtrack+reel+reel+4+track&source=lnms&tbm=isch)

[2] deep link showing adding an instrument and then a playback payoff: [https://www.youtube.com/watch?v=fYfbm3qHRLI&feature=youtu.be...](https://www.youtube.com/watch?v=fYfbm3qHRLI&feature=youtu.be&t=23m51s)

<comment><USER3> > I can jump from pop to classical to jazz without the tediousness of > manipulating analog media.

I think you are ignoring the fact that for some people, the manipulation of the analog media is part of the joy. Whenever something new overtakes something old, that's going to happen. I'm excited about self-driving cars relieving me from having to drive while other people are still buying manual transmission cars because they love the direct manipulation of the machine. When I want a cup of tea, I dump hot water over a tea bag while other people go through an elaborate ritual.

I don't have a record player, but I do have fond memories of sitting in my room with headphones on while a record played, looking at the large format cover art and studying the sleeve. I'm not a collector of anything, but I think I understand the joy of artifacts.

One thing I am somewhat surprised is that the streaming music services haven't borrowed the idea of filters from Instagram to apply to music. Would anybody be interested in simulating playback through a tube amp? Through a suitcase record player? Through a high quality turntable? Or a low quality turntable that can't quite turn at 33-1/3 RPMs?

<comment><USER2> _> I think you are ignoring the fact that for some people, the manipulation of the analog media is part of the joy._

No, I'm not ignoring that aspect and I understand that physical touch of media can add enjoyment for some people.

What I disagree with is the constant biased narrative from writers that _emphasizes_ analog media's attributes. That perspective presents a one-sided view favoring analog such as:

1) physical media you can touch is better than digital bits you can't touch

2) ownership is better than subscription (Spotify streaming)

3) listening in 20-minute side of 1 album is better than instantly jumping around a large music library

... ergo, analog is overall better than digital consumption. (As I stated before, I disagree as a person who straddles both the vinyl and digital eras. I've had extensive experience with both formats and the digital experience is better in my case. Many people besides me have come to this same conclusion.)

Yes, holding in your hand a vinyl album's cover art and reading its lyrics can add joy to music but there's also the _opposite_ view that seems uncool to write about: there's also joy in _not handling_ physical media. It's this second perspective I'm emphasizing and it doesn't take away from anyone who prefers their vinyl records.

<comment><USER4> You're overlooking the fact that we've already been here before and experienced the rush to digital as a world of perfect reproducibility and consistency without all the inconveniences of analog.

Digital is better if your priority is the things that are more easy with digital. If you ask me to mix your movie soundtrack, I'll head straight for the digital desk hooked up to the Pro Tools rig and it's be plugins for breakfast, lunch and dinner. If you invite me to jam for musical pleasure, I'll switch on the 303 that I have wired into a shitty desk that I bought _because_ it sounds so shitty and I enjoy the way it crunches a hot signal.

Multitracking, refining, polishing, can be enjoyable and deliver a sense of accomplishment when you deliver the end product, but it's work. The music I make and listen to for pleasure is typically done with cheaper, crappier gear, pushed beyond its design parameters, and recorded in one pass. I suppose you could cal it a techno-punk aesthetic; when you have sequencers and editing tools at your fingertips, the personal aspects are best expressed (for me) through performance rather than through perfection.

<comment><USER5> not sure these things are excluding each other.

<comment><USER4> Of course not, but for years there's been a 'digital can do anything analog can do so why even use analog' from the digital side of music engineering. To which I answer, because I don't _want_ to have perfect consistency and predictability in every context. There are contexts in which I _want_ imprecision, nonlinearity, and surprise so that I can _select_ rather than _design_.

I'm not sure how to articulate this, but it's a general problem in our technology culture. To me this is not that different from not wanting to write code all the time. You know what I hate about writing code? When I'm working with unfamiliar languages/frameworks/libraries I don't know what all the available options are, whereas when I'm working with more visual tools I can see all the options even if I don't understand what they do, and I can select and experiment and, well, _play_ with the options until I find something useful or interesting. I can't play when I'm writing code because my experiments are just liable to result in syntax errors or suchlike.

Writing code appeals to people who like learning a bunch of things first and then recombining them. I find this kind of learning slow and tedious and I keep wonder why I'm doing all this syntax bullshit instead of letting the computer handle it for me so I can focus on my domain-specific ideas.

Likewise when I talk with DSP programmers about how I like the unpredictability and nonlinearities of analog signals, they say things like 'I could add a random noise generator to the oscillator algorithm' or so (I'm simplifying, but that's a design reality on many electronic musical instruments). This is often a self-defeatinmg strategy, at least in the short term - witness Roland corporation bending over backwards to do The! Most! Accurate! Component! simulation! Ever! in a recent line of digital devices featuring 'analog circuit behavior'. Meanwhile their smaller rival Korg has completely crushed them in the very important entry and mid-level market segments by simply producing what the market wanted - a wide variety of cheap analog gear, mixing both classic and new designs, and labeling the boards and publishing the schematics so people can mod them if they're handy with a soldering iron.

</comment></comment></comment></comment></comment></comment><comment><USER6> > What if Picasso had had Snapchat? What if Hemingway had spent half the > afternoon writing Yelp reviews of his favorite bars?

Is the author suggesting that great art and writing can no longer happen, because of Snapchat and Yelp? Because I'd argue that we've never lived in a time when it's been easier to create art, of all kinds, and there doesn't seem to be any shortage of great literature being published, either.

I find this endless bemoaning of the unrealness of "digital" quite tiresome.

<comment><USER7> Hemingway could have, if he wanted to, spent half the afternoon writing reviews of his favorite bars. You don't need Yelp for that. Just like Picasso could have spent his time taking pictures of food or whatever the author imagines people do with Snapchat.

This all seems more like an excuse. "I could be Hemingway if only that dastardly Yelp weren't distracting me all the time!". Yelp isn't the one to blame here.

<comment><USER8> Also, both Picasso and Hemingway spent lots of time socializing, especially with other artists. At the most distilled level, that's what people use all this new-fangled technology for.

<comment><USER9> Did you read the article? The author addresses and counters this notion that digital socializing brings us together.

See, you've put all of your spiritual and ethical eggs in to your technologic worship so you are completely closed off to the notion that smartphones might actually be really horrible. You're basically just defending your own thinly veiled insecurities about how you give your own life meaning.

<comment><USER8> Woah, calm down - I was just expanding on the single comment I replied to.

I'm an old fogey who isn't young or cool enough to have all my eggs in that basket. My eggs are far more in the sitting-around-reading-books-and- newspapers and hiking-in-the-mountains baskets.

But I do think this hysteria is pretty overblown, as your comment demonstrates.

</comment></comment></comment></comment></comment><comment><USER10> I love my omni-devices a lot, but there is an anti-social angle to it that I wish I could get over.

Nobody knows what you're doing on your iPad. You could be reading your e-mails, scrolling through twitter, or buying something on Amazon. But in a more casual environment (living room, with friends), you lose opportunities for spontaneous interactions.

There's also a difficulty in sharing. You can't give the funny pages to someone. Hard to loan e-books sometimes.

I think some of this is solved by TV screens. Long term, I bet we'll be "casting" our phones to screens a lot more often in social environments.

But sometimes the limitation of physical goods is nice. Legos are funner than CAD software, most of the time.

<comment><USER11> For this same reason modern cinematography often resorts to older tech or no tech. Dialling someone's number on the mobile is not as dramatic as doing it on older bulkier phones. Scrolling something on the iPad is not the same as paging a real book. Then there's writing a real letter, not knowing someone's whereabouts as opposed to just calling their mobile, etc. etc.

Tech _is_ social in its own way but it seems to be bringing these massive anthropological changes. It will be interesting to see whether the come back of physical tech like vinyl is serious or it's just some of kind of a protest of the older generation.

<comment><USER10> Tech has ruined many classic ways of storytelling in cinema

Nobody prints giant newspaper headlines anymore. Nobody holds a map upside- down.

My bet is many more movies will be based in the 80s.

</comment></comment></comment><comment><USER12> > Last year, in fact, the OECD reported that "students who use computers very > frequently at school do a lot worse in most learning outcomes."

There's no universe where having less information available to students improves learning.

Wikipedia for everyone is revolutionary! I doubt an OECD test can capture that.

The problem OLPC faced is that the iPod touch was a more compelling device for children. Its bill of materials today is less than $100. And children use touch devices religiously. OLPC had no hope of delivering a competitor to iPhone on technological and business grounds. But the theory is probably sound.

<comment><USER13> _There 's no universe where having less information available to students improves learning._

I think that's an oversimplification.

I highly recommend _The Shallows_ by Nicholas Carr. A quicker read is the article that inspired the book: Is Google Making Us Stupid?[0]

He's not blindly or rapidly anti-tech. For example, he says: _" The Web has been a godsend to me as a writer. Research that once required days in the stacks or periodical rooms of libraries can now be done in minutes."_

But he does recognize that there are drawbacks to how we engage with digital media: _" When we read online, she says, we tend to become "mere decoders of information." Our ability to interpret text, to make the rich mental connections that form when we read deeply and without distraction, remains largely disengaged._"

[0] [http://www.theatlantic.com/magazine/archive/2008/07/is- googl...](http://www.theatlantic.com/magazine/archive/2008/07/is-google- making-us-stupid/306868/)

<comment><USER14> I have read novels since before the internet. I'm more likely to interpret and make connections about an article I discuss on HN than I am for any book I read (which I consume like popcorn).

</comment></comment></comment><comment><USER15> This is a good time to sell your records. The heavy marketing of kitsch to millennials has driven the price up on anything redolent of "authenticity." I got $3K for mine. Started by only mostly taking the ones I thought were nice, but then noticed how much they were paying for the ones that were crap I paid 25 cents for at a Salvation Army. The rest of them followed shortly.

</comment><comment><USER16> Just walked along the beach and saw an elderly couple sit on a bench, talking. Neither of them held a smartphone. Perhaps they don't even own one. It struck me that short of a revolution in this area, the number of times I'll do that with my wife will be easily counted. Obviously I wasn't like this 10 years ago. Conversation has become too slow and unrewarding for me to even engage in. Hell, even my favorite tv sports or a good movie is too slow and has too little instant reward to not use Twitter at the same time.

I think a holiday island that banned all mobile broadband could actually use it as a selling point.

<comment><USER17> I just spent four weeks in Cuba, where the only Internet is (expensive, slow) public wifi hotspots in extremely select places, and I had zero cell service either as my carrier had no roaming agreement.

I got quite a bit of exploratory programming done, and read a lot of books (and explored Cuba itself of course! Made half a dozen friends, amazingly friendly people)

<comment><USER16> It has to be zero though, not "sparse" or "slow" as that just means I'll not see Cuba but instead see the inside of that lobby with WiFi :) That's how bad thus illness is.

Unfortunately I think before I get a change to go the island will be blanketed in 4G (fortunately for them though... I think).

</comment></comment></comment><comment><USER18> Just noticed yesterday that vinyl records started being sold in my local supermarket, alongside a disappearing variety of CD/DVD/Blu-Ray discs. What an interesting twist of history.

<comment><USER19> Exception sells and the past is quite rare these days.

</comment></comment><comment><USER20> Reading this article about escaping from oppressive technology, when the page turns off my music in order to try, and fail, to play an ad.

<comment><USER21> haha but adblock got the rest of us covered

<comment><USER20> Does this work on mobile?

</comment></comment></comment><comment><USER12> > The reason [for board games' popularity], Sax suggests, has only a little to > do with the games themselves, and more with the desire to do something with > other people

Sort of. One of the most important features of board games is that they're comfortable to play while drinking. Sax's example of Snakes and Lattes, after all, is actually a bar.

The digital gives us an alternative to typical entertainment, food, drugs and alcohol.

</comment><comment><USER22> The strange thing is seeing record players for vinyl that output to a USB port. Or even Bluetooth. Huh?

</comment><comment><USER23> I'll play the Bourdieu card and simply say that it's all about the symbolic gains you get in your tribe by possessing those artefacts. Nothing new under the sun (I combo the Ecclesiastes card).

</comment><comment><USER24> More tedious nostalgia for the glorious "time before phones",this time with vinyl as a pretentious garnish. Can we please stop thinking this idea is new or interesting?

<comment><USER25> Perhaps a more interesting question then is _why does this tedious nostalgia persist?_ If our new tools are not providing for our needs then we should change them to do so.

<comment><USER26> There are a few cases where we really are giving things up in the digital world. I've yet to see a digital control that holds a candle to the good old analog volume knob in terms of speed and precision of setting, for example. E-books are better than paper ones in many ways, but paper still has the advantage for sharing and certain aspects of navigation.

On the other hand, one big "need" is simply for the familiar, and another is to be different from the crowd. Old timers will hold onto their vinyl because it brings back memories that cannot be replaced, while young hipsters will buy them because no one else their age is. Simply being modern prevents new audio technology from fulfilling either need.</comment></comment></comment>


Node.js - A giant step backwards? - <AUTHOR> http://fennb.com/nodejs-a-giant-step-backwards <comment><USER2> Allow me to be a little grumpy:

I hate tabloidy headlines with question marks. As in "Queen Elizabeth: Is She a Transvestite?", "The Moon: Is It Made of Cheese?" or "Linkbait: Will It Ever End?".

<comment><USER3> <http://en.wikipedia.org/wiki/Betteridges_Law_of_Headlines>

<comment><USER4> Well sourced. Thank you.

</comment></comment></comment><comment><USER5> The big reason callback-based systems are hard (despite the fact that built-in flow control constructs need to be re-implemented) is that functions are no longer composable. That is, if I write a bunch of code that doesn't need to do any I/O, I'll just return a value to the caller. If at any point in the future the spec changes and _any_ function in this call stack needs to do any I/O, all the code that ends up calling this function needs to be refactored to use callbacks.

There really should be language support for this sort of thing (like coroutines) so these sort of cascading changes don't need to happen.

<comment><USER6> There are ways to compose functions, like the deferrable pattern. They just all kind of suck and are poor replacements for having a stack.

I'm all for using coroutines to solve this problem. That's the approach taken by my Celluloid::IO library:

<https://github.com/tarcieri/celluloid-io>

Unfortunately Ryan Dahl is adamantly opposed to coroutines so that's not going to happen in Node any time soon.

<comment><USER5> Deferreds make your code nicer, but they still don't magically make your code composable.

What would make Node more attractive is if it supported copy-on-write multithreading and gave me a way to cheat and use asynchronous I/O (like a wait(myFunctionThatTakesACallbackOrDeferred) function)

<comment><USER6> There are many ways to compose deferrables, primarily by grouping several of them together into something which is also a deferrable. See the em-scenario gem for examples:

<https://github.com/athoune/em-scenario>

Note: I still think this approach sucks.

V8 provides a really awesome shared-nothing multithreading scheme via web workers. It's just nobody uses them.

<comment><USER5> Oh right that's definitely true and is much more elegant. I was talking about when a function written in synchronous style (in a long stack of synchronous calls) needs to call something asynchronous.

</comment></comment></comment></comment></comment><comment><USER7> In my experience, node.js is a terrible choice for most web applications. If you really need real-time, sure, go for it. But if you're interested in node as an alternative to rails/sinatra/django/flask, then stay away from it. The cool stuff you get for free like coffeescript/jade/stylus can also work with the ruby and python frameworks.

Node sucks for general web apps because you have to program everything asynchronously. This is a major step backwards, and quite frankly it feels to me like trying to program in assembly. It's not expressive at all. You have to write your program in some pseudo code, then translate that to async code. And what for? What's the advantage you'll get? scalability? Who says you will need it? This is exactly where you should remember that premature optimization is the root of all evil.

<comment><USER8> > Node sucks for general web apps because you have to program everything > asynchronously.

To be fair, the exact problem is not async itself, but forcing CPS (continuation-passing style) for serial routines. For example, gevent and eventlet use greenlets (coroutines for Python) to avoid unnecessary callbacks in serial routines.

<comment><USER9> I'm curious -- how would the author's example look using greenlets?

</comment></comment></comment><comment><USER10> This is really old - discussion from 6 months ago: <http://news.ycombinator.com/item?id=2848239>

Basically, async I/O gives you more options than "block the whole world while you go read this stuff", and that means that old idioms aren't effective.

You gain more control: can choose when to block, when to limit concurrency and when to just launch a bunch of tasks at the same time. At the same time, you need to adopt a few new patterns, since you can't/don't feel right blocking execution every time you use an external data source. It's definitely a tradeoff and not a magic bullet.

For my longer take on this, see <http://book.mixu.net/ch7.html>

<comment><USER6> You don't get to choose when to block. Blocking becomes an error which hangs the event loop. The only option for blocking calls is to use a thread pool that sends events back to the event loop when a thread finishes running.

<comment><USER10> You're right, I should've said "emulate blocking by checking that all of the tasks we queued have completed upon finishing a task before proceeding while allowing the event loop to run" instead of "blocking". It's not really blocking the event loop, only a controlling the flow of a particular path of execution. Only a few native API's provide synchronous versions that will block the entire process until they complete - like the filesystem API's fs.readFileSync.

</comment></comment></comment><comment><USER11> While I agree that event programming is very different, some of the issues the author brings up can be dealt with by architecting a program for an event based system. I understand that, is the authors gripe. That it is sometimes hard for someone coming from a non event control flow background to adapt at first. But items like the loop example are examples of mixing half control flow and half event based programming. What should be done in that situation is that it should not be returning a list, it should be returning a promise that will get called on completion of the list. Or a more elegant solution would be to notify listeners when a new item of the list is parsed so that they can observe it and see if it is an item that they are interested in. I understand the authors frustration, but it appears to me, that some more articles on best practices would help bring clarity on how to deal with these form of patterns.

</comment><comment><USER12> I hope this isn't too pedantic, but I wish the author would stay away from calling Node "concurrent". The whole point of Node is that it's asynchronous but not concurrent: there is a single thread of execution for your whole program, which is what lets you ignore locking, etc.

In fact, when you program for Node it's really important to keep this in mind, since (contrary to another statement from the article) not all libraries are asynchronous. If you select a synchronous db driver or write a long-running loop, it will block the rest of your program.

In general, though, I thought it was a good piece. I'm sure many heads have exploded on first introduction to node (and JS in general).

<comment><USER6> You're confusing concurrency and parallelism. Concurrency describes having several tasks or operations that contend on resources or events. They may or may not execute in parallel, and certainly don't in Node. In contrast, Netty provides a thread pool for executing events and thus provides concurrency and parallelism.

<comment><USER13> As far as I know, by definition (coming from someone with a predominately Java background) concurrency requires multi-core processors, or, for example, a distributed application with at least 2 nodes that communicate with the same central server / "hub" (which would still require a multi-core processor, as far as I know, on the server). The central tenet mentioned with concurrency is often that of "race conditions" where it cannot be predicted which thread or node will access a resource first. If a task isn't executed in parallel, such as it has to wait for the other to finish before it starts / proceeds, I don't see how it could cause a race condition. Admittedly though, I don't have deep knowledge of how high level code translates to actual CPU instructions so it could be possible, or even likely, that if the processor is switching between tasks in such a way that each line of code, so to speak, that is run is from a different method that concurrency issues would occur even on a single-core processor. A language like Java has robust and mature aspects of the language to deal with this so I would be wary of using something like node.Js if this wasn't well documented. Concurrency issues are nasty and I have seen firsthand the mayhem they can cause in legacy applications I've worked on.

<comment><USER14> Concurrency doesn't require multi-core. Parallelism requires multi-core.

</comment></comment></comment></comment><comment><USER15> This guy doesn't know much about javascript, I am guessing. I made some gists that take his code and add minimal changes to it, that fix the problems he complains about:

"Two different code paths, can't do DRY" really? <https://gist.github.com/1678395>

"Oh noo, I can't return the results because they are async". That's what callbacks are for. You know what you CAN do? Do I/O in parallel that's what! Node makes it easy. <https://gist.github.com/1678415>

Anyway I hope this illustrates the point. The guy says it exactly right in one place: "Once you get your head around thinking in async terms, node.js starts to actually make a lot of sense." And therefore it is not a giant step backwards.

There are more elegant ways to write this (see <http://qbix.com/plugins/Q/js/Q.js>) but these are just minimal changes to his own code.

</comment><comment><USER16> I tend to agree with the post, but I find the one-language-to-rule-them-all thing too compelling to fret too much over asynchronicity. Although it'd probably lead to lots of synchronous code, it would be nice for it to to be easier in nodejs to be synchronous sometimes and asynchronous sometims.

I would refactor the code to something like (still not as simple as synchronous):

        asynchronousCache.get("id:3244", function(err, myThing) {
          var useResult = function(err,_myThing){
              // We now have a thing from DB, do something with result
              // ...
          }

          if (myThing)
             useResult(null, myThing);
          else
             asynchronousDB.query("SELECT * from something WHERE id = 3244",useResult);

</comment><comment><USER17> The problem is that the author simply didn't notice the refactoring and abstraction opportunities available. (One question to ask yourself: "How do I test this?" If you can't answer that question, the code is wrong.)

We'll start with the synchronous example:

        myThing = synchronousCache.get("id:3244");
        if (myThing == null) {
          myThing = synchronousDB.query("SELECT * from something WHERE id = 3244");
        }

This is verbose and tedious. We should really make the API look like:

        myThing = database.lookup({'id':3244}, {'cache':cache_object});

Let's apply this idea to his asynchronous example. We want the code to look like:

        database.lookup({'id':3244}, {'cache':cache_object}, function(myThing) {
            // whatever
        });

So instead of writing this:

        asynchronousCache.get("id:3244", function(err, myThing) {
          if (myThing == null) {
            asynchronousDB.query("SELECT * from something WHERE id = 3244", function(err, myThing) {
              // We now have a thing from DB, do something with result
              // ...
            });

          } else {
            // We have a thing from cache, do something with result
            // ...
          }
        });

We need to refactor this. Remember, node.js is a continuation-passing-style language. So let's set a convention and say that every function takes two continuations (success and error).

Then, to compose two functions of one argument:

       function f(x, result, error)
       function g(x, result, error)

To:

       h = f o g

You write:

       function compose(f, g){
           return function(x, result, error){
               g(x, function(x_){ f(x_, result, error) }, error);
           }
       }

(Data flows right-to-left over composition, so "do x, then do y" is written: "do y" o "do x".)

Now we can cleanly write a complex program from simple parts. We'll start by creating a result type:

        result = { 'id': null, 'value': null, 'not_found': null }

Then, we'll implement cache functions that take keys (as results of this type) and return values (as results of this type). Looking up an entry in cache looks like:

        cache.lookup = function(key, result, error){
            new_key = key.copy();
            cache.raw_cache.lookup(key.id, function(value){
                new_key.result = value;
                new_key.not_found = false;
                result(new_key)
            },
            function(error_type, error_msg){
                if(error_type == ENOENT){
                    new_key.not_found = true;
                    result(new_key)
                }
                else {
                    error(error_type, error_msg);
                }
            });
        };

Looking up an entry in the database looks about the same. The key feature is that the "return value" and the "input" are of the same type. That makes composing, in the case of "try various abstract storage layer lookups in a fixed order", very easy. (Yes, the example is contrived.)

        dbapi.lookup = function(key, result, error){ ... };

Now we can very easily implement the logic, "look up a value in the cache, if it's not there, look it up in the database":

        cached_lookup = compose(dbapi.lookup, cache.lookup);
        cached_lookup(1234, do_next_step, handle_error);

You can, of course, generalize compose to something like:

        my_program = do([cache.lookup, dbapi.lookup, print_result]);

Writing clean and maintainable code in node.js is the same as writing it in any other language. You need to design your program correctly, and rewrite the parts that aren't designed correctly when you realize that your code is becoming messy.

Continuation-passing style is pretty weird, but you do get some benefits over the alternatives. Writing a program with coroutines involves deferring to the scheduler coroutine every so often, littering your code with meaningless lines like "yield();". Using "real" threads is even worse; your code looks like single-threaded code, but different parts of your program are running concurrently. (Did you share any non-thread-safe data structures, like Java's date formatter? Hope not, because you won't know you did until the production code dies at 3am.) Continuation-passing style lets you "pretend" that you are executing multiple threads concurrently, but the structure of the code ensures that only one codepath is running at a time. This means that libraries that don't do IO don't have to be thread safe, since only one "thread" runs at a time.

All concurrency models involve trade-offs over other concurrency models. But when comparing them, make sure you're comparing the actual trade-offs, not your programming ability with each model.

<comment><USER18> I think you've actually demonstrated how something that would be really simple in python, gets horribly complicated in javascript. Or maybe it's just me...

<comment><USER17> If you use a continuation passing style in Python, then the code looks about the same. Most Python programmers use threads (and let the GIL give them a bit more thread safety than C++ and Java programmers get) or Twisted (with Deferreds).

I think you'll write better JavaScript if you know Python because Python encourages you to use named functions instead of lambdas. JavaScript fanbois get very excited about anonymous functions and overuse them; Python doesn't let you use anonymous functions for anything useful, so you tend to name things. (object.method is also nice syntax for working with callbacks.)

Anyway, Python and Node feel about the same to me, except for the fact that Python has nicer syntax.

</comment></comment></comment><comment><USER19> Transforming functional or imperative code into continuation-passing style isn't that big a deal. If javascript weren't such a pain in the ass just to parse, there would probably be tools to do that. Maybe coffeescript will do it, but this is why macro-extensible languages are a big win—I'd have the right hooks to easily do it myself rather than waiting for the implementors to officially update the language (or get elbow deep in their internals and hope they accept a huge patch).

<comment><USER20> There's already a branch of CoffeeScript, called Iced CoffeeScript (<http://maxtaco.github.com/coffee-script/>), that does this. The example in the post would look like:

      for blogPostId in recentBlogPostIds
        await asynchronousDB.getBlogPostById blogPostId, defer(err, post)
        templating.render post

Though you still can't simply return the result — you'd have to use a continuation — but it does make it simple enough to use CPS in general.

</comment></comment><comment><USER21> To make things easier, you can use node-fibers (<https://github.com/laverdet/node-fibers>) to structure your asynchronous code with coroutines or, if you are feeling less adventurous, async (<https://github.com/caolan/async>) is an excellent helper library for common asynchronous code patterns and it works on the client-side as well.

</comment><comment><USER22> This callback programming is the reason i quit node.js. It is easy to get something up and running, but then it feels like i never get out of the chaos i created.

This whole thing additional to the whole mess JavaScript is? I never liked it to begin with, but there is no real alternative until Dart is ready. Every time something comes out for JavaScript it adds another abstraction and chaos in my opinion. jQery for example, really impressive to begin with, but when you see what a horrible mess you can create with it...

There is a reason why big companies never adopt these things, i can't imagine how it would be to take over a node.js app from someone else.

Now you can argue that this takes practice. Crockford may write JS from heaven, but i don't want to invest my time in this language. These inconsistencies are not fun to deal with and when Dart is here, companies will drop it very fast.

I am now stuck with Scala, it is the complete opposite. It is complicated to get in, but when you get it, you have a gigantic toolbox to solve every problem the way you want. For web programming i recommend Lift, but when you want to get in fast and a fan of async try Play2.0. Node.js made async popular, it should get credit for that.

<comment><USER23> > There is a reason why big companies never adopt these things, i can't > imagine how it would be to take over a node.js app from someone else.

That's incredibly inaccurate. Big companies adopt a lot of crazy things, craziness isn't much of a deciding factor. Node.js is used by plenty of large companies and despite your tastes, Javascript in general is ridiculously popular in companies of all sizes.

<comment><USER22> References please, clientside doesn't count. Google forbid it and i don't know of any big company how has SSJS in production. It's definitively not ridiculously popular.

<comment><USER24> Apparently Walmart also uses it for mobile: [http://venturebeat.com/2012/01/24/why-walmart-is-using- node-...](http://venturebeat.com/2012/01/24/why-walmart-is-using-node-js/)

</comment></comment></comment></comment><comment><USER25> Use recursion. Fixed:

      asynchronousCache.get("id:3244", function doThing(err, myThing) {
        if (myThing === null) {
          asynchronousDB.query("SELECT * from something WHERE id = 3244", function(err, myThing) {
      		// We now have a thing from DB, do something with result
      		doThing(err, myThing);
          });

          return;
        } else if(err !== null) {
      	// Handle error.
      	return;
        }

      // We have a thing.
      });

<comment><USER16> Were you implying that your solution was simpler?

</comment></comment><comment><USER26> Tame JS (tamejs.org) makes asynchronous code in node.js very very easy.

<comment><USER27> Thank you!

</comment></comment><comment><USER28> I thought that this was going to be a node.js bashing.

What a let down.

</comment><comment><USER29> The problem is, Javascript continuation syntax is ugly and verbose. All the nested indentation fails to map to our human sensibilities about what the code is actually designed to do.

Someone needs to fix this

</comment><comment><USER30> I am not convinced with the blog post example. If ordering and null entries really matter, then you must put appropriate instructions to handle them. Ordering can be tackled by adding the blogPostId to each entry, and sorting the resulting collection with this key (assuming that you don't pick up a million+ posts).

I advocate polyglot programming, and using node.js for tasks other than what its designed for (server side async programming) might result in unfavorable results.

iPods are not lousy because one can't text with them.

</comment><comment><USER31> My take on this post is that the author was calling Node a giant leap backwards because he believed all code should have the look and feel of Python.

But now, he's not so sure.

Did I miss anything?

ETA: I understand that coding for Node looks and feels weird, but so does coding for Lisp, Smalltalk, Haskell and a long list of other programming languages.

<comment><USER32> The problem is that the problems Node solves, can be solved better and more cleanly than a spaghetti code of callbacks, with coroutines for example. It's just that Node and javascript are not up to the task.

Now, the thing Node has going for it, is that, despite being inferior than other similar technologies, it has a big following (community matters), lots of libs (libs matter), and it's based on an easy and familiar language to many.

</comment></comment><comment><USER33> I kinda like the em-synchrony for Ruby. It handles the callbacks with fibers, so my actual code doesn't have the callback hell of Javascript. Although the implementation of Ruby fibers is not-so-nice at this point. I hope they'll fix it in the next versions.

<comment><USER6> em-synchrony's problem is it has people wrap asynchronous libraries one-at-a- time. There's a few problems with that:

You're exposing a synchronous API, but still can't take advantage of the huge ecosystem of Ruby libraries that already expose synchronous APIs.

Wrapping libraries becomes a one-off chore. Each individual library must be wrapped to work in an em-synchrony system, and if the libraries aren't both asynchronous and wrapped in fibers you can't use them. This not only shrinks the ecosystem of libraries further, but is also more error-prone than providing a general coroutine abstraction around socket IO.

Providing a generalized abstraction for doing synchronous I/O with sockets/fibers and an evented backend is exactly what I'm working on in Celluloid::IO:

<https://github.com/tarcieri/celluloid-io>

<comment><USER33> This is a very interesting project. I'll have to dig deeper into it soon.

</comment></comment></comment><comment><USER14> Aync codes like threaded codes are different from the simple sync code. These different style coding are there to take advantage of the concurrent benefit of the system. Developers with simple single flow control code background often complain about the extra flow control complexity when it's outside of their comfort zone. Think of it as a level up on your skill.

There are libraries out there that add syntactic sugar to make async code look like sync code. Like,

        group (
            asyncfunc1()
            asyncfunc2()
            asyncfunc3()
        )

<comment><USER34> I think my biggest gripe is that these things are only possible by using one of the many libraries or rolling your own solution. The rather disorganized state of the node.js libraries is far too confusing for most of us who don't do Node 24x7.

<comment><USER35> Agreed. The solution needs to be part of the language, or at least node itself, not a 3rd party library (or 10)

</comment></comment></comment><comment><USER36> It takes some work to get used to the change in flow control, but it seems to be worthwhile (at least it has been so far for my project). Coming from a real time/embedded background seems to have helped me because typical those systems are heavily event based. I don't know if node.js will change the world but I think it's worth at least playing with just to get some experience with the programming model.

</comment><comment><USER37>
        getPosts (ids, cb) ->
            res = []
            stash = (err, post) ->
              res.push post
              cb(res) if res.length is ids.length
            db.getPostById(id, stash) for id in ids

        getPosts [...], (posts) ->
            # go on...

use `res[i] = post` if there is some implicit ordering.

</comment><comment><USER38> Declaring node a 'giant' step backwards is a stretch. Callback spaghetti isn't the problem it set out to solve. It is meant to provide easy(-er?) concurrency. If you measure it against its goals, I think it's pretty good.

</comment><comment><USER39> I wrote a module based on fibers to help with these sort of problems. Take a look at <https://github.com/scriby/asyncblock>

</comment><comment><USER40> This is a rather sensational article. The author's first example is pretty easily solved:

      getFromCache = function (id, callback) {
        asynchronousCache.get(['id', id].join(':'), function(err, myThing) {
          if (myThing == null) {
            asynchronousDB.query("SELECT * from something WHERE id = $id", {id:id}, function(err, myThing) {
              callback(myThing);
            });
          }
          else {
            callback(myThing);
          }
        });
      };

      getFromCache(3222, function (myThing) {
        console.log('myThing:', myThing);
      });

<comment><USER40> Or if you want more re-usability:

      getFromCache = function (id, query, callback) {
        asynchronousCache.get(['id', id].join(':'), function(err, myThing) {
          if (myThing == null) {
            asynchronousDB.query(query, function(err, myThing) {
              callback(myThing);
            });
          }
          else {
            callback(myThing);
          }
        });
      };

      getFromCacheSomething = function (id, callback) {
        var query = buildQuery("SELECT * from something WHERE id = $id", {id:id});
        getFromCache(id, query, callback);
      }

      getFromCacheSomething(3222, function (myThing) {
        console.log('myThing:', myThing);
      });

<comment><USER41> Don't forget to bubble errors up the callback chain along with return values (I always forget that too):

        getFromCache = function (id, query, callback) {
          asynchronousCache.get(['id', id].join(':'), function(err, myThing) {
            if (myThing == null) {
              asynchronousDB.query(query, function(err, myThing) {
                callback(err, myThing);
              });
            }
            else {
              callback(err, myThing);
            }
          });
        };

</comment></comment></comment><comment><USER42> I rarely use ifs and whiles using javascript.. There are better, higher level libraries that take care of it for you. As a bonus, some of them let you make it * paralleled* with the same syntax. Obviously, when you switch to a new language, you need to learn their new paradigms / designs.

<comment><USER43> > As a bonus, some of them let you make it * paralleled* with the same syntax.

JavaScript is single-threaded, so parallelism within a single JS VM is not possible.

<comment><USER42> Hence the * _</comment></comment></comment>


Ask HN: iOS program to capture notes? - <AUTHOR> I use OneNote as my commonplace book, but I want a separate application that can capture my thoughts quickly.
I am using Google Keep, but going from notes to pure text is cumbersome (especially when you are doing this multiple times a day). I move all tasks to org-mode as well.
What is a good alternative to Google Keep? <comment><USER2> For quick capture, I think Drafts could work for you. It is built on the idea of quickly writing things down and then (possibly later) sending them to somewhere else.

[http://agiletortoise.com/drafts/](http://agiletortoise.com/drafts/)

<comment><USER3> I came here to recommend this exact thing. There is also simplenote, if you have cross-platform worries or don't want to spend the money--but Drafts absolutely is worth it. It's the perfect replacement for a pocket notebook-- write down whatever; contact info, url, quote--send it to contacts, read it later service, notes application. The tutorial videos on the site are a great showcase.</comment></comment>


Did Philip K. Dick disclose the real Matrix in 1977? - <AUTHOR> http://www.youtube.com/watch?v=jXeVgEs4sOo

<comment><USER2> That's what I've been trying to say since tomorrow.

</comment><comment><USER3> now khoury discloses the video that discloses the real Matrix in 1977 3 years after the video was uploaded</comment>