A MapReduce Algorithm for Matrix Multiplication - <AUTHOR> http://homepage.mac.com/j.norstad/matrix-multiply/index.html

<comment><USER2> The author's name and academic affiliation looked familiar; it turns out he's the same John Norstad who wrote Disinfectant, a freeware Mac anti-virus program that was a staple of all of my school's computers up to its retirement in 1998. It's good to see he's still up to some serious coding.

My favorite part of Disinfectant was the Easter Egg embedded in its about box: it played the Monty Python theme song (John Philip Sousa's "The Liberty Bell") if you held down some combination of modifier keys while selecting the menu item. At the end it even had the characteristic Monty Python "foot" come down on a list of viruses it detected, if I recall correctly. Good times.</comment>


Lean Designs is now $9/month - <AUTHOR> http://blog.leandesigns.com/2011/04/lean-designs-is-now-9month/ <comment><USER2> Minor copy hint. It will be better to tell people that they have been "grandfathered" than "downgraded" to the new price.

<comment><AUTHOR> Good catch -- thanks. I was thinking it meant they'd get the new price but you're right; it's the other way around.

</comment></comment><comment><USER3> As someone who does a lot of work wireframing sites and is always trying to make the move from wires to HTML and CSS take less time, this looks great.

Would love to see a fluid-width grid be introduced as an option down the line.

</comment><comment><USER4> That's a price point I'm comfortable giving it a long term spin on. Thanks. I do think a $99/year might be a decent prepay option for people who want a longer term commitment.

</comment><comment><USER5> Wow, I think I'm going to try it. Thanks! It's now at a price point where it's worth giving a whirl.</comment>


Ask HN: What about a read later Feature in HN? - <AUTHOR>

Where I work there is a really stupid DansGuardian setup that doesn't allow me to see 90% of the internet.
So a lot of times I see nice topics here that I wish I could save to read later.
Is there a way to implement some kind of read later feature ? so I can log in my account and get a list ? it could be daily erased so we don't need a lot of space to put all this, just for reading at home late night.
Thanks ! <comment><USER2> If you're only looking to save stories to read later on a day-by-day basis, why not upvote stories you want to read later and then visit your 'saved stories' when you have better access (accessible through your profile page)?

<comment><AUTHOR> This could be a nice option, but I would prefer a dedicated feature, maybe even save the big ones to read in the weekend...

I sometimes use my "patented"(kidding just my way of organizing myself) Gmail priority box tagging to task system to save the best ones for later, but It's not nice to have to e-mail 20 things a day to yourself.

</comment></comment><comment><USER3> It's a cool feature idea. Although, I have a workaround. I usually just copy the link location and save it to my delicious account with the tag toread.

Maybe delicious is blocked at your company, so that's not an option.</comment>


Miller, key to obtaining 14,700 tons of silver Manhattan Project - <AUTHOR> http://web.archive.org/web/20071217171643/http://www.oakridger.com/stories/051606/opi_20060516028.shtml

<comment><AUTHOR> I was reading through a synopsis of a Forsyth novel, "" ~ <http://en.wikipedia.org/wiki/The_Fist_of_God> and come across a device called a _"Calutron"_ ~ <http://en.wikipedia.org/wiki/Calutrons> Reading through the Calutron I came across the fact " _Ag"_ replaced scarce supplies of _"Cu"_. In the end using _"14,700 tons"_ from the US Treasury reserves of silver for the Y-12 Manhattan Project.

The question I wanted to know and what the article details is _"What happened to all the silver?"_

</comment><comment><USER2> Summary: This seems to be an obit.

The silver was used as an electrical conductor for electromagnetic separation of uranium isotopes.</comment>


Are ad blockers doomed or have we already won? A history lesson - <AUTHOR> https://adguard.com/en/blog/ad-blocking-history.html <comment><USER2> I posted this deep in a thread but feel like it should be a higher level comment so here we go.

Websites can be so ridiculously short sighted and just want to squeeze out every penny they can not thinking of the users they end up losing in the process. And they do lose users And fast. Personal experience time!

I ran a pretty popular wiki for Dungeons and Dragons homebrew on what used to be called Wikia. At some point they decided they available needed to have some terrible new skin that was stuffed with ads and unbelievable ugly. We pushed back but they were adamant about forcing it, so I took all the content and all the users and self hosted it for almost a decade afterward. The Wikia site was completely dead. Sucks for them but their choice.

I paid $10/mo or $20/mo for the site depending on the year, and never ran ads. At one point I got an offer from a company in the same hobbyist space to buy it from me. At that point I was extremely sick of being my own sysadmin and worrying about security vulns so I accepted it. Now some time later they're trying to pull the "stuff it full of ads in the worst places!" routine. Users are getting pissed and starting to ask me about taking all the content...and users...and going off to a server adminned by me again.

If I do this, it will be completely devastating for the site and tank their traffic. Do they care or realize? Guess we'll see.

All of this could be avoided if they just made the ads less shitty. Not showing up in the middle of navigation bars. Not being bigger than the surrounding content, so it completely stretches it and ruin's the site layout. Not having a completely clashing background color to the site. All extremely simple stuff.

<comment><USER3> I occasionally go The Guardian's web site, and they displayed a nag say I should not be blocking their way of making money out of a non-subscriber. I thought "fair enough" and disabled my ad blocker. About 2 minutes later, which is what it took for their web site to load with the ad blocker off, I turned it back on again.

In the end solved my attack of the guilts by becoming a subscriber. However, I had no sympathy for them no getting money form ads. That was totally self inflicted. The ad blocker, the thing they were blaming, wasn't the problem. Without the ad blocker I would not be visiting their site at all.

<comment><USER4> When I see a site that attempts to stalk me (even if my countermeasures manage to block it) the last thing I would do is to hand them my personal and billing details on a platter, give them money, _and_ act as a "manual" tracking cookie by logging into my account every time I visit the website (to bypass the paywall).

At least beforehand the best they could do is to get pseudonymous network & browser data (if they managed to get past my countermeasures like uBlock and nasty IP ranges blocked at the network level), where as once I pay they now have confirmed billing details they can do whatever they want with. If they don't respect my privacy before I pay then I have no reason to trust they'll suddenly respect it after I pay. Most likely they'll just attempt to have their cake _and_ eat it, aka take my money and _still_ stalk me.

</comment></comment></comment><comment><USER5> I feel that we've done ourselves a disservice by referring to them as ad blockers rather than content blockers or, better yet, virus blockers. With malicious ads being the primary vector for compromising a person's computer, calling these tools virus blockers would not only be more accurate, but it would make it harder for sites to counter their use from a public relations point of view.

Could you imagine visiting a web site only to have it tell you to disable your virus blocker to view the web page? Yet, web sites make the same requests of your "ad blocker" even though the end result is the same. They want you to disable your security protections and risk infection to view a web page.[1]

Sadly, I believe we've already lost this battle and are worse off for it.

1\. [https://www.networkworld.com/article/3021113/forbes- malware-...](https://www.networkworld.com/article/3021113/forbes-malware-ad- blocker-advertisements.html)

<comment><USER6> > With malicious ads being the primary vector for compromising a person's > computer, calling these tools virus blockers would not only be more > accurate, but it would make it harder for sites to counter their use from a > public relations point of view.

I don't understand this. How are malicious ads the primary way to compromise a computer?

<comment><USER7> It depends on the ad. In the before time, long ago, ads were a simple static image or body of text. And in that case, while not impossible, it's rather hard to compromise a computer with a static image or block of text. You'd have to have a fairly specific image crafted to adversarially target a specific bug in the rendering of images to get code execution, and thus compromise a computer.

It is no longer the before time.

In the now time, ads frequently contain not just text or images, but javascript as well. And already having code execution by virtue of javacript, it is a _lot_ easier to escalate the privileges of that code execution from the limited environment of the browser to installing code on the computer running that browser. Want to deploy your bot? Buy an ad that includes your malicious javascript payload. Now, anyone who goes to a site and views your ad will execute your javascript for free in addition to your offer to sign them up for credit score monitoring.

<comment><USER8> Are there any ad networks that allow random advertisers to include custom JavaScript in ads?

It just seems like a huge security hole and is not in the interest of ad networks for multiple reasons.

They might have JS in ads, but isn't that from the ad network's infrastructure.

<comment><USER9> Every single ad seller's been caught by companies selling these dangerous ads. Google, yahoo, etc. They usually catch it within 3-5 days. That's too long.

</comment></comment></comment></comment></comment><comment><USER10> Great article! It's funny to finally see ad blockers go "mainstream".

My dystopian-future fear is that that Web Assembly will be the end of ad blocking (and the end of a web of connected web sites). Big sites will eventually convert to essentially "a web browser inside a web browser" so they have total control over the content and how it's displayed.

Then ad blocking (and other customization) will be limited to "the analog hole" \- trying to image detect or OCR things.

I hope I'm wrong, but I've also been asked countless times over the years to "stop people copy/pasting our text" and "stop people seeing our code" and "stop people downloading our images"... the browser-in-a-browser feels inevitable!

<comment><USER11> > Big sites will eventually convert to essentially "a web browser inside a web > browser" so they have total control over the content and how it's displayed.

This has already happened: Just look at how many websites pester you to download their mobile app or even block content unless you access from the app. From a user functionality perspective the vast majority of apps do nothing a browser can't do. But the killer feature for apps is how much easier it is for the developer to get your location data, contact list, and importantly show you unskippable, auto-playing, 90s-era-popup-level-annoying ads

<comment><USER12> Many websites indeed pester us to download their mobile app but I have yet to find one that forces me to? Do they actually exist?

<comment><USER13> Reddit forces you to download the app now. You can scroll like 2-4 pages worth of content and then it'll pop up asking you to open in app.

On every page you navigate to from within the website you'll first get a pop up asking to choose between browser and reddit app.

<comment><USER14> I'm using old.reddit.com and wasn't aware they started doing this. Reddit is turning into a dumpster fire, it's bad enough I have to use the old UI so that it doesn't burn a hole in the cpu.

<comment><USER15> Forget the CPU usage, I only use the old UI because it's better/ I find it more usable.

Or maybe I'm just getting old :D

<comment><USER14> I wont disagree there, it's not useable. I wonder what possessed them into believing any of this was a good idea.

<comment><USER16> The new UI increases the similarity between posts and ads, making you more likely to mistakingly click on an ad.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> From the article:

> The very beginning of ad blocking is the 90s, just when the ads appeared. In > 1993, GNN, the very first web advertising service, was launched. Then in > 1994, the first-ever banner was sold. In the blink of an eye, the online ad > industry was worth billions of dollars. Double Click emerged, Yahoo started > to sell ads. And that's when the very first ad blocker was created.

GNN (Global Network Navigator) was not an advertising service. It was the first commercial online magazine. O'Reilly & Associates, the publisher of GNN, wanted to see if a website like GNN could be supported through commercial sponsorship. GNN's ads were informational — much more like whitepapers than a display ads. (Wired's HotWired site, which launched at almost exactly the same time as GNN in the fall of 1993, invented the banner ad, which of course is what most adblocking tech has targeted. Cookies for tracking didn't come along until later.)

Source: I worked on GNN as technical director, and in fact my first job there, in the summer of 1993 about a month before we launched, was to assemble the first 'ad' — a set of articles about intellectual property law, sponsored by the now-defunct Bay area law firm Heller Ehrman.

<comment><USER18> > GNN (Global Network Navigator) was not an advertising service. It was the > first commercial online magazine.

Isn't that the same thing? With a couple of exceptions, magazines are advertising services first and foremost, in as much as the overwhelming majority of their revenue comes from ads.

<comment><USER17> I don't want to argue about magazines (or newspapers) in general, since it seems you have quite a cynical view there. I'd advise that you research common standards of journalism, including the concept of the editorial/advertising wall.

But I'll tell you that the the existence of GNN itself, in 1993, was certainly not for the purpose of serving ads. Heck, as I explained, online advertising didn't even _exist_ at that time (besides a few misguided attempts on Usenet), so there was only conjecture that it might work at all, and lots of room to experiment.

Also, there was really no other economic revenue model accessible to us, other than sponsored content, as there were no online payment systems on the WWW of that era. Heck, there weren't really any active websites at all — almost all sites (including GNN) were what we'd today call static sites. (As I mentioned, cookies came later, so there was also zero targeting of ads besides basic demographics of Internet users at the time.)

<comment><USER18> > I don't want to argue about magazines (or newspapers) in general, since it > seems you have quite a cynical view there. I'd advise that you research > common standards of journalism, including the concept of the > editorial/advertising wall.

My cynicism comes not from being ignorant of traditional newspapers but from having been very close to them. My experience is that people (in any industry really) may be decent, noble, and above any such influence on any conscious level, and yet they will nevertheless show an almost magical tendency to act in alignment with their economic interests, even when they seem to have reached their position on wholly unrelated grounds.

</comment></comment></comment></comment><comment><USER19> So a survey article about adblocking without mentioning the main ad blocker in the world (and their competitor), ublock origin. Well played! As for the history lesson, the main meta lesson is that adblockers need to be completely detached from any monetory incentives. No company, however noble, should be trusted at all. Only open source + community ad blockers have survived and flourished. Time and again, people have tried to make a quick buck by becoming the middlemen in the adblocking industry by promoting their flavour of ads, whitelisting ads, or just hijacking ads.

<comment><USER20> Sorry for that, we don't mind mentioning anyone, it's just there was no historical event that we could tie to uBO. I'll ask the author to add a footnote about uBO and others we missed to mention, we love them all.

upd: done

<comment><USER21> I haven't read the article, and I'm not what you'd call well-versed in the history of ad blocking.

But even I know that uBlock was bought out and introduced 'acceptable ads', and that uBlock Origin became the community fork which maintains the spirit of the original uBlock.

That deserves more than a footnote, imho.

<comment><USER22> Acceptable ads was introduced by adblock plus, and it remains their primary revenue source.

uBlock is the original version of uBlock origin. Both were started by gorhill4 (sp?). Gorhill got sick of the constant support burden of people coming into his repo and reporting unblocked ads, which he then had to redirect to the filter list repos.

He handed the entire project off to some teenager with little programming experience. Said teenager did little but make a new website and request donations, core work basically halted.

Afterwards, gorhill got sick of seeing his old project be abandoned and get a bad reputation, and forked it as uBlock origin.

Thus, uBlock origin is not a community fork.

</comment></comment></comment></comment><comment><USER23> If I can't block the ads on a page I'm simply not going to visit it ever again. I've never seen a website that was actually necessary for me to visit that had ads or couldn't be blocked.

<comment><USER24> I feel the same. There is nothing on the web I need to read _so_ badly that I am willing to put up with advertising to get it; I can just go waste my time somewhere else.

</comment></comment><comment><USER25> Commercial companies being able to force themselves onto our consciousness is unacceptable.

Personally, seeing ads in public spaces feels just like in totalitarian countries you would see large portraits of the supreme leader or government propaganda. Somehow this is legitimized because they're private corporations. Not in my book.

More power to ad blocker authors, and a particular shoutout to:

* Raymond Hill of uBlock Origin fame: [https://github.com/gorhill/uBlock/](https://github.com/gorhill/uBlock/)

* The EFF, for blocking trackers and other 3rd party nasties with Privacy Badger: [https://www.eff.org/privacybadger](https://www.eff.org/privacybadger)

</comment><comment><USER26> Websites started off with a glass storefront and an open door. You kinda had to poke your head in the door to look around to see if you wanted to go in. Then the glass storefront had some sales prices shown. Then slowly you could no longer even see the glass storefront for all the ads. Then the spinning sign men showed up to annoy. Now, there's a bouncer with a clipboard blocking you from getting in.

It's mostly just not worth the effort any more unless you have an ad blocker in some form.

<comment><USER27> This is a really good metaphor.

</comment></comment><comment><USER28> Who is honestly clicking on all these ads that makes advertising worthwhile?

I am honestly baffled sometimes how this all works... In my 30+ years of internet usage in one form or another I have rarely, rarely, rarely ever clicked on a freakin ad. Yes, I've generally had them blocked for the most part. But when they aren't blocked, I see what the content is and why would I even want to click on one!

Color me confused who is keeping the web running by clicking on ads.

<comment><USER29> Part of me thinks theres an internet ad bubble. I think its really hard to know how much value an ad provides, so it gets handwaved as being critical to success and worth tons of money. A lot of big internet companies rely on ads or provide services to companies that provide ads or make it easier to use ads.

<comment><USER4> I wouldn't say that ads are completely ineffective (there's a significant chunk of the population that doesn't resent ads like we do, and will actually click on them even if they're aware that they're ads), but I agree that there's definitely a bubble going on.

I've seen many non-tech people search for a certain brand or product, and despite it being the first non-sponsored search result, they will instead click on the sponsored result/ad ad the top even though it's the same product.

The above causes the metrics and conversion rate to look great, so the waste of oxygen that is the marketing department can justify their salary and budget, the ad providers and all the ecosystem around it also gets paid, but at the end of the day that ad wasn't _actually_ providing any value because the user already had the brand in mind and only clicked the ad by mistake.

</comment></comment></comment><comment><USER30> I miss the days when barely anybody blocked ads. Those of us who did didn't have to worry with defeating anti ad block systems.

<comment> gjsman-1000 uBlock Origin is shockingly competent at defeating those "please turn off your adblocker" warnings.

<comment><USER31> On most sites, at least. There are a few out there that go well out of their way to be annoying. Facebook likes to construct their ad text out of multiple randomly-named divs. TVTropes uses randomized IDs on their ad popover.

<comment><USER32> They seem to do this for more than just straight ads. I use uBlock Origin to filter out the "Stories" div. It comes back every week or two.

</comment></comment></comment></comment><comment><USER33> Basically ad blocking makes the internet useful again. I am no longer bombarded with popups or distractions. Therefore I won. Tracking is pathetically useless on the internet. It's easy to screw with the metrics and your "profile" but even without doing so tracking is simply snake oil

</comment><comment><USER34> There is a great paper on the arms race between Ads and Ad Blockers out of a group in Princeton.

They propose a perceptual ad-blocking scheme where ads are always rendered in a DOM, but elements only displayed to the if they are not "ad like". This is makes it much easier to evade ad-block detectors, since your browser appears as if it does not have an ad-blocker! [https://www.cs.princeton.edu/~arvindn/publications/ad- blocki...](https://www.cs.princeton.edu/~arvindn/publications/ad-blocking- framework-techniques.pdf)

<comment><USER35> The alternative to the arms race is to stop having browser extensions. In a browser like chrome made by an advertising company with 80% of the browser market last I checked, the results could be devastating for the vast majority of internet users. We nerds will always be fine.

Mobile will of course fare far worse unless you root your device, for ios and android. Can't wait for the inevitable day where the unskippable 10 min youtube ad pauses if I look away from the screen...

</comment></comment><comment><USER36> Ad blockers were born earlier than the Internet and personal computers.

\---

A Personal Computer for Children of All Ages

Alan C. Kay

Xerox Palo Alto Research Center, 1972

[https://www.mprove.de/visionreality/media/kay72.html](https://www.mprove.de/visionreality/media/kay72.html)

>A combination of this "carry anywhere" device and a global information utility such as the ARPA network or two-way cable TV, will bring the libraries and schools (not to mention stores and billboards) or the world to the home. One can imagine one of the first programs an owner will write is a filter to eliminate advertising!

</comment><comment><USER37> I don't turn off my virus blocker for anyone. No way no how no sir. Sites that refuse to show content without opening up for viruses are intrinsically suspicious, no matter how fancy their brand name.

</comment><comment><USER38> When adsense first came out it was text only and ads were actually fascinating and interesting to read. They were regulated and meaningful.

Then images and javascript were eventually allowed and it was all downhill from there. Now it's a race to the bottom of how many hundreds of external objects and tracking that can be added to a page as well as malware since so many badly behaving ads slip right through any attempt at automated bans.

</comment><comment><USER39> I don't block ads but I do block all javascript by default. They are essentially synonymous now.

</comment><comment><USER40> "It means that an ad blocker of the future will have to monitor traffic of the entire network." (towards the end)

This is already a concern in the DNS world, with Response Policy Zones (RPZ) on one hand for DNS-based control ([https://dnsrpz.info/](https://dnsrpz.info/)) and DNS Over HTTP(S) (a.k.a. DoH) on the other.

</comment><comment><USER41> Here's another history (the dates in the OP are fuzzy). [https://www.thedrum.com/opinion/2019/12/20/monetizing-the- ba...](https://www.thedrum.com/opinion/2019/12/20/monetizing-the-banner-ad- crisis)

</comment><comment><USER25> I wonder if the legal action against AdBlock Plus / Palant made a dent in the download or use of ad blockers in general. The article doesn't provide any evidence of this.

Also - don't get your apps on Google or Apple's app stores! Use APKMirror, APK pure, etc. Some of these even have app-store-like apps to use instead of Google's, that don't need a Google account.

Also, there's at least one app "store" app specializing in FOSS purely: [https://f-droid.org/en/](https://f-droid.org/en/)

</comment><comment><USER42> I feel like the article is missing an important milestone about release of Brave browser for Android circa 2017/2018 (it's only briefly mentioned at the end).

It changed the landscape on Android in my opinion: it was the first browser that was _as good as Chrome_ (fast, same look & feel -- being a fork of Chromium -- plus regularly updated and having strong, credible technical team behind it) but also having ad blocking built-in and other additional privacy measures. Soon Opera added ad blocking as well, and other browsers (except Chrome) followed.

<comment><USER43> You have your timeline backwards. Opera was the first browser to implement a built-in native adblocker in 2016. Here is the blog announcement: [https://blogs.opera.com/desktop/2016/03/opera-built-ad- block...](https://blogs.opera.com/desktop/2016/03/opera-built-ad-blocking-now- beta/)

Opera was and actually continues to be a pioneering browser with many "firsts" over the years. I was an avid user of it for a decade but I am saddened that it has become surrounded in controversy with a shady Chinese owner and predatory loans and stopped using it two years ago.

[https://www.engadget.com/2020/01/19/opera-accused-of- predato...](https://www.engadget.com/2020/01/19/opera-accused-of-predatory- loan-apps/)

<comment><USER42> Good catch! Here's a better link specifically talking about mobile: [https://blogs.opera.com/news/2016/06/ad-blocker-android- ios-...](https://blogs.opera.com/news/2016/06/ad-blocker-android-ios-windows- phone-download-free/)

</comment></comment></comment><comment><USER44> I personally think we're nearing the end of a golden age where sites can support themselves through advertisements that 90 percent of users see while we, the nerds, are able to easily block almost all the ads. The more widespread blockers become, the more incentive there is to create unblockable ads, e.g., YouTube inserting a video ad directly into the video stream so that even if you had some kind of content-aware AI blocker running you still wouldn't be able to continue your video until the ad is over and the unedited stream resumes.

</comment><comment><USER45> Please correct me if I am wrong here regarding Ghostery functionality: In current Firefox & Vivaldi versions it behaves as you would expect....blocks ads according to your settings for every tab load. But in chrome, the default behavior (assume chrome induced) appears to be to auto disable the plugin until you manually re-enable the plugin then reload the tab....repeat process for every new tab load. Do I have a Chrome setting misconfigured or is this another example of Google's "what's best for you is what we say it is" attitude?

<comment><USER46> [https://github.com/Eloston/ungoogled- chromium](https://github.com/Eloston/ungoogled-chromium)

<comment><USER47> how's that related to parent's question? I can't find a correlation. are you suggesting he not use chrome? that's isn't much of an answer.

parent: I've not seen this problem. I only use chrome on mac. maybe on windows/linux it's doing something differently. as each new tab is a new process, it smells like a goofball file system permissions issue to me. does it still happen if you create a new profile?

it works as you'd expect both with google sync on, off, paused, and never- been-setup for me.

hard to imagine that this isn't some bug of installation for you. there's no way this would be tolerable behavior and if it were because of chrome per se, there'd be lots of uproar so you'd find your answer right away.

<comment><USER45> Yes, agree, expect would have seen more of an uproar if this was wide spread. Was trying to stay out the troubleshooting rabbit hole, thus posting the Q here in case other have observed the same. Still, with the other browsers proclaiming more privacy features and google somewhat begrudgingly trying to slow that conversation its hard to know what to expect in chrome without going deep into their roadmap.

</comment></comment></comment></comment><comment><USER48> > Now it's surprising to see a lot of comments like: "Why do you need an ad > blocker? Just use the hosts files".

I often wonder if people realize that they're being that person.

</comment><comment><USER49> I guess we all know Chrome on Android doesn't support extensions in order to prevent ad blockers. If there wouldn't be Firefox, Chrome on desktop would have surely limited ad blockers as well.

</comment><comment><USER50> Is part of a digital detox turning off java by default and enjoying the Text Web in its full glory?

What do you estimate the cost is annually for all of the wasted bandwith (especially mobile data) on predatory marketing?

</comment><comment><USER51> I remember using Naviscope and sometimes dealing with DNS blocks with the hosts file. Those were the days. (I had a very rudimentary ad blocker via my web browser back in the days [404Browser])

</comment><comment><USER52> No one (or a much lesser percentage) would use an ad-blocker if ads were just _ads_ , without all the tracking, privacy and malware concerns.

Go back to contextual static-image ads, folks.

</comment><comment><USER53> 1\. Click

2\. Open network panel

3\. Google Analytics

4\. Close tabs

It's disgusting how so many so-called privacy advocates can't even get this right even when _talking about privacy_.

</comment><comment><USER47> > 2015 — Content blocking comes to Safari and iOS

typo. He means "Safari _on_ iOS". Safari on desktop had normal extension-based ad blocking since day 1. Then the content blocking API came to iOS then later the same API in macOS.

> • No debugging tools

perhaps in 2015 -- I wouldn't know -- but today it's certainly debuggable with the help of a macOS host. Much like remote gdb.

> The maximum number of rules limitation is a huge problem,

not a problem at all. rules limitation is _per filter_ but each adblocker can install multiple filters. I suppose the rules limitation is for latency reasons, in case of a poorly designed blocker.

> It was disproportionately hard to maintain a completely different filter > list for Safari alone.

Completely false. filters are regex's. It's trivial to use the same source list with whatever filter technology.

I guess because this article is content marketing, and not academic research, these errors (and omissions) are ok. But I do wish, that given the title, the author had bothered to mention that Bing inserts ads that are not blockable via simple URL filters. adblock+ currently doesn't handle them and I believe they are not handle-able at all via the Safari content filter API. By extension => ad blockers are doomed. So yeah, he's not going to say that because he's selling an ad blocker ...

<comment><USER20> 1\. The only debugging tool we have is the browser console, and the only thing printed there is the blocked URL, you cannot even find out what rule did that.

2\. The maximum number of rules IS a problem and it is there only because the current implementation consumes to much memory and slow to compile a content blocker. WebKit devs may allow us to pull request an alternative implementation (there's an ongoing discussion on bwo), and if there are no performance issues, the limit will be increased.

3\. Regarding maintaining a filter list, traditional blockers do not use regexes unless it is really really necessary. What's written in this post is by people who maintain filter lists for over 10 years.</comment></comment>


Starship Troopers: One of the Most Misunderstood Movies Ever - <AUTHOR> http://www.theatlantic.com/entertainment/archive/2013/11/-em-starship-troopers-em-one-of-the-most-misunderstood-movies-ever/281236/?single_page=true <comment><USER2> Never considered the sarcasm and social critique in that movie to be all that subtle. "Would you like to know more?" ([https://www.youtube.com/watch?v=faFuaYA- daw](https://www.youtube.com/watch?v=faFuaYA-daw)). Loved the movie for it.

Could never get over how different the book felt though. No hint of what I liked so much in the movie. Basically the complete inverse message of the movie.

Don't think I've ever seen this kind of "same story, inverse message" between a book and a movie before.

<comment><USER3> The video feels like comedy to me, but that wasn't what I felt back in the days when the movie came out and I was young. It gave me more of a dystopian feeling.

</comment></comment><comment><USER4> Please add [2013] to the title

</comment><comment><USER5> I don't think it was misunderstood; it was just a poor job of being a satire of the book. To properly criticize a subject, /you have to take the premise seriously/, which is what Verhoeven didn't do.

The premise, the basic engine of the book, is a young man's coming of age story into military and society, and his longing to reconnect with his father. It's not really about fascism or propaganda. This shows that Verhoeven didn't really even care to understand the book. He critiqued what he thought it was about.

This is a longer post I wrote on reddit back in 2013:

"I argue that's why it sucks as a critique, because it just allows you to laugh and blow off the propaganda as fluff, instead of taking it seriously.

What's scary about Nazism, fascism, totalitarianism, etc. is how many people fall for it and then commit horrible acts, believing they're doing the right thing, while getting teary-eyed for the state.

When you read Starship Troopers, you find yourself getting a misty-eyed sentiment for the corps and "The Brave Sacrifice that our men and women make..." and then you think "WTF? This novel is about space bugs. Holy hell, this propaganda shit works!" and you begin to realize how insidious and effective the propaganda truly is.

When you watch Starship Troopers, you just laugh and say "Oh, what a ridiculous movie. Ha ha ha, isn't that funny." You don't fall for the propaganda, which is what an effective critique would have you do. Instead, you can stay above it and laugh condescendingly at those poor idiots who do, and then get eviscerated by space bugs. But you, as an audience member, are too smart for that, because you can clearly see that it's a sound stage. It allows you to remain safe in your comfort zone, whereas real art would expose you to your own vulnerability.

It's like the people who think they're getting a dig in on Hitler by calling him an "asshole" and saying "Fuck you, Hitler!" Sorry, not really the level of critique and understanding we need for Nazism. That's not a strong-enough tearing apart of Nazism.

Likewise, we need something stronger then a self-aware B-flick science fiction parody to criticize Starship Troopers. It doesn't really do the job. It's not a critique of the book, though it is a critique of militarism and state propaganda.

A true critique of Starship Troopers would address the actual mechanisms that Heinlein employs in the book, such as nostalgia, camaraderie, and espirit de corp, or the main character's estranged relationship with his father, and the role that seems to play in his finding fulfillment in military life. It's actual military service and culture, not state propaganda, that informs Rico's beliefs and feelings in the book.

Instead we get a movie seemingly inspired by Starship Troopers, taking place in the same universe, but not actually dealing with the themes presented in the book. And at that, a boring, B-grade science fiction parody that's supposed to be interesting because it knows its a parody wink, wink. It's not a criticism of the book."

"A criticism is basically a comedy, and a comedy has a straight man and a clown. In a parody or a farce, the comedic target is the buffoon, and the audience is the straight man who's job it is to say, "Hey, get your act together, stop fooling around!" But the mechanism of the comedic critique is that the target is too stupid to know better, and continues acting the clown.

When the movie is winking at the audience, it's not the clown because then it's in on the joke. Being over the top and cheesy, we know that the movie isn't taking itself seriously; it's playing dumb instead of being actually dumb. It's saying "hey, isn't this silly" instead of presenting actually silliness. As the audience, there is no position for criticism because the movie already knows it's misbehaving. It's our role to say "hey, this is silly", and when the movie does our role for us, it's boring because it allows us no participation.

Take this scenario:

        Man on sidewalk: Hitting head with hammer.

        Passer-by: "Hey! Don't do that! You'll hurt yourself!"

        Man on Sidewalk: "But how will I get rid of these lice!?"

That's a comedic scenario (regardless of its quality). The Man is doing something actually dumb, being a buffoon, and the passer-by is criticizing the action, being the straight man. Now take this:

        Man on Sidewalk: "Hey buddy, wouldn't it be silly if I hit my head with a hammer, like this?" Hits head with hammer "It's that crazy?"

        Passer-by: "Yeah, that's crazy".

That's not a comedic scenario because the Man on sidewalk has taken both the roles of buffoon and straight man. In presenting the action as stupid, he's also acting as the straight man, his own critic, and the Passer-by has no role in the interaction; he adds nothing, he just agrees with the Man.

When you read Starship Troopers, its presented sincerely, at face value. That leads you to take it seriously, think about it, question it, arrive at your own conclusions. You play the straight man, questioning the actions of the guy on the sidewalk.

The movie is presented as a farce, a joke, "Hey look at this, isn't this ridiculous?" "Yes, it is, why am I watching it?" It's clearly over the top, an exaggerated caricature. It doesn't lead you to think deeply about the issues presented, it allows you to blow them off as silliness and fluff. There's no role for you here, nothing to engage in. You just agree: "Yup, this is totally ridick!"

It's like getting 1984 wrong. These books are seminal in American and trans- Atlantic thought about government and the individual. It's too important not to do the best job at."

<comment><USER6> _Starship Troopers_ , the movie, wasn't intended as a satire of the book, it was intended as a satire of fascism. The original screenplay was percieved by some involved to have some similarities to _Starship Troopers_ , the book, so the film rights were picked up and some cosmetic changes to the script made. I think that is a pretty shallow and uninteresting satire of what it targets, and that it further suffers from being tied into the book -- which Veerhoeven admits that he read very little of -- which gets it viewed as simply a hostile reaction to the book or an even weaker satire of the book (compared to how it is as a satire of its actual target.)</comment></comment>


Ask HN: Fypayme as a service? - <AUTHOR> How feasible does this seem: when a client does not want to pay up, go to fypayme as a service, upload your data, get accepted or not, and they buy your debt (at 60% or so) and go after the client to pay up.<p>Just a thought from recent threads :) <comment><USER2> Love the idea - and would certainly use one. :)</comment>


Teaching code optimization to 11-year-old son. - <AUTHOR> http://carymillsap.blogspot.com/2009/06/profiling-with-my-boy.html

<comment><USER2> I don't know, isn't 11 year old a bit premature for optimization? (sorry, I had to :))

<comment><USER3> On the plus side, since it appears that he understands that you don't optimize the thing that takes 2 ms (application code) while there are things taking 200 ms (database roundtrip) or 700 ms (page rendering), he is probably better at optimization than half of the professional engineers I know.

God save me from one more code review where somebody made a for loop over months in the freaking year an obtuse nightmare because they had (mostly wrong!) ideas about how they could shave off a few _processor cycles_ twelve whole times. (Inline functions for extra speedup! Forget standard math operators, lets twittle bits! Business objects are for wimps, we'll stick everything in one String -> String hash table and compose the keys with inlined uncommented StringBuilder monstrosities!)

</comment></comment><comment><USER4> At that age my dad was teaching me and my siblings circuit debugging and my mom was teaching us programming on CP/M. Valuable stuff. If anyone thinks this is "too advanced", I respectfully suggest that this stuff is just too new to be mainlined into the traditional curriculum. Process analysis is as powerful, simple and vital as any chemistry or maths.

</comment><comment><USER5> When I was 11 years old, my dad taught me to be a goalkeeper. I've now not touched a football since I was 15.

<comment><USER6> OT:

When I was 11, my father fled overseas and I carried a pseudonym, and a rifle almost as tall as me:

<http://en.wikipedia.org/wiki/SAR-80>

(any other civil war children on HN?)

</comment></comment><comment><USER7> Programming, and analysis is tremendously valuable skill for a kid this age to start learning. I've been gently bringing this sort of thing up to my kids since they were old enough to understand the words I was using.

</comment><comment><USER8> It's interesting to hear about what people's dad's taught them when they were 11 years old. So far, I've got:

robg's son - Code optimization (result pending)

aristus - Circuit debugging (turned out to be very useful)

J_McQuade - How to tend goal (skill no longer applicable)

biotech - World geography and history (good to know in social situations; I work with, and live near, people from all over the world)

Anyone else?

<comment><USER9> My dad taught me he wasn't afraid to kick me in the ass (actually) if I stepped out of line (figuratively). It was actually a useful lesson and helped me to reconsider my attitude to others and stop being a dick.

</comment></comment><comment><USER10> Looking forward to teaching my kid this kind of stuff as well. But it will take about another 15 years until he turns 11.</comment>


Why easy deployment is great - <AUTHOR> http://www.solberg.is/kraftwerk.html

<comment><USER2> Similarly, Ruby developers are flocking to easier technologies like Passenger in droves rather than sticking with the older (but often faster) technologies like NGinX and mongrel_cluster.

It's nice to have the powerful technologies for more "serious" deployments, but it's _really_ nice to be able to easily get a quick project up and running.

Heroku, as he mentions, is fabulous for that.</comment>


Simplicity and Utility, or Why SOAP Lost - <AUTHOR> http://keithba.net/simplicity-and-utility-or-why-soap-lost <comment><USER2> I think this is largely accurate, but one thing the article misses is that SOAP was never as interoperable as it was claimed to be. If you had a Microsoft client and a Microsoft server, things would work great, but as soon as you started mixing vendor implementations, you quickly ended up in configuration hell. For simple SOAP messaging you could usually get it to work with enough elbow grease, but for any of the WS-* protocols you might as well be doomed. I lost days, if not weeks, of work to failed interop of WS-Security across two different vendors (both Java, and both with the code under my control).

<comment><USER3> I spent several years integrating Java/Linux/Unix/Microsoft/etc and I never ceased to be amazed at how many companies/programmers thought it required different code to make them interoperable. I had very few issues with SOAP interaction between systems because they are just text files.

For all intents and purposes, SOAP is a formatted pipe connection. The only issues I ever ran into were related to things like Java incorrectly implementing RSA encryption or Microsoft adding so much complexity that nobody used (and did not require).

There are still several major banks/insurance companies out there whose payroll transaction systems run on the SOAP implementations I put in place 10 or more years ago.

Now I see people claiming REST is better (and in many ways, they are correct), but I also see that large numbers of programmers don't really grasp REST any better than they did SOAP.

<comment><USER4> > I had very few issues with SOAP interaction between systems because they are > just text files.

Did you write parsers for the messages by hand every time?

I did a bit of work with SOAP, and found interoperability to be a problem. Encapsulation and signatures both spring to mind. But then, i was using tooling on both sides. I shudder to think what dealing with SOAP messages manually would have been like.

<comment><USER3> Why would I write manual parsing code every time? There already are/were XML parsers in every language I needed to integrate. SOAP is just XML. XML is easy. I've moved to REST implementations but I have just quite got why anyone thought SOAP itself was anything complicated.

Microsoft's 'WS' implementations were a mess of SOAP, but that's a whole different story.

</comment></comment></comment></comment><comment><USER5> The S Stands for Simple — [https://web.archive.org/web/20140710041718/http://wanderingb...](https://web.archive.org/web/20140710041718/http://wanderingbarque.com/nonintersecting/2006/11/15/the- s-stands-for-simple/)

a web classic, can never be linked enough times

<comment><USER6> "can never be linked enough times"

Off topic question here. Does an archive.org article get cached so that when it's linked to it comes up faster? Or does it display at the same speed of a random archive.org page?

That page came up pretty fast for me don't know if that is random or because other people are hitting the link from HN.

<comment><USER7> Archive.org does caching. A page is pulled from long term slow storage, and cached.

</comment></comment></comment><comment><USER8> The entire thing hide itself behind a "don't worry about how that works, the tools and libs are supposed to do that for you" philosophy, and then those would fail and break so often it was almost comical. You would then end up debugging the entrails of a SOAP exchange, which is one of the most terrible things I've seen.

</comment><comment><USER9> I feel like I spend a troubling amount of time as a software developer dealing with and/or avoiding solutions that are much more complicated than the problems they're trying to solve.

<comment><USER10> tell me about it... I've been searching for a C++ library that will encode x86 instructions from syntax that looks moderately similar to assembler code. Not a disassembler, not a JIT toolkit, not a special cross-platform IR that gets compiled to real instructions. Just an instruction encoder with a moderately pretty syntax. No luck so far.

<comment><USER11> Have you seen xed [1]? It seems to fit the bill nicely from what I understand about your requirements.

[1] [https://software.intel.com/sites/landingpage/pintool/docs/67...](https://software.intel.com/sites/landingpage/pintool/docs/67254/Xed/html/main.html)

<comment><USER10> yes, I don't need its decoding capability and I don't think its syntax is pretty but if I ever decide to write my own library I'll probably wrap xed in some C++ sugar.

<comment><USER12> I'm not sure I understand your requirements but might DynASM be useful? It's one component of the JIT library behind LuaJIT but many people use it for run- time code generation completely outside a JIT setting.

[http://luajit.org/dynasm.html](http://luajit.org/dynasm.html)

<comment><USER10> DynASM looks cool but its preprocessing step and fancy C integration definitely place it outside the description "Just an instruction encoder with a moderately pretty syntax."

I guess it's not fair to say that XED and DynASM are "much more complicated than the problems they're trying to solve." They are much more complicated than the problem _I 'm_ trying to solve. But I am surprised that there is no minimal X86 encoder with nice C++ syntax out there.

</comment></comment></comment></comment></comment></comment><comment><USER13> The fact that SOAP is not reasonably supported in a browser was a huge reason it fell down. When SOAP first came on the scene, complicated AJAX based applications were not typical. But as more and more JSON/HTTP APIs emerged in conjunction with browsers becoming more powerful and rich apps build built in them, the meaninglessness & complexity of SOAP grew.

Also, another major issue with SOAP is that most all of the popular tools would generate classes based on a WSDL. This creates a toolchain issue that is readily solved for someone experienced, but can really suck if you are new to the idea of generated code working it's way into your project.

Much worse was the scenario of WSDL versioning in conjunction with these tools that generated classes. If the API never broke backwards compatibility, you should be OK and can just use the newer class representations, counting on the service and tools to deal with null fields appropriately (not always true unfortunately). But if version bumps of an API/WSDL broke backwards compatibility... then you had to have separate class hierarchies for different versions of the WSDL; what an intense headache. Contrast that to web REST APIs; without a formal schema and a lack of class-centric tooling, client libraries would often let the author stuff in the params themselves and let the serializer stuff in the body based on the params; so yes your API is not as formal, but this isn't a big issue but offers infinite flexibility in dealing with one-off versioning issues or interop issues.

As someone else mentioned, some platforms couldn't interop with others (differences as it related to simply stuff like nullable fields or primitives existed all over; total nightmare), and some features of WSDLs didn't translate well to certain languages.

A great WSDL author would know to make their WSDL as simple as possible, because they had spent time working with various language toolchains and new the limitations out there, but that's asking way too much and not realistic for someone to have to spend all their time trying to understand all the ways someone in language XYZ might use their WSDL.

<comment><USER4> My observation of the rise of JSON/HTTP was that it was a thing happening in the dynamic language communities, and that only came into the Java world when the battle was already over.

I suspect the dynamic language communities preferred JSON/HTTP so strongly because it was so much easier to use: they didn't have big corporate backers releasing SOAP tooling, but it's trivial to parse JSON straight into structures that are more or less native to the language (arrays of objects in JavaScript, lists of dicts in Python, arrays of hashes in Ruby).

Java did have heavy-duty SOAP tooling, and didn't (and doesn't) have a natural way to represent JSON's objects, so it was much less of a win there.

<comment><USER14> Not sure what you mean. What about

[https://github.com/douglascrockford/JSON- java](https://github.com/douglascrockford/JSON-java) ?

<comment><USER4> Given the JSON string:

        {"cities": [{"name": "London"}, {"name": "New York"}]}

Parsed into a variable called 'root' with either 'new JSONObject(...)' or 'json.loads(...)', compare:

        root.getJSONArray("cities").getJSONObject(0).getString("name");

To:

        root['cities'][0]['name']

The Python version is the sort of thing you find yourself writing in Python anyway (at least, if you write tabloid-level Python the way i do); it's reasonably idiomatic. The Java version is cumbersome and feels very un- Javaish.

Bear in mind that with SOAP, in Java, by that point you would have mangled the data into realistic-looking objects, and would write something like:

        root.getCities().get(0).getName();

</comment></comment></comment></comment><comment><USER15> I think SOAP has lost in a sense that it's no longer very popular around many web developers.

But has it really lost? I still see it used a lot in large corporate and high tech environments.

I was never a big fan of SOAP myself, but that's also partly because when I started, the tooling wasn't great and I got mostly a negative user-experience. But this is many years ago.

My understand is that these days it's quite good, and it has a pretty good user-experience. Furthermore, everything is backed by xml schemas, which makes it easier to create and require strictly valid xml being sent back and forward.

While some equivalents exist in REST-ish API's, it's arguably not very common and with SOAP it's a pretty much a free and built-in feature that everybody uses.

Modern web API design is great for getting things up and running fast, but it's not amazing for rigorously robust design.

I don't really like the "SOAP is bloated and over-engineered" narrative. It is uninteresting now, and was uninteresting 10 years ago.

I think it's much more interesting to learn about the things that SOAP did get right, and see how we can apply some of these learnings in our API's.

<comment><USER16> I work on an SOA platform for a very large software company. We offer both REST and SOAP versions of our RPCs. In my experience, SOAP services are okay plug-and-play if you own both the provider and the consumer. But consuming external APIs can be nightmarish, especially with SOAP 1.2. SOAP exists in our organization for legacy reasons but we recommend all new consumers use RESTful services.

Our mobile clients like REST because it's faster and easier to consume from outside the .NET platform than SOAP. Even within the .NET platform, a client can get up and running consuming a "RESTful" service in fewer lines of code than a SOAPy one. Not only SOAP tooling, but HTTP client tooling in general, is a lot easier to use these days.

WSDLs are cool because they are a fairly standard metadata format. Our clients like them because they can perform data validation with proxy/firewall systems before the request ever enters the corporate network. I've yet to see a concrete benefit from that kind of strictness, though. IMO, SOAP schema validation is so brittle that it causes more problems than it fixes.

Of course, you can also use non-SOAP document description formats like RAML for describing your RESTful services. It's not like SOAP offers anything you can't get for REST. But once you start adding all that on top of your REST API stack, you might as well use SOAP 1.1. (Never use SOAP 1.2).

I don't think the main problem with SOAP is that it's over-engineered, although it is. The issue is that the supposed benefit of "interoperability" was never really realized. It's supposedly protocol-agnostic, but nobody cares. It's supposedly interoperable, but everyone implements it differently.

<comment><USER15> Very interesting! My knowledge was mostly based on hear-say, so it's great to get some details from someone with actual experience with SOAP.

What's wrong with SOAP 1.2?

<comment><USER16> It's too confusing, I think. The effort it takes to try to understand what's going on is too great. You can explain our REST service infrastructure to a developer in a few hours. I don't know how long it would take to explain the SOAP infrastructure, because I don't think anybody understands the whole thing.

If you are trying to communicate with a vendor that uses SOAP 1.2, it almost always seems to come down to guesswork. What set of properties do I need to specify before they accept my request? The WSDL gives you an object schema but it's not sufficient for the masses of WS-* extensions that you might have to support. Meanwhile, the vendor just exposes the WSDL and assumes that's sufficient "documentation" for clients and you don't need any examples or explanations or other info. I find the best way to approach this is to open Soap UI and start messing with settings until requests are accepted. There's no point asking the vendor for documentation because they probably don't know themselves.

Also, speaking from the perspective of a framework developer, I mainly start to pay attention when things stop working or clients are having problems. SOAP 1.2 doesn't have any more problems, but the problems are proportionally harder to solve. No matter how good your tooling is, it's not perfect, and it's a lot easier to look "under the covers" for RESTful services than for SOAP services. Of course that could also be attributed to the hellish nature of WCF, and not SOAP 1.2 per se.

<comment><USER17> This. So true!

        ...it almost always seems to come down to guesswork.

        Meanwhile, the vendor just exposes the WSDL and assumes
        that's sufficient "documentation" for clients and you
        don't need any examples or explanations or other info. I
        find the best way to approach this is to open Soap UI and
        start messing with settings until requests are accepted.
        There's no point asking the vendor for documentation
        because they probably don't know themselves.

Having just dealt SOAP API last week, I can relate to this so much. I'm glad that I'm not the only one feeling the pain here.

</comment></comment></comment></comment></comment><comment><USER18> My guess is that more and more people are coming to the realization that xml is great for fluid text and document formatting, but too ambiguous to serve as a data structure format.

XML nodes and children are just too slippery. I've actually argued with enterprise developers about why serving the following format was a terrible idea.

      <user>
    	<id>123456</id>
    	<name>Joe</name>
    	<account>Account 1</account>
    	<account>Account 2</account>
      </user>

<comment><USER19> Is there a hard and fast rule for deciding when something is an attribute and when it is a child?

I would have personally done

        <user id="123456" name="Joe">
    	<account>Account 1</account>
    	<account>Account 2</account>
        </user>

but I've never actually produced XML, only consumed.

<comment><USER18> Both ways still leave the structure ambiguous. Should <user> be mapped to an associative array of mixed objects, or to a fixed object using a custom mapper to shove the account objects into their own sub array.

<comment><USER15> If you're looking for a generalized way to map an XML structure to primitive types, you're going to have a bad time.

</comment></comment></comment></comment><comment><USER20> Not sure why the article equates XML with SOAP.

Request:

       GET /customers/43456 HTTP/1.1
       Host: www.example.org

Response:

       HTTP/1.1 200 OK
       Content-Type: text/xml; charset=utf-8

       <customer>Foobar Quux, inc</customer>

Seems fine to me. In fact, having named elements without the requirement for a dictionary makes parsing straight to an object-representation (without an intermediate property-list) much easier.

<comment><USER16> It never equates XML with SOAP. The point is that even while SOAP was being pushed by Microsoft, JSON was gaining mindshare among API developers, and API design was moving away from complex XML documents.

Using a simpler format for object serialization into XML is definitely an option, and it's a perfectly fine middle-ground between SOAPy verbosity and JSON compactness, but IMO it doesn't really have a lot to offer over a JSON version of the same API. Many API providers support both formats using content-type detection.

</comment></comment><comment><USER21> In my opinion, WS-* lost not because of the format or verbosity. WS-* lost because the concept is about the continuation of RPC, where you expose custom methods that can be invoked from a client. When state is altered in custom ways, complexity goes through the roof - to the point where you need a DSL (WSDL) to define these methods and how to interact with them.

REST simplified things because the concept is about limiting the method invocation to the bare minimum and always have an explicit understanding of the state that is being changed or communicated.

The XML/JSON question is not as important as the method/resource question.

<comment><USER22> The whole baked-in type system also adds a lot of complexity. On top of that you get the complexity that is xml it self (namespaces, while theoretically a good idea, are pure insanity).

</comment></comment><comment><USER23> "The essence of XML is this: the problem it solves is not hard, and it does not solve the problem well." – Phil Wadler, POPL 2003

SOAP takes XML's problems to the next level.

</comment><comment><USER24> Hold on to this, _" tldr: Simplicity and utility trump large corporate backing."_

When your manager tells you that your API needs to handle something "just in case", when your customer asks, "But what if I want to use this API with mumblefratz?", and when you look at your code and say, "Gee, if I make this a variable I could handle any special edge case by encapsulating its specialness in the variable ..."

</comment><comment><USER25> Pete Lacey's parody of SOAP is both hilarious and also very accurate:

[http://harmful.cat-v.org/software/xml/soap/simple](http://harmful.cat-v.org/software/xml/soap/simple)

</comment><comment><USER26> I've had the "fortune" to work with SOAP as well (java implementation) and I never could shake the feeling that it was designed with the intention of being obscure. It seems you could employ an entire batch of consultants just to deal with defining, implementing and changing SOAP APIs (kind of a misnomer I know). The whole change from SOAP 1.1 using an ActionHeader to SOAP 1.2 using an action parameter seems downright misleading. Or downloading WSDL files to automatically create Java classes sounds great in theory but now your program has additional obscure classes with _very_ weird syntax and you have to read through numerous reference guides just to know how you can modify the header of an outgoing request. Such a waste of time.

<comment><USER27> I also get to deal with SOAP occasionally. I recently got the joy of dealing with it for a CA's API.

It's clearly the result of developers and managers more interested in what the technology CAN do than what it should do.

<comment><USER13> In my experience, it wasn't that. Larger companies put value in supporting standards, because it is an important checkbox in their marketing, and SOAP is definitely a standard.

<comment><USER27> I was talking about how SOAP itself was designed.

<comment><USER13> ... oh :)

</comment></comment></comment></comment></comment><comment><USER28> One nice example of how MS really made things more complex with SOAP is the MSN Messenger Protocol (MSNP), which started out quite simple and sane, then got extremely SOAPy in the later versions; compare protocol interactions pre- SOAP:

[http://msnpiki.msnfanatic.com/index.php/MSNP8:Getting_Detail...](http://msnpiki.msnfanatic.com/index.php/MSNP8:Getting_Details#Example_SYN_Responses)

and doing the same thing with the SOAP'd version:

[http://msnpiki.msnfanatic.com/index.php/MSNP13:Contact_List](http://msnpiki.msnfanatic.com/index.php/MSNP13:Contact_List)

<comment><USER29> I think this is a great example of SOAP's failing. While it _is_ simple, it _looks_ difficult. As you scroll through all that XML your eyes begin to glaze and you don't even notice the small section at the bottom. Despite being the most important, the section is at the bottom, has weird grammar, and feels like an afterthought.

>Here the WSDL and XML schemas for the web service descripted here, you can use them to generate a web service binding for your programming language.

>MSN Addressbook/Sharing Service WSDL & XSD files

This is how simple it actually is:

[http://www.diveintopython.net/soap_web_services/index.html](http://www.diveintopython.net/soap_web_services/index.html)

<comment><USER28> I wouldn't consider requiring a ton of mostly redundant and useless information in messages (each namespace needs _a whole damn URL_ every time it's referenced? Does the parser use it, or even care that the entire URL is correct?) and XML parsing (which isn't _so_ bad, in comparison to all that redundantly redundant redundancy) to be "simple" at all. WSDL/XSD is yet _another_ layer on top of this mess of complexity and I suppose you're referring to the fact that it _looks_ simple if everything goes according to plan, but when it doesn't it's anything but simple. Trying to get any kind of performance out of it is another counterpoint to "simplicity"... This is all from the experience of someone who has worked with XMLA-based OLAP systems.

That link you gave has a summary part ( [http://www.diveintopython.net/soap_web_services/summary.html](http://www.diveintopython.net/soap_web_services/summary.html) ) that says "SOAP web services are very complicated."

</comment></comment></comment><comment><USER30> It's all about who has the power.

With JSON, if the data returned by the server doesn't exactly match the documentation, it's the client's problem.

With SOAP, if the data returned by the server doesn't exactly match the documentation, the server is broken. The client, reading the WDSL file which documents the API, will report an error and refuse to continue. This means bug reports the server provider cannot make go away by the usual defect-denial techniques.

</comment><comment><USER31> [http://www.google.com/trends/explore#q=wsdl%2C%20restful&cmp...](http://www.google.com/trends/explore#q=wsdl%2C%20restful&cmpt=q)

SOAP is past its peak but far from dead. In the Microsoft ecosystem, SOAP is nearly transparent, except for a bit of fiddling - you publish your WSDL from your definitions, I consume it to generate an API class on my end, and after maybe ten minutes on either side, we don't even think about SOAP again.

</comment><comment><USER32> It's funny that the joke starts with a dig at CORBA. When I was worked on a CORBA-based system a decade ago, I thought I'd never see something more over- designed. But this whole document-oriented web services thing makes me feel like: [https://screen.yahoo.com/unfrozen-cave-man- lawyer-1-22341242...](https://screen.yahoo.com/unfrozen-cave-man- lawyer-1-223412426.html).

</comment><comment><USER33> Sure, SOAP's complexity is a problem, but the issue with "RESTful" APIs is that they're so loosely defined, almost all the way to the other extreme. Being able to generate code and have a type-checked API, which is as easy to use as any other local API was a very nice feature we've now lost. I wish there were a better compromise.

<comment><USER34> There is a better compromise (in fact, several):

* Originally, Google Protocol Buffers. These are still in wide use; unfortunately, they never published/blessed an official RPC stack.

* Apache Thrift, aka Facebook's answer to Protocol Buffers.

* Capn Proto, by one of the Protocol Buffers authors, now has an RPC standard!

After having used Protocol Buffers extensively, I could never go back to untyped APIs. I'd at least use Apache Thrift for everything. Hopefully Capn Proto gets more languages supported for its RPC soon.

<comment><USER10> Protocol Buffers is great. Thrift generates much nicer C++ code but performs slower and wants you to do everything inside their networking world. I'm excited for Cap'n Proto. It's a good time to be doing binary IPC.

I'm still uncertain about melding the message format and RPC mechanics though. Part of me feels like network communications is just too big of a deal to abstract away into something that looks like a normal procedure call. But hey, even if that's always true for big systems, it probably won't be for smaller apps.

</comment></comment></comment><comment><USER35> SOAP Web Services around still frequently used in a lot of large corporations, where technology evolves a little slower and Microsoft products are still very popular.

Being a Rails fan myself, I have always enjoyed using HTTP Web Services and interacting with tech companies' Restful APIs so easily.

This post provided a clear, side-by-side comparison of the technologies including the historical context of SOAP, which I found really useful and enlightening. If I could give you some Bitcoin for writing it, I would. Have a new Twitter follower instead.

It's hard to find succinct, objective technology articles in this day and age. Most reviews I find are either unconstructively biased ("dynamic typing sucks!") or too long and convoluted to be effective.

</comment><comment><USER36> I always liked XMLRPC. It seemed really simple. At least in Python they simply mapped to function calls and all of the XML stuff was handled for you. It took minutes to get an API set up with that from any program.

I never understood why it's out of favor?

</comment><comment><USER37> I still have to use SOAP more often than I'd like to these days. It's a pain testing and dealing with all the different tools you have to use just to stand up a basic request.

A lot of vendors I've worked with will publish REST web services for public data but as soon as any private information needs to be accessed they use SOAP. I don't know if they just don't trust the tools to make REST secure or what but it's disappointing for sure.

Also the people who wrote the SOAP code are long gone which makes support for them even more difficult when I'm trying to get bugs fixed. REST server code has not been anywhere as bad to deal with.

</comment><comment><USER38> SOAP is still common in healthcare as many IHE profiles rely on SOAP for Cross-community document/data exchange. They are a pain to work with if you don't have a toolset that handles it well.

</comment><comment><USER39> The article lists

1) JSON coming up to replace XML as a serialization technology, and

2) and Ruby on Rails (etc)

I remember even serious pressure from w/i the XML community in the sense of XML-RPC, and the joke that the _entire_ _spec_ for XML-RPC was smaller than the Table of Contents for the SOAP spec. SOAP was tough. It was confusing to use (fwiw, I had the best luck w/ Perls SOAP::Lite) and difficult enough to implement that devs I knew simply abandoned it.

</comment><comment><USER40> New Finnish gov digital infrastructure is going to built using Estonian X-road (well next year). And yes, its only SOAP, so I guess either Finns are pretty crazy or SOAP is making a comeback. Go figure.

</comment><comment><USER41> The first thing I did as a developer was to write a SOAP wrapper gem for Propertyware's API. It was here that I learned the concept of Pain.

</comment><comment><USER42> Why I never used SOAP: Endian issues.

</comment><comment><USER43> Let's hope SAML follows soon.

</comment><comment><USER44> Apples,oranges and orangutans.

Doing transactions and data format evolution in REST is hard, in SOAP it is simple.

</comment><comment><USER45> You can't argue that PUT, DELETE, and POST methods are usable in a browser, and once a rest api starts going hogwild with headers, the GET really doesn't work either.

The fact REST didn't provide some way for all methods to be invoked in a simple browser was to me a step towards the inaccessibility of SOAP.

<comment><USER4> Rails addresses this by interpreting a special _method parameter:

[http://api.rubyonrails.org/classes/ActionView/Helpers/FormTa...](http://api.rubyonrails.org/classes/ActionView/Helpers/FormTagHelper.html#method- i-form_tag)

That is, a POST containing _method=delete will be interpreted as a DELETE.

It seems faintly silly; if you're exposing an API to the browser, why use methods that you can't use directly and then have to go to the effort of emulating them, when you could just use supported methods directly? Is the use of the proper methods really that important?

But it does work.

</comment></comment><comment><USER46> Heh...we're using SOAP and WSDL for this current project...

<comment><USER23> You have my sympathy.

<comment><USER46> Thank you.

And believe me - it was certainly not my choice.</comment></comment></comment>


Do Evernote clips solve link rot? - <AUTHOR>

I am a writer trying to create a portfolio of my web content over the last 4 yrs from a site that might die soon (why I'm looking for new work now).<p>My articles look fine cli[pped into in Evernote, and I can make individual article links (under 'sharing') so it's an ideal writing portfolio system, but when the site dies, will evernote links return a 404 message? <comment><USER2> If I'm understanding you correctly, it's fine to use Evernote for this purpose.

When you clip an article from the web, or a selection from a web page, Evernote doesn't just link to the original web site, it creates a wholly new copy of the content in your personal Evernote database. It stores the URL of where the content originally came from, but that's just metadata for your reference/information, and when you share a link to the clipped content you're sharing a link to content stored on Evernote's servers, not the original URL. After you've clipped content into Evernote it makes no difference if the original web site disappears.

<comment><AUTHOR> Yes, you are. Reassuring - thanks! Will do.

</comment></comment><comment><USER3> probably better to post the question in [https://discussion.evernote.com/](https://discussion.evernote.com/)</comment>


UEFI to make its way into mobile and non-PC markets - <AUTHOR> http://www.zdnet.com/uefi-to-make-its-way-into-mobile-and-non-pc-markets-7000015138/ <comment><USER2> I remember when people here said UEFI is nothing to worry about since it "only" really affects ARM devices. But what happens when the ARM devices are the most used "computers" are the most used by far in a few years?</comment>


Introducing visual search - <AUTHOR>

We've just launched a pretty cool and innovative feature at Labels.io called visual search. To get a better grasp of how it works have a look at http://labels.io/mediademo and click on the tags. Since we've really just launched it, it's probably not entirely bug free - if you run into any weird behavior I'd appreciate if you could reply here and let me know. Otherwise all comments are welcome!<p>Octavian <comment><AUTHOR> Thanks - we've called it visual search because it basically allows you to go cherry picking by selecting skills or other attributes you're interested in (e.g. active job seeker) from profiles or search results.

Say you're looking for an Ajax developer - you'd start by looking for "ajax" only, then keep clicking on tags until you've found the perfect match - a bit similar to browsing a supermarket's shelves and adding stuff to your basket (that's where the term "visual search" originates from :)

About the link - I'm not sure I can make it clickable...

</comment><comment><USER2> Really nice. I think it will be very practical with touch screen devices.

I'm not sure "visual search" is an appropriate term though, I was expecting "image search" or something. This seems more like "tag-label-in-search-box search". (perhaps just me)

(btw, make the <http://labels.io/mediademo> clickable?)</comment>


Google joins Hedera governing council - <AUTHOR> https://cloud.google.com/blog/products/gcp/working-with-hedera-hashgraph-to-support-the-next-generation-of-distributed-ledger-technology <comment><USER2> Very interesting move</comment>


Show HN: Handwritten.js – Convert typed text to realistic handwriting - alias-rahil https://github.com/alias-rahil/handwritten.js#README <comment> alias-rahil Many times I get university assignments that are compulsory to be submitted as handwritten document. Most of the information needed for the assignment is available on the internet so why not save time? Just make a text document and let handwritten.js do the writing part!

example: [https://raw.githubusercontent.com/alias- rahil/handwritten.js...](https://raw.githubusercontent.com/alias- rahil/handwritten.js/master/screenshots/lorem-ipsum.jpeg)</comment>


20-year-old Military Weather Satellite Exploded in Orbit - <AUTHOR> http://spacenews.com/20-year-old-military-weather-satellite-apparently-exploded-in-orbit/ <comment><USER2> Total knee-jerk amusing tin-foil-hat theory: Somebody in the US military wanted to test a satellite-killing system. Maybe the X37B left an orbiting payload containing a satellite-to-satellite laser...

Seed some stealthy units ahead of time, let then linger until you need to start taking out enemy surveillance/communications.

<comment><USER3> China has satellite-killing technology already deployed. This is more likely to have been a result of that being tested than anything else ..

</comment></comment><comment><USER4> military weather satellite... weather... exploding.... yea sure... What did they meashure the weather with??? Warheads?

Edit: I know perfectly well that sattelites carry small amaounts of fuel, but this is just too... hmmm</comment>