The case for an antibiotics tax - <AUTHOR> http://www.washingtonpost.com/blogs/wonkblog/wp/2014/01/13/the-case-for-an-antibiotics-tax/?wprss=rss_ezra-klein&wpisrc=nl_wonk <comment><USER2> This is a great idea. The point of a tax is to impose penalties that exist in real life, but are not part of the original transaction: externalities. Widespread use of antibiotics has a cost associated with it that must be paid by someone, and it should be part of the price of antibiotics.

Much like there's a cost associated with income inequality, so we tax the rich more to supposedly cover that cost. Costs associate with pollution, greenhouse gases, moral hazard, etc. are all risks and costs that must be mitigated at the transaction level, otherwise the market fails.

<comment><USER3> > Much like there's a cost associated with income inequality, so we tax the > rich more to supposedly cover that cost.

That's a fairly disturbing way to frame progressive taxation. In the other examples of taxing externalities, we intentionally discourage the behavior by taxing it. Do you intend to discourage people from becoming rich by taxing it? Also, it takes both rich and poor to have inequality. Why not tax poor people more to discourage poverty?

<comment><USER4> There are some economic/social theories that suggest homelessness is an adequate and necessary deterrent to poverty.

However, I'm not going to address a flaw in your logic, namely that the only role of taxation is deterring undesirable behavior.

<comment><USER5> >There are some economic/social theories that suggest homelessness is an adequate and necessary deterrent to poverty.

Is the implication here that if homeless didn't exist, it would actually be ok to tax/punish poverty? Otherwise why even bring that up?

</comment></comment></comment></comment><comment><USER6> The basic problem is that one intervention is seeking to fix another. Crop subsidies are the reason why these antibiotics are so widely used. Farmers are encouraged to feed animals food they aren't meant to eat which makes them so sick they need antibiotics to stay alive long enough to be slaughtered.

Just end those crop subsidies and let things take care of themselves. A few agribusinesses will be pissed but the rest of us will be much better off.

<comment><USER7> Or ban feeding an animal something that is not part of its "natural" diet. Then we have the fun of debating if cows naturally eat corn and soy. Chickens will be particularly fun because they historically ate the scraps from the humans (what we now call "compost" :P), they were the old form of food recycling.

<comment><USER8> I'm pretty sure human beings are not "supernatural" beings, therefore everything that we do including feeding cows stuff that makes them sick is "natural".

Now if humans are "supernatural" than cows are also "supernatural" because they've been created by humans. Cows are a product of centuries of human genetic engineering.

<comment><USER7> You're attempting to be funny by giving the word "natural" too much thought. I stuck quotes around the term for people like you.

Natural being defined as something their bodies are "designed" (have fun with that one) to digest.

</comment></comment></comment></comment><comment><USER9> My fellow libertarians:

Milton Friedman, freedomist gadfly, was in favor of government regulation to protect the population from contagion. The regulation and restriction of antibiotics falls firmly within even a minimalist state's purview.

In other words, the government has a clearer mandate to restrict antibiotic use than it has to restrict heroin use.

<comment><USER10> >Milton Friedman was in favor of government regulation to protect the population from contagion.

I'm gonna call source since none of the literature I've read from Friedman holds such a position. If anything the whole prescription drug system should be abolished and drugs should be marketed directly to consumers.

<comment><USER9> I think Milton would agree with you regarding abolishing the prescription drug system.

The (only?) exception being antibiotics, which contributes to contagion.

Source was an interview which I watched, so... it'll be hard to find.

EDIT: Never count out Google!

"FRIEDMAN There is room for some public health activities to prevent contagion, such a thing as for example.."

[http://www.hoover.org/multimedia/uncommon- knowledge/26936](http://www.hoover.org/multimedia/uncommon-knowledge/26936)

<comment><USER10> >FRIEDMAN There is room for some public health activities to prevent contagion, such a thing as for example..

And then Friedman gets cut off when he is about to get into the examples. Knowing Friedman I would assume his examples would consist of incidents that the the private industries have quite a deal of trouble handling such as a violent outbreak or an extreme vaccine shortage.

I would not play off Friedman's words to call for regulation, taxation, or any other restriction of free trade for antibiotics.

<comment><USER9> Antibiotics _do_ constitute a violent outbreak, or at least direly threaten to release one.

<comment><USER8> An antibiotics tax won't solve anything.

About the only effective thing you can start doing is MSRA wards in hospitals and a system of rotating antibiotics. Developing new antibiotics would probably also be a good idea, no idea what the situ looks like there.

<comment><USER9> A tax won't solve anything, agreed, unless it's on the order of 10,000% or more.

Restricting antibiotics (further than they are currently) may or may not help, but is certainly within the purview of a limited libertarian state.

Restricting most (all?) other medications is not.

<comment><USER11> Antibiotics are used in commercial farming because they increase weight. The tax simply needs to be enough that (weight(antibioticked cow) - weight(non- antibioticked cow))*(price of beef) < (cost of antibiotics). Maybe that's "on the order of 10,000% or more", but I'd like to see numbers.

<comment><USER9> Antibiotics are overused outside of commercial farming too.

<comment><USER11> Yes, but commercial farming is the single largest use of antibiotics. Cutting out that use would significantly improve things. We should continue to address other issues (educational campaigns hammering home the fact that antibiotics do nothing for viruses, and encouraging completion of the full course when you _are_ taking antibiotics).

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> But how do you fix antibiotics abuse in other countries? Antibiotic resistant bacteria are spreading a lot faster in Russia, Pakistan, India, South East Asia and Latin America. And with international tourism growing it is just a matter of time before it reaches everywhere in the world.

<comment><USER13> There is not so much problem of antibiotics overuse in poorer countries as there is a problem of antibiotics misuse. Where antibiotics are expensive people tend not to take them long enough so they fail to kill bacteria that were sligtly resistant to the antbiotic and this also contibutes toward increasing antibiotics resistance.

You could probably do a lot of good by requiring from the pharmaceutical companies that want to sell antibiotics on american market to ship half of their production to Russia and such for free. That would increase price of antibiotics for americans to prevent overuse and make them available in poor countries to prevent misuse.

</comment></comment><comment><USER14> There are two components to anti-biotic use that are taken together very harmful. The first as has been amply described by the author is the flat over use of anti-biotics where they are not needed. The second and perhaps more relevant human example is that humans tend not to finish their full course of anti-botics allowing resistant mutations to gain a greater foot hold. Other than long acting or implanted delivery mechanisms I am not sure that we can ever really ensure compliance with the full regimen in all patients.

</comment><comment><USER15> I feel that the problems we face with antibiotics is similar to those we face with oil. It's common knowledge that the two will _disappear_ and there's people out there fighting to try to protect us and we have a silent majority going about their business and ignoring all the warning signs. So yeah, tax 'em

</comment><comment> m-photonic From what I've heard, in parts of Asia it's common for antibiotics to be sold over the counter, and a lot of the worst drug-resistant strains come out of the developing world. It's a much bigger deal than American agriculture, given the classes of antibiotics involved.

</comment><comment><USER16> Or we could ban giving them to animals

<comment><USER17> That's too blunt of an instrument, though. Antibiotics still have legitimate veterinary uses.

A small tax per unit might stand a better chance, though. Something that might not be onerous at the low quantities one typically buys antibiotics for when they intend to use it legitimately, but adding up to something prohibitive in the mass quantities needed for industrial-scale prophylaxis.

</comment></comment><comment><USER18> There was recently an interview posted here on HN about the end of antibiotics ([http://www.pbs.org/wgbh/pages/frontline/health-science- techn...](http://www.pbs.org/wgbh/pages/frontline/health-science- technology/hunting-the-nightmare-bacteria/dr-arjun-srinivasan-weve-reached- the-end-of-antibiotics-period/)). In short, the interviewee Dr. Arjun Srinivasan was pleading for a serious conversation about what to do to further regulate their usage, because some bacteria are developing increased resistance to most, if not all, antibiotics available. What's stunning to me about all these articles is that, after all these alarms have been raised and as all the people responsible seem to be contemplating solutions to regulate antibiotic usage, nobody's mentioning alternative methods to fight bacteria. Following the afore mentioned article one commenter remarked that Dr. Srinivasan did a great job or spooking us, but there was absolutely no mention of bacteriophage during the interview, which got me curious. Turns out phage therapy ([http://en.wikipedia.org/wiki/Phage_therapy](http://en.wikipedia.org/wiki/Phage_therapy)) has been used successfully for close to 100 years in Russia and Georgia. According to this Wikipedia page [http://en.wikipedia.org/wiki/Bacteriophage](http://en.wikipedia.org/wiki/Bacteriophage)

        Phages were discovered to be antibacterial agents and were used in Georgia and the United States during the 1920s and 1930s for treating bacterial infections. They had widespread use, including treatment of soldiers in the Red Army. However, they were abandoned for general use in the West for several reasons:

            - Medical trials were carried out, but a basic lack of understanding of phages made these invalid.
            - Phage therapy was seen as untrustworthy, because many of the trials were conducted on totally unrelated diseases such as allergies and viral infections.
            - Antibiotics were discovered and marketed widely. They were easier to make, store and to prescribe.
            - Former Soviet research continued, but publications were mainly in Russian or Georgian languages, and were unavailable internationally for many years.
            - Clinical trials evaluating the antibacterial efficacy of bacteriophage preparations were conducted without proper controls and were methodologically incomplete preventing the formulation of important conclusions.

        Their use has continued since the end of the Cold War in Georgia and elsewhere in Central and Eastern Europe.

In other words the reason why western countries stopped considering them, and to some extent continue to shun them, is lack of understanding.

I am wondering then, if we have to have these "serious conversations" about regulation of antibiotics for the sake of the threat posed by over- consumption, how serious can it really be if we have to wear blinders and continue to pretend that what the Russians and Georgians have been doing is utter sorcery?

<comment><USER19> It isn't actually a "lack of understanding" \- I was doing research into phage therapy over a decade ago, and the field has progressed since then.

There are however a number of problems with phage therapy, and this is from the perspective of someone who _likes_ phage therapy:

\- Phages are usually very bacteria specific, there isn't really a "broad spectrum" phage. The therapy used in Russia and Georgia is often a bespoke formulation for each individual patient. This is:

a. Really, really hard for the FDA to approve. b. Expensive as all hell. c. Involves keeping "banks" of phages around, and creating custom cocktails of them. This is, as mentioned, expensive as hell, and manpower intensive.

\- Phage therapy is fairly novel in the West, due to some problems in the early days of phage therapy followed swiftly by the discovery of penicillin. It's an entirely different method of treatment, which means all the clinical knowledge doctors currently have is invalid, and has to be relearned. That's tough.

\- There's no promise a bacteria _has_ a phage associated with it, and synthetic phages are, at this point, a pretty distant prospect.

\- When bacterial cell walls rupture, they create endotoxins. Endotoxins are bad - indeed, in the early experiments with phage therapy in the West, insufficiently pure phage solutions with endotoxins in them were responsible for some deaths. Right now, phage therapy is most often used in dire cases, where side effects like that are less of a thing. For a bad case of Strep throat? There's some serious clinical trials that need to be done.

\- It's a hell of a lot harder to give someone a 14 day course of bacteriophages to take home than it is a 14 day course of antibiotics.

Phage therapy is a really fascinating field, and I think it has a lot of potential. But to say we shun them due to a lack of understanding, or acting like what the Russians and Georgians do is "utter sorcery" ignores a great deal of the research that takes place here. The real problem is, even while we struggle with resistance, antibiotics are _profoundly_ superior as a general purpose drug. The reasons the Russians used them so heavily is because they had trouble getting antibiotics.

But seriously, "What about phages?" isn't exactly a new idea.

</comment></comment><comment><USER20> I've read that the most effective way for the state to control the public's behaviour is a combination of taxes and subsidies (sorry, don't recall the source). Simply tax bad behaviour and subsidize good behaviour. Other means are possible, but less efficient.

The user fee could work, depending on the scale... if it is possible to be small enough to not deter individual use, but large enough to deter mass use in agriculture, then it stands a chance.

As an aside, the common practice of municipal hotel taxes never made sense to me. Wouldn't a city wish to _encourage_ people to visit?

</comment><comment><USER21> Too little, too late. There was a CDC report that the 'age of antibiotics' is over and there is little point in limiting their use now. Lets move the conversation on to something productive: what next?

<comment><USER22> Bollocks. The complete loss of effectiveness of antibiotics is not something that has already happened; they are still saving lives as I write this post. It is something that will happen if we don't change our behavior. Whether we change our behavior quickly enough has still to be decided.

<comment><USER21> The opportunity to prevent the creation of antibiotic-resistant diseases is gone, that is the point. Go ahead and use your antibiotics, and if you are lucky they will do something.

Its useful to think in more than black and white. But sometimes thresholds are crossed; the 'prevent the creation of difficult diseases' threshold has been passed years ago.

</comment></comment></comment><comment><USER23> The primary use-case of antibiotics remains: curing bacterial illnesses.

We should not seek to increase the price of this for the least well-off in society.

This would potentially have a net negative effect as it allows bacterial infection to spread, requiring increased antibiotic use.

Besides, a tax on use wouldn't impact upon doctor's behaviour in the desired way (reduce non-essential use): since the doctor is still making a net profit from the prescription and it (still) acts as a convenient placebo.

<comment><USER24> RTFA. It's a tax for use of antibiotics on livestock, not humans.

<comment><USER25> Which the cost will be passed along to the consumer.

<comment><USER23> I'm sorry that you've been downvoted - because you are right.

This is a tax on poor people that won't affect the majority of readers... it increases the minimum cost of producing meat.

If we can't figure out high-production meat farming then eventually we're saying that meat should be something only for the wealthy.

<comment><USER11> If it's a choice between meat being something only for the wealthy and a prevalence of untreatable bacteriological infections, I'm going to go with the former.

</comment></comment></comment></comment></comment><comment><USER4> > The agency is asking the makers of animal drugs to voluntarily alter their > labels so that farmers can no longer buy antibiotics to promote animal > growth (a fairly common practice).

I was under the impression that growth is secondary to supplementing the animal's immune system, especially since factory farms are terribly unsanitary.

<comment><USER26> I think that it's everything together. Basically, giving animals antibiotics means that you have more animals (and animal weight) which can be sold at market. If it were more expensive to give antibiotics to the animals, farmers might rethink the equation, deciding to instead raise more, smaller animals in more sanitary environments.

Michael Pollan's excellent book, "The Omnivore's Dilemma," describes at great length the way in which non-factory farms operate, and why he believes they don't need the same sorts of sanitary rules that the government places on factory farms. I have no way of knowing whether he's right, but there's definitely some logic to the claim that antibiotics are addressing the symptom, rather than the root cause.

</comment></comment><comment><USER11> I think this is clearly a good idea. Tax antibiotics, use the revenues to help subsidize development of future antibiotics.

</comment><comment><USER27> You would think we'd learn by now that when someone proposes a tax to control behavior, it's not about the behavior, it's about finding a justification to grab money. For example, the soda tax.

Why not treat them as controlled substances? All you need is a propaganda campaign a la Barry Bonds, et al.</comment>


Google Public DNS: 70 billion requests a day and counting - <AUTHOR> http://googleblog.blogspot.com/2012/02/google-public-dns-70-billion-requests.html <comment><USER2> Just to add a couple data points:

      1) Tons of random indy web crawlers, mail cannons, etc. use Google Public DNS.
      2) We actively discourage large machine-based usage of our service.

Even with some aggressive handling of large machine-based users, we still grow at a crazy clip.

Our growth: <http://i.imgur.com/znfu9.png>

<comment><USER3> Any idea on the limit for "large" machine based usage?

For examples, I use it with a PHP script that hits it a few hundred times and have not yet had a problem. Should I be expecting one?

<comment><USER2> We had a 500 cluster web crawler using us. Probably doing about a billion queries a day. They had the option to pay us or switch to Google Public DNS. Guess which they did? :-)

A few hundred, even if a few hundred per minute, is not a problem.

<comment><USER4> I have operated a rather large crawl cluster on EC2 (several hundred nodes), and I don't see why anyone would point one at a third party DNS service.

we operated for about 6 months using the default resolvers than come with the AMIs, then Amazon contacted us, telling us they wanted us to stop using their recursive nameservers... apt-get install bind, point at 127.0.0.1, redeploy AMI, done (in under 5 minutes).

it isn't as if a crawler cares about an extra 250ms from non-cached entries, and the bandwidth from DNS is trivial* compared to that of downloading pages.

... so why would anyone ever offer to pay you/anyone else for a recursive DNS service? it's a trivial problem...

(* say 32 bytes for the query, 64 bytes for the response... 1B lookups is ~64gb, or $3.50 with Amazon's very expensive bandwidth costs)

<comment><USER2> 250ms matters. That's 1/4 of a second. It matters for a crawler tremendously.

DNS query sizes are wrong. I'd double each. But still, inexpensive from a bandwidth standpoint. I get it.

<comment><USER4> why would it matter at all, given a crawler hits many pages on the same hostname? the fact the initial request takes 250ms more is meaningless.

when you also take into effect that crawlers are either: bound on sleep() if they're friendly, bound on cpu if doing processing and you have a lot of money for bandwidth, or if you don't have much money, bound on bandwidth.

and given that crawlers tend to be massively parallelised, the DNS query could take minutes and you really still wouldn't care...

(go and read up on Amdahl's law)

</comment></comment></comment></comment></comment></comment><comment><USER5> Being in the information security world, I have to wonder what percentage of these requests are based in malware? I know at least the latest version of ZeroAccess/Max++/Sirefef (which we managed to get before the AV vendors released definitions for it) uses it quite heavily. That's one of the symptoms we used to diagnose computers from a strictly network-level standpoint. No one on our network should be using Google DNS, so any computers who were making requests to 220.127.116.11 were likely infected (confirmed using other signatures).

That amounted to about 100 requests every day per infected computer just from us, and ZeroAccess isn't the only one doing it (and isn't a rare trojan).

</comment><comment><USER6> For those thinking about changing their DNS servers, you might want to take a look at <http://code.google.com/p/namebench/>

It benchmarks global (like Google Public DNS and OpenDNS) and regional DNS providers to show which DNS servers would be fastest for you.

</comment><comment><USER7> For comparison, OpenDNS does ~37bn <http://www.opendns.com/technology/traffic- stats/>

</comment><comment><USER8> That's a little over 800,000 requests a second on average. That's some serious traffic.

</comment><comment><USER9> I'm wondering if there's a detectable peak in people switching to Google DNS because of censorship in countries like .be & .nl

</comment><comment><USER10> I just switched to Google DNS. Before I switched I got a 38ms response time when I ping google.com, now I get 285ms? I'm in the UK. Is this why it's slow?

<comment><USER11> DNS has nothing to do with ping response times. A ping requests the IP address from the DNS server and then does the ping. On most systems the DNS is cached locally, so multiple requests will use the same information.

<comment><USER12> _DNS has nothing to do with ping response times._

Not true, the feature is called GeoDNS and gives you different IP addresses for the same domain based on your DNS server. See Locke1689's reply.

</comment></comment></comment><comment><USER13> Glad they're doing something about the CDN issue. This is the main thing that keeps me from switching to Google DNS.

</comment><comment><USER14> I used to use this but switched off over security concerns (Mainly because I didn't want Google everywhere)

I haven't noticed any difference in load times so I guess it didn't do any harm.

<comment><USER15> It would be funny if they suddenly dropped the service because it wasn't generating a good "revenue stream". It would be chaos for awhile.

</comment></comment><comment><USER16> I would be interested if statistical data gleaned from DNS makes it's way into any other service areas. DNS would seem like a useful way to rank the popularity of web sites, I am sure there are some interesting enhancements that could be made using that data.

<comment><USER17> I think their privacy policy disallows it: <http://code.google.com/speed/public-dns/privacy.html>

> We don't correlate or combine your information from the temporary or > permanent logs with any other data that Google might have about your use of > other services, such as data from Web Search and data from advertising on > the Google content network.

And they say that the logs are only used for debugging, DoS protection and abuse.

<comment><USER18> The quote from the policy says nothing about using or not using the information about what DNS queries are made for data mining or ranking.

<comment><USER17> Data mining and ranking is neither debugging, nor DoS protection or abuse protection, so I don't see how it could be allowed.

The FAQ makes it even more clear:

> Is information about my queries to Google Public DNS shared with other > Google properties, such as Search, Gmail, ads networks, etc.?

> No.

<comment><USER18> I did not mean "my queries" being "shared" but the query collection/archive as a whole. It would be another source to know what domains ___the people_ __visit.

> And they say that the logs are only used for debugging, DoS protection and > abuse.

Source?

<comment><USER17> Rereading it, I see it's less clear how it applies to aggregated data.

</comment></comment></comment></comment></comment></comment><comment><USER19> I for one am very thankful for this DNS. Ever since moving to China, 188.8.131.52 has useful for getting around various flaws of the internet experience here. Even with a paid VPN, it's nice to have an always working DNS server.

</comment><comment><USER20> It seems like Google's DNS servers are always MANY hops away from me, no matter where I am. The ping times range from 8ms to 45ms.

How is that faster than using a local DNS server?

<comment><USER21> Obviously it cannot be faster than a local DNS cache/server (for the RTT). What can be significantly faster is forwarding queries to Google Public DNS instead of your ISP. At least in my experience, ISPs often have slow and overloaded servers which are not well maintained. Recursively resolving completely on your own is often even slower than either of those two choices.

<comment><USER22> ISPs often also have abusive DNSes that redirect unresolved domains to ad- ridden landing pages, which is why I switched.

</comment></comment></comment><comment><USER23> What an enormous data mine.

<comment><USER23> Down votes for pointing out that Google DNS is an enormous data mine? Why?</comment></comment>


Ask HN: How can we contribute towards the open source community? - <AUTHOR> We run http://draftss.com where we offer graphic design on a subscription model to our customers.
We love using a lot of open source projects at our workplace and would love to give back to the open source community. Is there any way we as draftss.com could help the community? The first thing that strikes our mind is open source project websites are very poorly designed and we could help them there, but we are not sure.
Would love to hear your thoughts. <comment><USER2> The open source community is sadly lacking in UX and design in general (partly because of funding, but also stupid attitude) so maybe you could offer those services to projects that are in need?

Look for big open-source apps that are lacking in UX (pretty much all of them - I think Firefox is the only exception really) and see if you can help them. Keepass for example could be a good candidate - solid product, and could definitely compete with 1Password & co if it wasn't for its outdated design.

<comment><AUTHOR> Rightly said. We think that UI/UX is not taken seriously by the open source community. Keepass looks like a fantastic alternative to 1Password. Will definitely connect with them.</comment></comment>


Steve Jobs brainstorms with the NeXT team - <AUTHOR> http://thenextweb.com/shareables/2011/11/20/watch-steve-jobs-brainstorm-with-the-next-team-in-this-fascinating-video/ <comment><USER2> I recognised his trademark passionate speech (02:43) about using technology to improve education. Laden with superlatives, it's just like every Apple product launch since the iPod.

It's a great pity that education hasn't actually changed a bit in the intervening time. Computers are pretty much just used for teaching computers, as electronic typewriters and libraries, and to cut down on admin. They really are not used as learning aids, as 'simulated learning environments' or anything similar.

There's still a huge way to go in using IT in education. I think the Khan Academy is one step, the opening up of journals is probably another. We're a long way off what Jobs visualised even back in the late eighties.

<comment><USER3> Actually, his primary example of "simulated learning" is more modest than you put it. Essentially, researchers really did and still do want to have computers as a tool for performing experimental simulations and using computing for communication. Computing has been "marvelous" in advancing what scientists have been able to in the past couple of decades, and Apple is still very prevalent here today.

For example, even today the "workstation" is still quite common in labs. Where I work, I see a lot of 8-core Mac Pros. Huddled away under desks are old G4s and G5s. What do we run on these machines? MATLAB, Mathematica, heavy Fortran compilers, expensive microscopes, and almost-real-time experimental setups. In other words, all stuff vital to scientific experiment and computation.

Yes, he broadly lectured on "higher learning," but it is no surprise to me that the Web was born on a NeXT computer at CERN and not anywhere else. On the other hand, it is true that we have not seen the "simulated learning environments" or other AI-esque dreams from the 80s materialize in modern computing. At least not as we thought we understood them: OpenCourseWare, Khan Academy, and Stanford Online Education have begun to revolutionize the "learning" half. And as for open publications, well, the arXiv is 20 years old now (nearly the age of the Web!), the NIH requires open access 6 months after publication, etc. We're definitely not there yet, but I think we're on the right track.

If there were one thing though which would mark a great leap in progress, it would be Open Data. The incentives don't really exist today for open data--- data can be like a trade secret to be hoarded for publications, and getting ahead in academia is all about getting there first before you get scooped. We need broad, systemic changes.

</comment></comment><comment><USER4> Great to see this old NeXT stuff.

I still have my NeXTStation Turbo Color, and shockingly, it still runs! Other than my current iMac, it's easily my favorite computer ever. To be using a NeXT in the early 1990s truly was like being 15 years ahead of what everyone else had.

<comment><USER5> God I miss mine. I put mine out on the curb on moving day, after graduation, because I didn't have enough room in the car. I changed my mind and went back to get it and it was gone not even 15 minutes.

Whoever took her from Pheasant Run Crossings, I hope you're treating her well.

</comment></comment><comment><USER6> The original youtube link was posted on HN three times in the past day...

<http://news.ycombinator.com/item?id=3257547>

<http://news.ycombinator.com/item?id=3258750>

<http://news.ycombinator.com/item?id=3258731>

Apparently reading HN is all it takes to be a breaking tech news blogger theses days =P

<comment><USER7> Hah! Yeah, sorry didn't see those. This video was originally posted by Layar CEO Raimo van der Klein here: <http://cl.ly/2J0d1v2K1F3x3y3F401T> Right around the time that Jobs resigned. I had it tucked away in Instapaper as it was hosted on a Dutch video sharing site that also shared a lot of Porn and I would rather share it from a YouTube upload.

When I saw the YT link for this video posted on Twitter (probably via someone browsing HN) I found the other two from Slomacuser and thought that they would be a good counterpoint.

Good stuff tends to surface to HN though, so I'm not surprised it ended up here multiple times.

-Breaking Tech News Blogger

</comment></comment><comment><USER8> 11:00 in the video is a fascinating example of someone standing up to Jobs' reality distortion field.

<comment><USER9> That's Joanna Hoffman, who was also part of the Macintosh team. The Isaacson bio shares an anecdote about how the Mac team would annually give out an award to the team member who had proven most able to stand up to Jobs, and Hoffman won it the first two years. It was fun to see an example of why.

<comment><USER7> Thanks! I didn't recognize her. Added that info to the article.

<comment><USER10> What is her accent? It really is fascinating.

<comment><USER11> Sounds German to me, which would fit with her name.

</comment></comment></comment></comment></comment><comment><USER12> Oh man the 80's were really something. This is some seriously nerdy (but great) footage. One thing they weren't short on was vision, seems like that was in abundance (along with hair) back then.

</comment><comment><USER13> I love how the "boss" is sitting on the floor while most everyone is seated on the couch.

"...and if we can't do that, then we outta go broke"

</comment><comment><USER14> Thanks for posting, watched every video on it and found it fascinating indeed.

A few new revelation from them: Jobs' businessman side, NeXT's email client is far more advanced and sophisticated/simple than our current email clients, and Spinning Disk Wait Cursor has originated in NeXT.

</comment><comment><USER15> "Take a really expensive technology and pull it down to a price point that is affordable". That's what he did with the iPad too.

<comment><USER16> That might have been NeXT's goal, but they didn't achieve it.

In the video, Jobs says that three grand is the upper bound on what their polled potential customers are willing to pay. The first NeXT cube had a base price of $6,500.00. They also didn't meet their original deadline either, going over by more than a year.

<comment><USER15> Startups are hard; even for Steve Jobs.

If you think about it, when he went back to Apple, he didn't have to worry about logo, coffee machines etc.

In fact, one point he made on the video was that over at NeXT they had forgotten "how to be scrappy", and hustle for discounts.

</comment></comment></comment><comment><USER17> Jobs had a lot of uncertainty about what NeXT should build: very interesting part is around 15:52 where he says it isn't his job. He basically says that someone has to define it. It seems that he was just telling people to figure it out themselves and not providing much leadership. Would have been fascinating to see how it was resolved and Jobs's role: how much input comes from him versus his role as a facilitator.

</comment><comment><USER18> I see a bit more stuff about NeXT getting posted around, I suspect this is because of Jobs' passing.

It got me wondering : although a commercial failure, this computer made a big impact. I wonder if, in 20 years time, all the cool kids will have an old NeXT on prominent display in their home? What other bits of hardware/software combos are going to be classics?

<comment><USER19> I think there were only about 50,000 NeXT machines ever sold, so there may not be enough to go around for all the cool kids.

<comment><USER18> That's what I mean - with a very limited supply, unique (and durable) design, first-machine-on-the-web status and the steve jobs connection, I can see this becoming an investment grade collectible at some point. They cost between $500 and $2000 for the cube (which will undoubtedly be the one to have) now, I can see a future scenario where they are going for 10 times that at auctions, particularly if they have provenance (ie owned by a famous person, Next developer, used at a demo by jobs, etc).

<comment><USER19> Well, I have a Cube and a mono slab. If you're right, I'm set for retirement.

</comment></comment></comment></comment><comment><USER20> I want to know more about NeXT. Particularly interested in the details surrounding the fact that the goal was spring 1987, but actual release was fall 1988.

Perhaps the Isaacson biography covers it? Any other literature I could refer to?

</comment><comment><USER21> Go to 16:50. If you ever feel like you're scrounging for pennies in the couch: everyone does it and it's part of business at any level. It's typical for startups to spend a huge amount of cash when they get funded and pay full price for everything as word gets out they're flush with cash. It takes a while to develop a culture of being cheap.

e.g. the last time I worked in someone else's startup (6 years ago) I remember looking around the room and thinking that every one of the $2000 desks that were bought from a local artist is a server we could have bought.

</comment><comment><USER22> The author's assertion that this is better than Isaacson's coverage of the same topic rings hollow. Isaacson definitely addresses the hallucinatory '87 deadline, Joanna's resistance, the "honeymoon is over" intro to the second Pebble Beach meeting. I wouldn't be surprised if Isaacson had access to this video as a source.

That said, it's a different perspective, which is nice. I just disagree with Panzarino's implicit assertion that a) Isaacson's biography missed this, and b) this gem of a video fills that purported void.

<comment><USER7> Niels, it definitely wasn't my intention to imply that Isaacson don't touch on these matters at all, because he did. However, I must stick by my assertion that the discussions of Jobs' motives and methods during this era is very, very light. This video adds a significant amount of color to the conversation about NeXT and the way that he interacts with the staff is fascinating.

So yes, he may have pulled some quotes from the players involved, but I feel that this short video tells you more about Jobs' operational methods at the time than the entire section on NeXT in the bio.

Thank you very much for your thoughts though, it is definitely a possibility that this was part of the material used by Isaacson, good point.

</comment></comment><comment><USER5> Wow, in the 4th video, where he's showing off NextStep mail application, the definition of smooth scrolling has definitely changed over the decades.

<comment><USER23> That being said, after watching this video it struck me how little innovation has being going on in the email space.

Granted, change for change's sake is not always a good thing, but for a video made before I was born it seems strange that even the mail.app that ships with Lion still hasn't fundamentally changed from its neXt forebears - we still have the three large horizontal textboxes on top of a large textarea for the body, and everything seems to function in exactly the same manner.

No wonder people my age barely use email anymore. A subject line? really?

<comment><USER24> What's wrong with the subject line? I'm genuinely interested in the post-email phenomenon. Us old timers sometimes would sometimes put a whole short message in the subject line, giving roughly the functionality of an instant message.

</comment></comment></comment><comment><USER25> Is the guy skeptical about the software delivery Rubenstein (who later went to Palm)?

Looks a bit like him.

<comment><USER26> I think that's George Crow. SJ addresses him by name at one point in that video.

</comment></comment><comment><USER27> Fascinating. I'd also love to see the Lotus 1-2-3 segment. Anyone know where that is?

<comment><USER28> I'd like to see the whole video. Here's some info on it - not sure where to actually get a copy though <https://catalyst.library.jhu.edu/catalog/bib_1261137></comment></comment>


Irving Wladawsky-Berger: Extreme Scale Computing - <AUTHOR> http://blog.irvingwb.com/blog/2010/02/extreme-scale-computing.html <comment><USER2> Wow, it's very high level but exhaustive in coverage with lots of links; for example, just what will be required to build practical exaflop systems?

One minor detail is that as you scale the CPU etc. 1000 times, you're only going to be able afford a 10 fold increase in power ("It is generally agreed that an exaflop system must consume around 20 MWs [!!!], otherwise their operating costs would be prohibitively expensive").

Recommended.</comment>


Mark – A simple and unified notation for both object and markup data - <AUTHOR> https://github.com/henry-luo/mark <comment><USER3> So this is _literally Lisp_ , just with curly braces instead of parenthesis :).

I don't understand this part of the readme:

> _The advantage of Mark over S-expressions is that it is more modern, and can > directly run in browser and node.js environments._

Does this mean I'm so out of date with JS that this syntax is actually legit JS? Or does Mark run its own parsers, at which point it's just like sexps, except it uses the "more modern" curly brace instead of "less modern" parenthesis?

<comment><USER4> > So this is literally Lisp

No, it's close to S-expressions, but it's not a programming language like Lisp.

> just with curly braces instead of parenthesis

Well, and more syntax than S-expressions: it's got both objects and arrays as fundamental structures instead of just lists, and it has commas as noise characters.

<comment><USER5> > Well, and more syntax than S-expressions: it's got both objects and arrays > as fundamental structures instead of just lists

Well, Common Lisp has both of those as fundamental atoms:

        #S(foo :bar 3)

        #(1 2 3)

The former creates an instance of a FOO struct with its BAR slot set to 3; the latter is a 3-item array.

<comment><USER6> And then CLOS objects, hash tables, regular expressions, etc. can be added with reader macros.

<comment><USER3> It's cool and I love it, but it's irrelevant in the context of a universal data exchange language. In such case, you'd want to have those primitives defined in the exchange language spec itself - even if you'd end up implementing them as reader macros in CL (which I don't recommend - <USER2> macros turn your READs into EVALs, which you obviously shouldn't do on untrusted input).

<comment><USER5> > you'd want to have those primitives defined in the exchange language spec > itself

I agree with this: certain things need to be in the spec.

> even if you'd end up implementing them as reader macros in CL (which I don't > recommend - reader macros turn your READs into EVALs, which you obviously > shouldn't do on untrusted input).

This I don't agree with, because technically #\\( & #\" are reader macros … they're just very well-defined reader macros. Presumably a spec which defined hash tables, regular expressions or whatever would define them as well as the Lisp spec defines lists and strings (and if not, well — it's a bad spec!).

<comment><USER3> > _I agree with this: certain things need to be in the spec._

That was my main point. In the second part of the comment I didn't mean to discourage use of reader macros - it was more of an aside that the general facility of CL-style reader macros literally makes READ "shell out" into EVAL, so you need to (diligently) disable it for untrusted input (or reimplement a limited READ by hand). So we can't say "oh, but S-exps in Common Lisp can have anything through reader macros". Presumably _if_ hash table literals were specified as a part of basic syntax, we could depend on it being standard _and_ part of the safe subset of READ's duties; as it is however, we can't depend on it for arbitrary inputs.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> One major weakness of JSON is lack of a corresponding "infoset"; that is, an equivalence predicate. When are two JSON blobs "the same"? There's no sign of anything like this here.

Another is the lack of support for binary data. There's no sign of support for binary data here.

Finally, there's this claim:

> _The advantage of Mark over S-expressions is that it is more modern, and can > directly run in browser and node.js environments._

Is it more modern? I don't think I care.

Can it directly run in browser and node.js environments? What does that mean? It seems to need a parser. But then, S-expression parsers certainly directly run in browser and node.js environments.

\---

IMO, SPKI SEXPs are _much_ more sensible than this design and many, many other designs:

[https://people.csail.mit.edu/rivest/Sexp.txt](https://people.csail.mit.edu/rivest/Sexp.txt)

<comment><USER5> > IMO, SPKI SEXPs are much more sensible than this design and many, many other > designs

Yes, yes, ten thousand times _yes_! I really don't understand why, over two decades hence, the world has stuck with XPKI & ASN.1, and has invented XML & JSON, when SPKI solved the PKI problem for good & canonical S-expressions solved the flexible- and human-readable–data-exchange problems for good.

<comment><USER8> Since you both seem to know the spec: how would you encode key/value pairs? Or would you have to have a list of nested lists, like

        (my_dict (key value) (key value) (key value))

Un-ordered qualities for data can be useful (e.g. they allow you to reorder data to stream "important" stuff first), but I don't see it anywhere in here.

<comment><USER5> With canonical S-expressions, unordered sets are a problem because part of the point is to be able to have a single canonical sequence of bytes, which can be hashed or compared bytewise for equality.

In general, I'd resist specifying data as arbitrary key-value pairs, but _if_ I decided that I indeed needed them, I'd do exactly as you suggest — and I'd mandate that the be sorted lexicographically by their keys.

</comment></comment></comment></comment><comment><USER9> Each existing format have advantages and disadvantages for particular purposes.

Benefit of HTML: You can actually write it by hand and easily see where each element begins and ends, even when the document is longer than a screenfull. Mark has the "}}}}} problem with larger documents, so it is not as suitable for human-written markup.

It is not clear to me how mixed content like Hello world is expressed in Mark. I expect it will be pretty convoluted.

Benefits of JSON: Maps directly to simple data structures: List, dictionaries and simple values. Similar data structures are supported in almost any language. Mark has "type names" and anonymous text content which complicates serialization and serialization a lot, and is sure to give interoperability (and perhaps security) problems.

So - worst of both worlds? Instead of tying to be an overall worse alternative to all the formats, they should rather focus on a specific niche where Mark can be a better alternative.

Take configuration files, for example. They don't have large amount of textual content like HTML, and they don't need to be transferred between disparate systems.

       {size width:100 height:100}

vs

       <size width="100" height="100"></size>

vs

      {"size": {"width":100,"height":100 }}

In this case, the Mark syntax is simpler and cleaner. Mixed content is not needed, which would make the format simpler. Yeah it is basically the same as S-expressions, but that is not a bad thing.

<comment> phoe-krk _Mark has the "}}}}} problem with larger documents, so it is not as suitable for human-written markup._

And HTML has a problem of

, all spread over nine different lines, one tag per line.

Take a look at [https://github.com/keithj/alexandria/blob/master/definitions...](https://github.com/keithj/alexandria/blob/master/definitions.lisp#L24) which is Lisp code styled in a standard manner. I don't see any problem there.

<comment><USER9> The HTML example is _much_ better than "}}}}} though, since you can e.g. add a new item at the end of the list without needing a specialized editor to locate the right position. This is one of the reasons for the redundancy in repeating the tag name in the end-tag. In theory Lisp should have the same problem, but usually code (hopefully) rarely have nested blocks larger than a screen, so it is not a big issue in practice, even if )))) looks ugly. Bottom line is code have a different structure than typical hypertext documents, so just because a notation is suitable for one does not mean it is suitable for the other.

<comment><AUTHOR> But when s-expression is used to represent document, not a program, then it is also not free to refactor deep nested content. So s-expression is no better than XML/HTML/JSON/Mark when encountering deep nested content.

<comment><USER9> It is exactly the same as Mark, but I am arguing it is _worse_ than XML/HTML for these scenarios.

</comment></comment></comment></comment></comment><comment><USER10> Comparing {mark} to XML, it doesn't seem to support namespaces which makes the claim to be extensible somewhat dubious. How am I supposed to add custom objects without risking name clashes? Namespaces also make XML kind of fully typed without being tied to a single programming language.

Another strength of XML is support for mixed content which seems rather awkward in {mark}. The following

Some bold text

apparently needs to written as

        {p 'Some' {b 'bold'} 'text'}

It would be more honest to mark support for mixed content as "verbose" in the feature table.

Besides, the name {mark} seems like a bad idea. How could you find relevant results when searching for {mark} using a search engine?

<comment><AUTHOR> Current Mark design does not enforce a namespace standard. Namespace can be easily captured in Mark, e.g. {'ns:elmt' 'xml:attr':'value' ...}

XML Namespace seems to have a lot issues, thus Mark does not want to enforce something exactly following it.

Namespace in Mark, currently, is left upto the application user to define it.

We might be able to come up with a better way to define namespace.

As for the name, you can just use Mark. I use '{mark}' as an alternative name, to make it more graphical, more impressive.

<comment><USER11> Please don't.

XML Namespaces is syntactic vinegar.

Less is more.

</comment></comment></comment><comment><USER12> Needs a "Why was Mark created?" section because this appears more 'neat' than 'useful'.

<comment><AUTHOR> Yes, I'll do that.

</comment></comment><comment><USER13> > The advantage of Mark over S-expressions is that it is more modern, and can > directly run in browser and node.js environments.

There seems to be a ton of s-expression parsers in npm already, that can run in browser and in node.js: [https://www.npmjs.com/search?q=s-expression](https://www.npmjs.com/search?q=s-expression)

Besides being able to run in js environments, what else does {mark} bring over s-expressions?

</comment><comment><USER14> "Whoever does not understand Lisp is doomed to reinvent it"

\- A wise man on the Internet once said

</comment><comment><USER15> Defining the type of objects is a must when you want to exchange things in a strongly typed environment (Java on the server, TypeScript on the client, for ex). So +1 for {mark}. Do you handle multiple typing? (We use that a lot in Neo4J, and we think it is really neat)

Another comment: Coming from a Semantic Web background, and using N3 as the exchange format and N3.parse() as my client-side lib, I would advise to have a UID parameter to uniquely identify objects, and a refId syntax, so any parameter can reference some other objects of the data structure. That helps when you want to transmit a graph [1].

My humble 2 cents.

[1]: I would add that it is also useful when you retrieve some refIds that are not defined in the current data structure. You can then ask the server to dereference these refIds, and send another (portion of the) graph, that you can connect with the existing data structure.

<comment><USER16> Can you clarify what is meant by "multiple typing"?

<comment><USER15> Let's say you transmit an object of type Person, that is also a Student and a MartialArtist. Your inheritance graph may define that a Student is also a Person. So not sending the Person type could be fine. But would you define a common subtype for Student+MartialArtist, just because your data serialization handles only one single type per object? Obviously no! You want to send your object with types "Student" and "MartialArtist". I.e multiple types.

</comment></comment></comment><comment><USER17> If you want a better JSON, try binary-json "Concise Binary Object Representation" RFC 7049 [http://cbor.io/](http://cbor.io/)

<comment><USER18> You either go with JSON because everything talks JSON or you go with something that doesn't have an explicit parsing step like flatbuffers or capnproto.

If you don't care about parsing CPU efficiency then gzipped JSON beats protobuffers, CBOR, etc when you care about bytes sent over the wire.

If you care about CPU efficiency then protobuffers, CBOR, etc are worse than flatbuffers or capnproto.

There is not a lot of space for a new standard between these two existing categories.

<comment><USER19> > gzipped JSON beats protobuffers, CBOR, etc when you care about bytes sent > over the wire.

Gzipped JSON does _not_ beat gzipped Protobufs in message size. Comparing gzipped JSON to uncompressed Protobuf doesn't make sense.

</comment></comment></comment><comment><USER20> Interesting project but a little overboard with the self back-patting in the README.

</comment><comment><USER21> > The advantage of Mark over S-expressions is that it is more modern

Is it more modern because it is newer? There is mention of how adoption is limited, but wouldn't the adoption of a completely new syntax be even more limited :-)

There is even a canonical representation using length prefixes: [https://en.wikipedia.org/wiki/Canonical_S- expressions](https://en.wikipedia.org/wiki/Canonical_S-expressions)

<comment><AUTHOR> Being 'more modern' means Mark takes a JS-first or web-first approach in its design. Whether we like it or not, JS has dominated the web. JSON is successful, partly because it takes a JS-first approach. Mark inherits this approach.

</comment></comment><comment><USER22> The biggest problem with these ideas is that json is already supported in the browser.

There might be a use case where your data is better represented in LDIF because it's hierarchical, but there's no built in LDIF support, so now you're importing a ton-o-javascript just to parse some new format.

At this point, we should realize json isn't meant to be human readable anyway. If you need to hunt through it, you put it into some type of json viewer so you can see the tree and query it. It's an interchange format, that's more compact than XML.

If you're shipping data between non-browser things like backend services, there are already binary formats like protobuff that have typing and can be optimized for small payloads.

</comment><comment><USER23> Looks awfully similar to Clojure's EDN

<comment><USER24> I rarely code in Clojure, but I do use EDN and whenever I see new standards I always compare it to EDN.

<comment><USER25> Actually EDN is much better by default (sets, extensibility, etc)

</comment></comment></comment><comment><USER26> Besides the nonsensical "advantage over S-expressions" statement in the README, the biggest issue I have with this is that Mark maps only to JavaScript, not to other languages where dicts/maps/hashes and arrays/slices/lists are two different things. Makes me wonder if it just has not occurred to the author that there are languages != JS.

<comment><AUTHOR> If all other languages have no problem supporting XML, they'll have no problem supporting Mark.

It just that in languages like JS and Lua, where an object can be an map and a list at the same time, they'll have the convenience of mapping a Mark object into just one object, instead of many.

<comment><AUTHOR> Another way to support Mark in other languages, is just to use map for both properties and contents. E.g. in Java, the key in map can be integer. Of course, the performance will not be as good as primitive array. But it can be one man's quick-and-dirty solution.

General JS arrays (not those TypedArrays) are actually maps indeed.

</comment></comment></comment><comment><AUTHOR> Thanks for several comments pointing out the unclearness of what's being "more modern".

I've updated the README to be: "The advantage of Mark over S-expressions is that it takes a more modern, JS-first approach in its design, and can be more conveniently used in web and node.js environments."

Hope it's clearer now.

</comment><comment><USER27> Anyone who doesn't know Greenspun's 10th Rule is doomed to rhyme with it.

</comment><comment><USER28> _The nice thing about standards is that you have so many to choose from._

\- Andrew Tanenbaum Computer Networks, 2nd ed., p. 254.

I think all developers go through some experience where they want to just "unify" everything because that will supposedly make it easier for them and other developers.

Overtime as you become more experienced or I guess jaded you realize that reality of a "GUT" technology platform or programming languages is a pipe dream and the effort to get people to use said new format/language/tech is more effort than what you get in return.

Anyway to be short about it I think most should just pick the best tool for the job and stop rebuilding things that don't need to. And if you do please make sure you have a plan to how you are going to replace all the old working stuff.

<comment><USER29> > I think most should just pick the best tool for the job and stop rebuilding > things that don't need to.

I think you just contradicted yourself. Sometimes the best tool for the job is something new, something improved over what already exists.

I don't think the author intends to "replace all the old working stuff". But if this tool is better for new projects, then why not? I don't get all the negativity... do people here really love XML/JSON/YAML that much? There's a whole lot to complain about in all of those!!

<comment><USER28> I am not averse to new formats. I am averse to formats that try to "unify".

And yeah I don't have a problem with XML or JSON. Those two combined with some flatbuffer other men binary protocols cover most of my use cases... like really what's with all the XML negativity.

</comment></comment></comment><comment><USER30> "XML...Fully Typed: No."

XSDs don't count then? [https://en.wikipedia.org/wiki/XML_schema](https://en.wikipedia.org/wiki/XML_schema)

<comment><AUTHOR> XML is only semi-structured/typed without schema. JSON and Mark are always typed.

Full formal schema definition, as in XML, is often a burden to ad-hoc scripting, which is common in JS. JSON/Mark provides sufficient type info for these adhoc usages.

<comment><USER31> JSON is not "fully typed". It just happens to have different syntax for strings, numbers, and booleans. But the application code still needs to come up with a way to distinguish between timestamps, enums, different object types, etc.

XML uses the same syntax for strings, integers, and booleans, but it has mature schema/typing tools that make it easy to apply more precise typing, which you'd want to do anyway to identify timestamps, enums, and different object types.

</comment></comment></comment><comment><USER32> Pros: At least its not JSONx :D

Cons: Not seeing any advantage over JSON. If you want a type for objects just add a type field and have your code read it. Then you can use any of the existing parsers.

</comment><comment><USER33> > It has clean syntax

You could remove every '{' with 0 loss of meaning.

<comment><USER32> I was thinking this looked like YAML with {}

<comment><AUTHOR> YAML does not have good support for mixed content.

</comment></comment></comment><comment><USER34> I made my own little language called Geneva [0] for similar ideas but it acts as code and can be parsed as JSON. I also came up with a spec for doing this for HTML [1] (but no code to do this yet).

[0] [https://github.com/smizell/geneva](https://github.com/smizell/geneva)

[1] [https://github.com/smizell/janeml](https://github.com/smizell/janeml)

</comment><comment><USER35> Please just use EDN: [https://github.com/edn- format/edn](https://github.com/edn-format/edn)

</comment><comment><USER36> What he forgot to add:

Some disadvantages of Mark, comparing to JSON would be:

* Mark is insecure, JSON is secure.

* Mark is slower than JSON

Passing types directly to object.constructor is of course entirely insecure. [https://github.com/rurban/Cpanel-JSON- XS/blob/master/XS.pm#L...](https://github.com/rurban/Cpanel-JSON- XS/blob/master/XS.pm#L2052) (i.e. CVE-2015-1592)

<comment><AUTHOR> Thanks for feedback on the security aspect. It is something that Mark definitely needs to consider carefully.

Current Mark implementation does not call arbitrary constructor during parsing. The constructors are created from scratch. But application users might want Mark to call their customer class constructor. I'm thinking passing in a callback function to Mark.parse().

<comment><USER36> What YAML did in this aspect is providing a whitelist of allowed classnames.

</comment></comment></comment><comment><USER37> I like the idea but I don't think the benefits outweighs the negative implications it would have to implement it.

I mean JSON as a data format for api stuff is just enough as it is and you'd need some serious reason why to change from JSON and these reasons just doesn't cut it.

</comment><comment><USER5> > The advantage of Mark over S-expressions is that it is more modern, and can > directly run in browser and node.js environments.

… with the right translator to JavaScript, which also happens to be true of S-expressions.

His table is incorrect, incidentally: S-expressions support mixed content (if I understand what he means) and are also fully generic.

He doesn't have a good example of the benefits of his proposal over S-expressions: 'more modern' just means 'undiscovered bugs.'

I respect his enthusiasm and hard work, but I believe what the world needs is hard work on existing things rather than hard work reïnventing the wheel.

</comment><comment><USER38> > Mark utilizes a novel feature in JavaScript that an plain JS object is > actually array-like, it can contain both named properties and indexed > properties.

Where can I read more about this feature of JavaScript?

<comment><USER39> JS objects are tables, with Arrays being a syntactic convenience with some extra properties. JS engines do heavily optimize for the array case with dense layout. [https://docs.microsoft.com/en- us/scripting/javascript/object...](https://docs.microsoft.com/en- us/scripting/javascript/objects-and-arrays-javascript)

Calling it novel to JS is a stretch. Lua does this too and I'm sure there are other languages.

<comment><USER40> php does too

</comment></comment></comment><comment><USER41> So it's basically just XML with curly braces or sexps...

And why bring YAML in the mix? Yaml isn't used for transfer I hope? Should be compared to TOML as well in that case that seems a lot better than YAML, especially for configs: [https://github.com/toml- lang/toml](https://github.com/toml-lang/toml)

Or msgpack? Which also seems useful. Why not protobuf? Or just s-exps which is basically what this is.

</comment><comment><USER42> If I understand the grammar properly, all plain-text elements have to be quoted. That makes sense for object data, isn't really markup friendly.

</comment><comment><USER43> Great initiative. I'd say why not improve the leading format, that is, JSON ;-) ? I'm collectiong all data markup flavors and extension (HJSON, JSON 1.1, JSONX, SON, etc.) in the Awesome JSON - What's Next page @ [https://github.com/json-next/awesome-json-next](https://github.com/json- next/awesome-json-next) Cheers.

<comment><AUTHOR> JSON has a strong selling-point that it is compatible with JS in syntax.

It is very hard to make major extension to JSON and still be compatible with JS syntax. Minor changes are possible, like in JSON5.

Once it breaks JS compatibility, I don't think people will think it is JSON next any more.

<comment><USER43> Good point. If it's not JSON next but a complete new format than you will have to compete with JSON, all JSON next formats and all other alternative formats. Good luck.

</comment></comment></comment><comment><USER44> Reinventing LISP is a nice thing.

I like this project.

<comment><USER45> I like this syntax also for this reason, though I have to add that the hell of parenthesis would prohibit it to be widely adopted.

<comment><USER29> Is that really worse than the "hell" of angle-brackets in XML/HTML? Because those are pretty widely adopted.

</comment></comment></comment><comment><USER46> > Mark utilizes a novel feature in JavaScript that an plain JS object is > actually array-like, it can contain both named properties and indexed > properties.

wouldn't that make introspecting objects very annoying?

<comment><AUTHOR> In Mark implementation, care has been taken so that indexed contents are not enumerable. So e.g. when you run a for ... in loop on a Mark object, you'll only see properties, not the contents.

This is one of the difference between Mark object and an array. Array contents are enumerable by default.

</comment></comment><comment><USER47> Doesn't have a native date/time, so no advance over JSON really

<comment><USER48> You might be interested in Zish:

[https://github.com/tlocke/zish](https://github.com/tlocke/zish)

It's a data serialization format with timestamp, bytes and decimal data types.

<comment><USER47> Heh, check out [https://www.obj- sys.com/asn1tutorial/node15.html](https://www.obj- sys.com/asn1tutorial/node15.html)

ASN.1 dates from 1984. So much for Mark being "modern"!

</comment></comment></comment><comment><USER49> What would you use for schema validation? Obviously [http://json- schema.org/](http://json-schema.org/) won't cut it.

<comment><AUTHOR> A new Mark-specific schema will need to be developed, based on the prior art or XML Schema, JSON Scheam, etc.

</comment></comment><comment><USER50> This should probably be titled "Show HN:".

<comment><AUTHOR> I'll do that next time.

</comment></comment><comment><USER51> I really like protocol buffers. If you've never used it, they're really worth checking out.

</comment><comment><USER52> Not sure how many more xkcd 927s this thread will have but personally what bugs me the most is the thought that being slightly more versatile than JSON means that Mark is worth the trouble of adopting. Data structures are well represented by JSON, markup is mostly well represented with XML. I rarely really want to mix the two. Additionally, this doesn't feel like a language I would want to write documents in any more than I do XML.

I think we're fine with separate languages for data and markup.

<comment><AUTHOR> Data and markup/document separation might not always be that clear cut.

The latest trend in CMS systems, piloted by the latest content editors, like Quill, Draft.js, ProseMirror, Slate.js is to use JSON to present the content, instead of using HTML or Markdown. Using object notation, gives rise to cleaner API and data model.

So the wall between data and markup, JSON | XML may collapse one day.

</comment></comment><comment><USER53> I wish the start of comment can still be made less verbose-y "{!-- comment --}"

<comment><AUTHOR> Comment can just be {!comment} or {#comment} in Mark, if you like.

In the README example, I deliberately made it resemble HTML comment, so as to make it easier for people to correlate.

<comment><USER54> huh. when i read the spec, i thought comments were c like

        begin_sl_comment ::= '//'
        begin_ml_comment ::= '/*'
        end_ml_comment   ::= '*/'

maybe that ebnf is out of date.

<comment><AUTHOR> In Mark, there are two types of 'comment'. // comment and /* comment */ are lexical comments, which are stripped during parsing.

Then there's Mark pragma, like {!pragma}, which are preserved in the data model. HTML comment is supported as Mark pragma, not Mark comment.

<comment><USER29> Oh that's a really interesting distinction.

</comment></comment></comment></comment></comment><comment><USER55> I would strongly suggest a renaming. Mark is so generic that you can already tell you want {mark}, which has a pronouncability issue, and the name is too similar to the big player that is markdown (like a bright star making it impossible to see a dimmer one right next to it), making "mark" sound to me more likely to be a markdown renderer than a JSON replacement. Given that both mark and markdown are markup languages of various sorts, the names are just too close to each other, i.e., it would be different if markdown was what it was and you were proposing "mark" as the name of a library that lets you put marks based on geographical criteria on a map or something totally different.

Mark reserving all number-only keys is statistically likely to become a problem as a project grows larger. I'd suggest finding a different way to get out-of-band data to be _fully_ out-of-band, rather than trying to carve out a chunk of keys.

Somewhat similarly, defining a "pragma" as "something surrounded with braces that isn't a legal object" means that if you ever want to change the definition of an object in the future, you can't, because you will turn things that used to be pragmas into objects, or less likely (because you'll try to avoid this going forward) but still possible, vice versa. You need to concretely specify what a pragma is unambiguously, in a way that you can evolve either without affecting the other. It also means errors in generation become legal pragmas instead of errors, which will cause surprises, and on the flip side, errors in parsing objects can turn them into legal pragmas rather than parse errors.

I would reserve saying "Mark is a superset of JSON" for the case when you really can feed any JSON to a Mark parser and get a (roughly) equivalent structure. Alternatively, go through the documentation with a text find option and make sure every time you say "superset" it is qualified as a " _feature_ superset". Especially in light of "(Mark does not support hexadecimal integer. This is a feature that Mark omits from JSON5.)" The word superset should either be qualified every time or mean a _strict_ superset; "Mark is a nearly- feature-superset of JSON" would be more accurate.

In general, a review of [http://seriot.ch/parsing_json.php](http://seriot.ch/parsing_json.php) may be appropriate; mark addresses only one serious issue, and the other fixes are ultimately fairly superficial (the trailing comma issue, for instance, is almost never a problem for me because ninety-nine-point-I-don't-know-how-many- nines percent of the time, JSON is a thing my tools generate; the cases where that is a _serious_ issue have generally already moved on to another format like YAML, same for comments). Also, per my comment about parse errors turning objects into pragmas, if you expect this to become a big cross-language standard it is worth reviewing a snapshot of the variability in JSON parsers, which is a simpler format. A more complicated format should expect to see _even more_ subtle divergences in its multiple implementations and things like "misreading an object as a pragma" to become even more likely at scale.

<comment><AUTHOR> Hexadecimal integer is not part of JSON. It is a new syntax introduced in JSON5 (not JSON version 5). I don't think this feature is that useful, thus does not incorporate it into Mark.

<comment><USER55> (I can't downvote direct replies, so it wasn't me.) I was not suggesting that you incorporate it. I was suggesting modifying your marketing copy to incorporate the fact that it will not be a superset anymore. Superset is a word we should guard and not let it become "sort of superset-ish, maybe, mostly", but should mean _superset_. If you don't have _every feature_ , you should not say it's a superset. Since not only is there nothing wrong with feature elimination, but when done well is a downright good thing, it's not like this is some sort of major problem for the marketing or something; just say you used some taste in what you brought over.

And again let me emphasize, since you seem to be saying it again in some other replies, that "{mark} is a superset of JSON", if you mean that _syntactically_ (as opposed to features wise), MUST mean that _every valid JSON document will produce a valid {mark} parse_. Nothing less than that qualifies it as a superset. Given that you reserve numeric keys I don't think that is the case; whether the grammar is a superset is harder to determine so I haven't tried. That would be something best served by taking a very complete JSON parser test suite from someone and validating that all their corner cases that are supposed to parse in JSON, parse in {mark}. Based on my own experience in the world of parsing, the odds of you passing that first try are very low; if you manage, major kudos to you as that would be a very difficult test. (Though I would imagine that since the grammar largely came from JSON a lot of the surprises would be the ways in which your parser turns out to deviate from the grammar rather than grammar errors.)

</comment></comment></comment><comment><USER56> Looks like a worse HAML...

</comment><comment><USER57> tangential: I love json-5 which is like json, but allows comments and doesn't need to quote the keys, so it's just 'dumped js'.

</comment><comment><USER58> nope, data shouldn't include structural information (except maybe in the header) and markup shouldn't include style information.

</comment><comment><USER59> Not a fan. I'd rather JS adopted EDN instead.

</comment><comment><USER60> EDN FTW.

</comment><comment><USER61> waiting for mark 2. No... seriously, it's enough already [https://xkcd.com/927/](https://xkcd.com/927/)

</comment><comment><USER62> I don't know if it's useful to have a universal format; each format (YAML, XML) is suited for for a specific purpose (human readable, completeness).

The headline reminds me of: [https://xkcd.com/927/](https://xkcd.com/927/)

<comment><USER63> Maybe we should stop when we reach the YA prefix.

</comment></comment><comment><USER64> The doesn't have a grammar? When will people realize this is completely unacceptable.

<comment><AUTHOR> Grammar details in section 4 of [https://mark.js.org/mark- syntax.html](https://mark.js.org/mark-syntax.html)

<comment><USER65> Henry, did you use Gunther Rademacher's RR diagram generator?

Best of luck with {mark}.

<comment><AUTHOR> I used grammarkit ([https://github.com/dundalek/GrammKit](https://github.com/dundalek/GrammKit)), which further uses railroad-diagrams ([https://github.com/tabatkins/railroad- diagrams](https://github.com/tabatkins/railroad-diagrams)) library to generate the RR diagrams. I don't know if they are related to Gunther Rademacher's RR diagram generator.

<comment><USER65> Cool. I'll check those out.</comment></comment></comment></comment></comment>


How to sell your website fast, with no fees and at a high multiple - <AUTHOR> http://www.equitywebsites.com/

<comment><USER2> So, this would be the equivalent of putting the business office up as collateral for a business loan?

<comment><AUTHOR> More or less. I like to describe it as a 100% seller-financing deal, with the business itself as collateral, so you get the business back if you aren't paid what we agreed in the given amount of time.</comment></comment>


Google is shutting down its goo.gl URL shortening service - <AUTHOR> https://goo.gl/ <comment><USER2> Previous discussion [https://news.ycombinator.com/item?id=16719272](https://news.ycombinator.com/item?id=16719272)

</comment><comment><USER3> "While most features of goo.gl will eventually sunset, all existing links will continue to redirect to the intended destination." [https://developers.googleblog.com/2018/03/transitioning- goog...](https://developers.googleblog.com/2018/03/transitioning-google-url- shortener.html)

<comment><USER4> I hope this doesn't change too. Felt I had to use it to link a humongous wikidata SPARQL query in a (software) research paper recently.

<comment><USER5> I hope you added the entire link in an appendix, otherwise it's not Google's fault for ruining your paper.

<comment><USER4> The query itself is available in a screenshot. Also a pretty periferal part of the paper.

Looked/thought hard about options but did not come up with better at the time.

But wanted to highlight how important it is for parties starting such services to have a plan for longevity. Hopefully Goog will keep old links going for a long time.

</comment></comment></comment></comment><comment><USER6> I'm not sure how you guys feel about this, but personally, I've been avoiding Google services for the last couple of years because I just assume they'll eventually get shut down.

<comment><USER7> Same here. Only thing I'm still strongly dependent on is gmail. I don't really think that's going away anytime soon, but out of principle I'd like to move away from it. Takes a lot of energy unfortunately and you probably need to keep a redirect in place for a long time just in case...

<comment><USER8> Is there a self-hosted web mail service w ux like gmail, that you can migrate to smoothly and pay a license for?

I would consider this move. I just assume no one has ux even close. It would take me at least a year to fully transition from one gmail address.

<comment><USER9> Not self-hosted, but I am very happy with Zoho [0]. They target companies and their free plan includes lots of features like support for your own domain. The web UI is comparable to GMail (indeed in parts I prefer it) and they offer a very good Android app as well.

[0]: [https://www.zoho.com/mail/](https://www.zoho.com/mail/)

<comment><USER10> Zoho recently removed IMAP and email forwarding from their free tier (though existing users were grandfathered in), so stay away if you value email portability.

</comment></comment></comment></comment></comment><comment><USER11> I've recently came across a use case for an URL shortener (Entering long API calls on mobile devices) and was looking for a self-hosted solution. Any recommendations?

(No public shortening service, only admins can create new shortcuts.)

<comment><USER12> I'm looking for a URL shortener that tells me how many users clicked the link.

<comment><USER13> Is that your only requirement? In that case even my very simple one would be enough: [https://github.com/ptman/urlredir](https://github.com/ptman/urlredir)

<comment><USER12> Other requirements would be that it is actually hosted somewhere :) and doesn't ever shut down.

</comment></comment></comment></comment><comment><USER14> The last time I used an URL shortener was in the old days when Twitter still counted every character of the URL against the 140 char limit. I'm curious what use cases URL shortening services have nowadays?

<comment><USER15> A lot of people use them for tracking. For example, you can use one underlying URL but have several shortened ones for various promotional places (email, Twitter, etc) and then use the analytics for the shortener to see which place is actually sending you traffic.

</comment></comment><comment><USER16> Archived copy, which works with JS disabled:

[https://archive.is/r53k9#0%](https://archive.is/r53k9#0%)

</comment><comment><USER17> I used to register and use domain go.gl for my photography business in early 2000's

Was thinking about registering goo.gl just for kicks (it was available back then) but turned off this idea because Greenland would charge $50+ for registering. And it had to be done over the FAX!

</comment><comment><USER18> If you want a free OSS URL shortener for your own domain name, I built a simple one at [http://xluh.co/repo](http://xluh.co/repo). Will be expanding on it in the future.

</comment><comment><USER19> I really would appreciate a link shortening service automatically creating IPFS mirror!

</comment><comment><USER20> This would not be a problem if websites themselves provided shortened URLs for all paths within their domain name:

      foo.com/2018/03/31/the-title-of-an-article => foo.com/a3ef33

<comment><USER21> [https://news.ycombinator.com/item?id=16722817](https://news.ycombinator.com/item?id=16722817)

[https://news.ycombinator.com/b00b00](https://news.ycombinator.com/b00b00)

not very short

<comment><USER22> I do not understand. Please say what you mean in your message instead of just dropping some urls:s. For example now, your url:s goes to this submission and an unknown (!?). If you had written what you meant at least I could understand your point.

<comment><USER23> They are examples of a long "short URL" following your specification.

        https://news.ycombinator.com/item?id=16722817

might shorten to

        https://news.ycombinator.com/b00b00

which is not very short given the length of the hostname.

</comment></comment></comment></comment><comment><USER24> DUPE: [https://news.ycombinator.com/item?id=16719272](https://news.ycombinator.com/item?id=16719272)

</comment><comment><USER25> A good alternative: [https://lc.cx](https://lc.cx)

</comment><comment><USER26> I guess I was just a little prescient back in 2011, when I wrote of URL- shortening services in a blog post, "let's not forget that these entities have a nasty tendency to vanish". Not that being prescient about the Big G end-of- lifing services is particularly visionary or difficult, tbh.

The post[1] was to publicise a small shortener I'd written for myself (Java/JSP solution) -- in many ways deficient and lacking all sorts of features (stats, UI) but it worked well enough for me for a time until I got lazy, got ill, and got rid of the server it was running on. But I was bang on- target about the likelihood of such things disappearing under the waves.

I guess it's time to dust it off[2], bring the codebase up to date and get it working again. I'm a bit doubtful about hosting it on, say... Google Compute free-tier or something... for who knows when /that/ service will get taken down.

[1] [http://onemikro2nd.blogspot.co.za/2011/04/shrtn-url- shortene...](http://onemikro2nd.blogspot.co.za/2011/04/shrtn-url- shortener.html)

[2] [https://bitbucket.org/mikro2nd/shrtn](https://bitbucket.org/mikro2nd/shrtn)

<comment><USER27> > it worked well enough for me for a time until I got lazy, got ill, and got > rid of the server it was running on. But I was bang on-target about the > likelihood of such things disappearing...

Oh, the irony...

<comment><USER28> Kinda the opposite of irony. They said these things disappear. Had they said, "but this one won't," then we would be approaching irony.

<comment><USER27> My impression was that building his own URL shortenner was undertaken as a mitigation of the risk of other URL shortenners disappearing.</comment></comment></comment></comment>


DuckDuckGo and Firefox as a Replacement for Google and Chrome - <AUTHOR> https://techbq.com/genius/duckduckgo-and-firefox-as-a-replacement/ <comment><USER2> I recently made the leap to bing. Been on a combination of FF and TOR Browser for the last two years. I'm pretty much done with Google.

I think the breaking point for me was when I would visit non-google sites and get a pop-up asking if I wanted to use my google account by name to login. Probably a weird point to get stuck on, but that was mine.

<comment><USER3> I have seen that. Though, I hope I am correct in assuming it is in an iframe and thus in-accessible to the hosting site due to browser CORS restrictions.

</comment></comment><comment><USER4> I've been on Firefox on and off for most of my life. Was using Chrome predominately until last year, and went to Firefox. Firefox is great - I find it to be an absolute 100% quality replacement to Chrome.

DDG has a few shortcomings, and is doable to replace Google but it is not as good. I also feel DDG is like an 'uncensored' engine, Google has so many censors and manipulations on their queries, anyone anti- censorship/manipulation should not use Googles search engine

I'm currently using Google though, so shit, I'm a hypocrite

<comment><USER5> Biggest dig I have on Firefox is that Dark Reader runs pretty poorly on it compared to Chrome, particularly on complex Google-owned websites like Gmail, and I can't go back to white-background-by-default anymore.

It'd also be nice if Apple actually allowed third party browsers as first- class citizens, because not having content-blocking support in iOS Firefox makes it a non-starter.

Otherwise, Quantum-based Firefox is objectively a better browser IMO. I like the extension store better, and in general it seems to work more smoothly for me. If my company weren't stuck on Google Apps where Chrome's blurring of login is actually useful, I'd use Firefox all the time. As it is, I use it as my "personal login" browser everywhere other than my phone and tablet.

(ObDisclaimer: I used to work for Mozilla half a decade ago, but I definitely would not have praised the pre-Quantum version the same way. It had fallen way behind the curve.)

</comment></comment><comment><USER6> I moved to DDG a month or so ago. One thing I miss is the contextualization of my results. Google knew so much about me, it new that if I was searching for a cafe that it should search my local area.

DDG doesn't know me and so for roughly a fifth of the searches I do, I need to add more detail to the search to get the results I need.

<comment><USER7> That has been my experience as well. That being said, do you prefer your search provider knowing by default? Or "opting in" to provide the additional information?

Personally, I prefer the former but I understand the latter.

</comment></comment><comment><USER8> Brave + DDG works well for me. All of the compatibility of Chrome, but with none of the tracking.

</comment><comment><USER9> Too many sites and services work badly with FF. The Chrome incompatibility monopoly is a huge issue.</comment>


Could this be the next big social platform? - <AUTHOR> https://www.challengeachieved.com <comment><USER2> No.</comment>


Toronto police officer buys would-be thief the outfit he was trying to steal - <AUTHOR> http://www.ctvnews.ca/canada/toronto-police-officer-buys-would-be-thief-the-outfit-he-was-trying-to-steal-1.3536049 <comment><USER2> This would be okay, if the officer explained to the thief that this was wrong and suggested other means of getting what he desired, like lending money from friends, or using Kickstarter or social networks or maybe even church (if this works in Canada) or whatever. The acceptable follow up would be to analyze for groups of kids under risk and have educational meetings at school. What the officer did seems right, but it might have gotten lucky. This will not be enough in a generic case.</comment>


[Ask HN] How much of competitive intelligence gathering is too much? - <AUTHOR>

I am working on a new app, which has similar existing apps in the market. I registered and used these apps to get an idea about the features of the apps. (For each of them, I registered multiple users, tested the functionality heavily etc). Its trivial to prove that the user is me, as I registered at all places with my primary email address, or variants.<p>SO what am I wondering if there can be clause in the various EULAs I checkboxed, which says that you can not use our software to create a competitive software etc, and can it be enforceable? <comment><USER2> IANAL, but I think that a similar case appeared when microsoft "copied" the macintosh ui. You know the rest of the story.

</comment><comment><USER3> don't worry.. just launch</comment>


Improved Format of Online Tutoring Is Here - <AUTHOR> https://hackernoon.com/improved-format-of-online-tutoring-is-here-38c85ad73cb3 <comment><USER2> This is blogspam. Bookwormhub is a service where you pay people to write papers for you

<comment><USER3> Not even the first time this specific blogspam has been posted by OP.</comment></comment>


Nokia N810 Running Android - <AUTHOR> http://www.talkandroid.com/65-google-android-nokia-n810/

<comment><USER2> Nuked (at least for now): <http://suspended.hostgator.com/?domain=www.talkandroid.com></comment>