The Art of Debugging - <AUTHOR> https://remysharp.com/2015/10/14/the-art-of-debugging <comment><USER2> I always found debugging to be one of the most important skills in software development and programming.

Most people seem to think of debugging only as finding and fixing unexpected behavior in finished software projects, but it is actually a big part of the development process itself: When I implement a new feature, I normally use the following pattern:

* Make a mental model of what I want to accomplish (e.g. "add payment form to the web app")

* Split that into individual chunks of work (e.g. "create the web form and have it accept the data")

* Write a chunk of code and see its effect on the software

* Find unexpected behavior (i.e. "debug" the feature)

* Fix the unexpected behavior to match the desired one

Ideally, the loop above is not performed once for an the entire feature but many times on tiny, individual parts of it (writing tests for each small step is even better). By this definition I probably spend 50 % of my time "debugging" code, if not more.

Debugging is also the most important skill that I try to teach to other programmers when onboarding them into a team. Why? Because a programmer that is effective at debugging will save himself/herself and everyone else on the team an incredible amount of time. Developers that aren't able to efficiently debug problems themselves will get stuck frequently, which means that someone else on the team has to "unblock" them by doing the debugging for them. In that case, the "debugger" will usually be a more experienced team member, which means your team will waste not only the time of the inexperienced developer, but also that of the experienced one. I believe this is the main reason that adding another programmer to a large team can actually slow progress down rather than accelerating it.

On the other hand it's of course the responsibility of the experienced developers and the team lead to make sure that only a minimum amount of (unexpected) debugging is required to begin with. In practice this means having (among other things) strict development guidelines, software tests, a continuous integration system, very good documentation and a thorough code review process.

Also, I might be saying nonsense here but I think the reason that people from Physics or other STEM fields are usually very good programmers is that they are thaught a lot of "debugging" skills during their training, especially in experimental fields.

<comment><USER3> _Also, I might be saying nonsense here but I think the reason that people from Physics or other STEM fields are usually very good programmers is that they are thaught a lot of "debugging" skills during their training, especially in experimental fields._

I believe this is true, at least for myself, if you limit the STEM to Science, but I'll note it starts with your first bullet point, "Make a mental model". Here's a pretty good (top Google "process of science") diagram and description of the The Scientific Process: [http://www2.nau.edu/~gaud/bio372/class/behavior/sciproc.htm](http://www2.nau.edu/~gaud/bio372/class/behavior/sciproc.htm) and you can see how pretty much every part of it has direct utility in the mechanics of software development.

I'm weaseling with "the mechanics" because software development almost always involves a lot more direct, unscripted, and frequent interaction with other people. By comparison, what happens in science can be a lot more constrained, with the closest part of that sort of thing being funding. You also need to keep the people who you're delivering your results to happy, be they scientific journals or superiors and peers who need them for more direct uses, and having a working relationship with those under you, which for a PI could be postdocs, grad and undergrad students, and lab techs. And depending on the field the usual bureaucracy regulating what you do.

The mentoring model is almost infinitely stronger in science. When you're an undergrad, you get mentored by your grad student TAs, and if your smart, you spend at least a little time your favorite professors (in the best cases, they get free or much cheaper labor, potentially on high risk and/or apparently low gain work). In my personal experience, if you don't waste their time, Nobelists are at minimum happy to provide a little advice in passing.

The grad students both mentor the undergrads and are mentored by their PI and his more experienced postdocs and grad students, it's an apprenticeship model. Once you have your Ph.D., there's still a good chance you'll do, or should so, some mentoring in whatever lab you end up in, industrial or academic. In the academic track you'll be expected to formally teach classes, and good schools will demand adequate performance. If a PI, you cultivate your crew of lab techs, students, and postdocs. Personal reputation is also more generally important, especially lower down.

(Note that I've seen these positive behaviors at 3 levels of academic institutions, the low end one level above community college 4 year college where the professors are there to teach, a highest end "R1" university, and a middling "high research activity" university.)

Hmmm, there's also a lot of gatekeeping in science which isn't present in our field. It's legendary how many "college dropouts" for whatever reason ($$$ in mine) go on to be successful, whereas it probably isn't easy to become a bottom of the totem pole lab tech without an undergraduate degree. Which is the gateway to grad school and the Ph.D. where you can become more independent, and doing that in the American model requires passing quals, doing original research and defending that. There are of course exceptions to the typical path, but they're a lot more unusual.

<comment><USER2> very good points, thanks for sharing!

</comment></comment></comment><comment><USER4> Also of interest, "How do you fix a bug you can't replicate?"

[http://stackoverflow.com/a/1268464/59087](http://stackoverflow.com/a/1268464/59087)

<comment><USER5> Install a exception reporting tool and get a stack trace for it. My favorite (disclaimer, I now work for them) is Rollbar.

</comment></comment><comment><USER6> God, I just love the Chrome debugger. It is, hands-down, my favorite computing environment.

<comment> wh-uws Ever use it with node?

Its pretty awesome [https://github.com/node-inspector/node- inspector](https://github.com/node-inspector/node-inspector)

<comment><USER6> yeah, but with limited success. Loads sloooowly.

</comment></comment></comment><comment><USER7> _my work requires that I write JavaScript. Vanilla JavaScript, not JavaScript that interacts with the DOM._

Does he means he only uses JS for scripting CSS and producing information?

<comment><USER8> I think he just means that the vast majority of his time is spent in the actual "business" js code rather than "glue" js code.

And i kind of feel similar. I spend most of my time coding the actual app, making tests, etc... Less than 10% of it is just taking data from the dom, and putting it back in.

(this is all for web-app style things instead of your average website)</comment></comment>


What It Means to Be "Wavy" Max B, Kanye West and Paul Graham - <AUTHOR> https://www.reddit.com/r/Kanye/comments/4e6zra/what_does_it_mean_for_kanye_to_keep_it_wavy/ <comment><AUTHOR> Getting this explanation requires familiarity with Kanye West's recent album anti-release, "The Life of Pablo," which includes an interlude voicemail from hip hop artist, Max B.</comment>


How Sketch Took on Adobe - <AUTHOR> https://producthabits.com/how-sketch-took-on-adobe-by-making-a-faster-leaner-cheaper-image-editor/ <comment><USER3> > Omvlee decided to design his application to run natively on OS X. This was > very smart. Although Omvlee could have reached a considerably wider audience > by designing Sketch for Windows (or OS X and Windows), focusing on the Mac > market was highly strategic

Sketch exists thanks to the genius of Quartz / Core Graphics. It does not have a rendering engine per se and struggles even with path ops [1].

This technical debt may soon be the end of Sketch. Because apart from Adobe, there is now Figma with smart people like Evan Wallace who can really "decide" [2][3].

With C++ core, Figma can go fully native [4], and it's puzzling why they have done this already.

[1] [https://twitter.com/vmdanilov/status/892358827378696194](https://twitter.com/vmdanilov/status/892358827378696194)

[2] [https://www.figma.com/blog/building-a-professional-design- to...](https://www.figma.com/blog/building-a-professional-design-tool-on-the- web/)

[3] [https://medium.com/@evanwallace/easy-scalable-text- rendering...](https://medium.com/@evanwallace/easy-scalable-text-rendering-on- the-gpu-c3f4d782c5ac)

[4] [https://twitter.com/evanwallace/status/673959396104273921](https://twitter.com/evanwallace/status/673959396104273921)

<comment><USER4> There is also Affinity Designer.

Sketch became a good enough default very quickly, but there are starting to be several competitors that are just as good if not way better.

<comment><USER5> Affinity Designer is also does not have the psuedo subscription style that Sketch uses.

They also allow you to install it in as many machines as you like. Sketch forces you to buy a license for each of your computers.

<comment><USER6> I'm glad you mentioned this. There are many reasons why I'm no longer using Sketch, but their weird pricing model is _the_ reason I finally decided enough was enough.

</comment></comment></comment></comment><comment><USER7> It is a nice PR article, but if i was working at Bohemian, I wouldn't get overly confident. Sketch indeed did a nice job, and they carved out a market segment, but in doing so they caught Adobe's attention and it now responded by launching XD. As with a corporation that size, the response was maybe slow, but it is picking up steam and I speculate that in a few years XD will be an extremely tough competitor for Sketch. XD is already fairly good (sometimes better), it's already cross-platform, and Adobe has a relatively large and rather competent team of developers working on it. So I have little doubt that they'll soon have a better product on most, if not all aspects (1). The only thing that could derail it at this point is loss of executive support, but there's absolutely no sign of that, and I doubt it will happen.

[disclaimer: I work for Adobe, but these are absolutely personal opinions, nothing vetted by my employer. And I don't work at XD, though I do know lots of people who do. ]

(1) Adobe did that before. Witness e.g. Lightroom vs. Aperture, InDesign vs. Quark. It can be a formidable competitor when it's serious about something. And I get the feeling this time they are.

<comment><USER8> > XD is already fairly good (sometimes better)

I think you working at Adobe make you a little delusional about XD. I can bet that you have never actually used XD for any serious work if you really think that it's already good or even better than Sketch. It's nowhere near as good as sketch and is very incomplete, heck they added dotted line support only a few months ago. Figma and maybe Framer(a little different) are the biggest competition for sketch now imo. XD is mainly used by those who were still stuck in photoshop and now are trying to move to something better.

<comment><USER7> > a little delusional about XD.

By "sometimes better" I meant "some aspects", not necessarily that it's overall better right now (and especially not for everybody - it might never be "better for everybody" simply because people are very diverse in needs and preferences).

I wouldn't call it "delusional"; "biased" maybe - that's why I called out my affiliation to Adobe. Makes me know some things, and also makes me biased. Yes I'm a developer, not a designer, and have never used XD (I don't work on it) - so feel free to take what I say with a grain of salt. It's still a datapoint, I actually believe that XD will be a significant competitor in the years to come. You're free to believe I'm wrong - but don't think that I'm saying it just to support my employer, it's not the case.

</comment></comment></comment><comment><USER9> Big reason for this is probably pricing. Adobe's subscription model is hard on startups, small companies & especially individuals, so people naturally look at alternatives. And then they realize that Photoshop isn't quite the monopoly it once was, and apps like Sketch, Affinity & Co. offer similar feature set, while also being more specialized for the job.

<comment><USER10> Pricing is a part of it, sure, but the real reason I think is that Sketch was designed from the group up to be a tool for creating digital UI. Without the clutter and legacy of Adobe Illustrator / Photoshop, it was a breath of fresh air. Also, I think it has an important advantage of feeling like a native Mac app. I always feel like I'm firing up a virtual machine when I start Adobe products.

<comment><USER11> My fairly recent MacBook boots up in less time than Photoshop takes to open.

Photoshop is amazing and I use it daily, but my goodness does it creak.

<comment><USER12> Photoshop is 'slow to open' because it takes more time than your laptop uses to boot? That's nothing - have you never used GIMP?

<comment><USER13> On my aging Lynnfield i5 and spinning-rust HDD, GIMP takes 2 seconds to open (I just timed it - from pressing return in a terminal, to all windows appearing on screen). That is faster than most websites load these days. And I should add that I have quite a lot of custom Python plug-ins installed.

There's a lot of valid points that can be criticized about GIMP. Speed is not one of them.

<comment><USER14> Same here. For small tasks I use GIMP because it's a lot faster.

Loading my VM is faster than loading any Adobe products.

</comment></comment></comment></comment></comment></comment><comment><USER15> I was surprised this article doesn't mention DrawIt [1], Bohemian Coding's first (?) drawing app designed for UI elements and icons, which would seem rather familiar to any Sketch user today. It combined vector and pixel graphics, and allowed you to compose any number of effects like blurs, borders, shadows, bevels etc in a non-destructive stack.

Sketch was launched a few years later [2], and the way I remember it, it first focused more on vector art illustration on an infinite canvas. It was only later that DrawIt was retired while Sketch took over a lot of the UI/icon tools.

I always felt like the Sketch we have today is much more like the first version of DrawIt than the first version of Sketch.

1: [https://web.archive.org/web/20090609142331/http://www.bohemi...](https://web.archive.org/web/20090609142331/http://www.bohemiancoding.com:80/drawit/index.html)

2: [https://web.archive.org/web/20110225224308/http://www.bohemi...](https://web.archive.org/web/20110225224308/http://www.bohemiancoding.com/)

</comment><comment><USER16> I've always been upset about the fact that Adobe abandoned Fireworks. Fireworks always made sense to me when I had to cobble together graphics for my websites or apps. Adobe behaves like a company not interested in expanding their market, but just simply doubling down on it's existing cash cows until the day they become irrelevant.

<comment><USER17> Same here - Illustrator absorbed a lot of Fireworks features and offers decent optimised JPG/PNG/SVG exports for web, but over the last few years it's become excruciatingly slow while not really adding any new functionality.

Even with a 24 thread CPU and 1080Ti it drops frames constantly, even when the document contains just a single circle. It regularly hangs for a second or two when zooming or adding new shapes or text to the document. After Effects & Premiere are even slower for video editing and are the cause of much swearing in our office.

If Sketch and Figma can smoothly display 100+ populated screens with plenty of functionality then more power to them, we're definitely due competition in the graphics & video market.

</comment></comment><comment><USER18> The article should have also covered Figma, as I expect it to chew a large chunk of Sketch's market share.

In my company almost every designer switched over from Sketch to Figma because of the collaboration and reviewing abilities. Designers invite developers (including remotes) to a read-only view on which they can place comments. This works really good.

Maybe Sketch Cloud offers the same? It didn't catch on at our place.

<comment><USER19> Not directly in Sketch, but our team uses Zeplin[0], which integrates with Sketch, for that use case. Our designers still prefer Sketch, and Zeplin has become an integral part of our workflow.

[0] - [https://zeplin.io](https://zeplin.io)

<comment><USER20> I love the dimensions and color data you see when you hover over the main CTA on their homepage. Brilliant design

</comment></comment></comment><comment><USER21> > Omvlee was very smart to target a large segment of the graphics sector's > largest, most powerful incumbent, as doing so created major tailwind for > Sketch. Omvlee came to market with a differentiated product that was far > better than even Adobe's flagship product.

Great tip: just create something better than the household product for a large segment. Why did I never think of that....

<comment><USER21> On a more positive note:

What I really like about the Sketch story (correct me if I'm wrong), is that a small product-first focused company can make a big enough dent in an existing market. Kind of refreshing between all these marketing/sales-first VC fast growing in employee size companies with a bad fluff/action ratio.

<comment><USER22> Is it an existing market? I got the impression a lot of their work and success has been around prototyping mobile applications. This is a niche nobody served and grew quite quickly.

<comment><USER23> I think you could say it was a niche in an existing broader market, which had previously been covered by Illustrator and Photoshop. Sketch came along with a focused tool which did it better than the general-purpose tools. But it's not like UI protoyping was impossible before Sketch came along.

</comment></comment></comment></comment><comment><USER24> > In the blog post announcing the move, Omvlee cited three reasons for his > decision to abandon the Mac App Store in favor of direct sales: ... Apple's > insistence that desktop apps available through the Mac App Store be > sandboxed for additional security, a stipulation that was impractical for > Sketch.

I'm surprised by that. I'd have thought a user-document-based app like Sketch would be ideal for sandboxing.

</comment><comment><USER25> Absolutely love Sketch. I got a license because I thought it would be useful for UI design, but have been using it for all sorts of other things until I've trained properly on it (such as room layout planning, etc). Looking forward to using it for UX design when I know it a little better (I'm not a designer), but I also think it could become my go-to SVG generator (from what I've browsed on training courses from Lynda and Pluralsight).

</comment><comment><USER26> And then Adobe released XD. I give Sketch about 3 more years before it becomes completely irrelevant.

<comment><USER11> Adobe have been working on XD for ages and it still doesn't hold a candle to Sketch. It feels like it's born out of a scramble against Sketch, rather than from a deep desire to create the best interface design tool.

There was a gap in the market ever since they killed Fireworks, and if they were serious about filling it they could have done something years before Sketch became big, but instead they slapped a few ui-focused features onto Photoshop, sat back and called it a day.

<comment><USER7> Adobe _is_ serious about XD, though. There were some decisions which in hindsight might've been suboptimal, let's say. So XD didn't move as fast as many expected. But I feel it's picking up speed. Did you use it recently? As I understand it, while it may not be better for everybody just yet, it definitely holds a candle to Sketch now.

<comment><USER11> Yes, I'm always open to new tools and ways of doing things.

I give it a try every time there's a major update, hoping that this time it'll be good. There's always something which makes me go 'not today'.

For example the recent voice prototyping features are an interesting gimmick, but I'd rather they solve some of the basic stuff first.

</comment></comment></comment></comment><comment><USER27> Maybe for macOS users, because it is nowhere to be seen on Windows.

<comment><USER28> I don't know what they use to build Sketch. Probably Cocoa. If they use Electron, Sketch can be used even in Linux. But then you would have some people complain about the performance. You can not make everyone happy! :)

But I think they can have the cake and eat it too if they use Qt. But the price of Qt library is quite steep (USD 5500 per year). I know, I know, you can use it freely if you use dynamic linking. But still....

<comment><USER29> They don't use Electron. Their website states that they don't plan to release Windows or Linux versions because of the large amount of native MacOS API's they use making it very time consuming and costly to make a cross-platform version of the app.

<comment><USER30> I guess there's a market for a windows/linux version of this app then? (tho' maybe not as large, given pro-designer tendencies towards macs)

<comment><USER31> There's a third-party app for Windows called Lunacy [1] that can read/write Sketch files, so there must be a market large enough to make that worthwhile.

[1] [https://icons8.com/lunacy](https://icons8.com/lunacy)

</comment></comment></comment></comment></comment><comment><USER32> Wasn't there OmniGraffle on the Mac even before Sketch? Seemed to me in the beginning that Sketch was an exact clone of OmniGraffle with a little nicer interface. Sketch evolved a lot from that point on.

Edit: OmniGraffle 1.0 launched 2001 [1], Sketch started 2008

[1] [https://www.macworld.com/article/1002530/omnigraffe.html](https://www.macworld.com/article/1002530/omnigraffe.html)

<comment><USER33> OmniGraffle is for diagrams, general purpose vector drawing and UI design is not its forte. At best you do some prototype wireframing there.

<comment><USER34> Yeah, OmniGraffle is awesome for diagramming, but awkward even for low-fi wireframes.

</comment></comment></comment><comment><USER12> > We also know that Omvlee decided to monetize his product almost immediately. > This wasn't part of a larger revenue strategy; as a student, Omvlee was > living a humble lifestyle and needed the [f]unds ...

An interesting case of something that was clearly started as a "lifestyle business", but then managed to grow quite organically, with no real need for 'institutional' involvement.

</comment><comment><USER35> And today we have Adobe XD which is free. Actually I used it recently to open a .sketch file from a designer and it is the best free tool to open that files... what irony. Also a sign that Adobe really fears Sketch and now they are playing "here it is free" game :(

<comment><USER7> Adobe XD is __not __free - it was free while in beta, now it is a launched product that costs money.

[https://www.adobe.com/products/xd/compare- plans.html](https://www.adobe.com/products/xd/compare-plans.html)

<comment><USER35> I see a free starter plan there.

<comment><USER7> Right, but that's very different from "Adobe XD is free". You wouldn't call AWS "free", would you? (ok, this is an extreme difference, but for all we know, it's only a matter of time until the non-free versions become differentiated enough. It's not like Adobe doesn't know marketing)

<comment><USER36> The only difference between the free (Starter plan) and paid version is that the free version limits you to sharing one prototype at at time.

Thats it. Otherwise, functionality is the same.

</comment></comment></comment></comment></comment><comment><USER37> From a tech perspective what's the reason the Windows version of this is so allusive? Are there OS hooks that are so powerful on Mac that make a parallel development for windows an insurmountable task?

Said from a windows ubuntu tech shop

<comment><USER38> Sketch heavily uses macOS specific APIs for drawing, hardware acceleration, widgets, etc - I'd imagine Windows version would be a nearly complete rewrite with much higher subsequent development costs.

<comment><USER39> Which is interesting because Adobe XD also heavily uses MacOS specific API's and had to do a complete rewrite to support Windows. But Adobe has the manpower to do that.

</comment></comment></comment><comment><USER40> I'm absolutely happy people are taking on Illustrator/XD. I was a freelance illustrator specializing in print while in college, and have grown dislike Illustrator.

The issues I'm having now with most design and vector art tools now are:

* No Offline Support * No Linux Support.

That leaves us with... well, just Inkscape. Honestly it has gotten decent with the most recent version. We finally have an objects menu, after 5 years of development. But features are still behind Sketch, AI, and Affinity.

I'm well aware Linux users who are into drawing or design are a small minority, so I can't really complain.

<comment><USER41> Try [https://www.figma.com/](https://www.figma.com/) ?

<comment><USER40> I checked Figma out before, afaik it doesn't let me locally save my files and work on them without Internet on Linux.

Is that still the case now?

<comment><USER42> Afaik that is still the case — they seem to have stuck with the web version. I used Gravit for a while, but they got bought by Corel and the application has gone from free to $100 for the "fully-featured" version (which given it's basically a beta and is missing what I consider key features, is a bit much). Akira [1] looks like it could possibly be the answer, but it's still a way off (though usable)

[1] [https://github.com/Alecaddd/Akira](https://github.com/Alecaddd/Akira)

</comment></comment></comment></comment><comment><USER43> How does Figma compare to Sketch?

The article is completely focused on Adobe but Sketch's greatest competition moving forward is from the free-to-get-started Figma. Not one mention of that.

In fact the article kind of whiffs on this as it concludes that "Omvlee's refusal to accept venture funding" was a "major driver of growth." Ehh.. really? Figma's funding has been a major factor in helping it do in a couple years what took Sketch a decade.

</comment><comment><USER44> Sketch allows anyone more access to really fuck up a design. Looks good, some of the plugins/extensions are top notch but overall, it took the best of ideas from inDesign and Illustrator and bastardized it and somehow people believe it's better. It's different, it's new, but it's not better.

It's good for agencies and freelancers. We use it in corporate just to get the agencies to give us something better than a PDF.

</comment><comment><USER45> I remember the buzz when Sketch 2 came out in 2012. Tons of us switched immediately. Whilst I think Sketch has stagnated since then, what it initially offered was a lightweight tool that was designed around the types of primitives we used as designers.

Most notably, CSS3 border radiuses were finally being supported, and doing them in Photoshop was awful. It was really simple stuff like that. It just felt right at the time.

</comment><comment><USER46> The periodic references (mostly in a slightly negative tone) to not taking on funding were confusing.

</comment><comment><USER47> They were the first but loosing created market to figma and other tools

</comment><comment><USER48> Sketch fit into the niche left behind when Adobe killed Fireworks.

</comment><comment><USER49> There is still no photoshop substitute though

<comment><USER45> Affinity make great products

</comment></comment><comment><USER50> But have the really took over? I see designers who have shifted to Sketch pretty happy compared to using Photoshop or Illustrator to design something.

</comment><comment><USER51> Let me un-editorialise the title a bit:

"How Sketch Took on Adobe by Making a Faster, Leaner, Cheaper Image Editor, which is kind-of-useful for a very specific field -as long as it works properly- and leaving Adobe pretty much to be the standard for everything else (but catching up, see XD)"

<comment><USER27> And constrained to the few souls that use macOS for doing design.

Which outside SV and first world countries isn't quite true.

Might still be enough for Sketch to keep an healthy business but hardly enough to actually hit Adobe's business line.

<comment><USER52> Most professional designers are still using Macs.

<comment><USER27> So the countries where Apple doesn't have a presence don't have professional designers?

<comment><USER53> What countries are they?

<comment><USER27> Lots of countries where earning at least 500 euros per month is a dream come true.

Where getting a mac mini might mean an imported device from somewhere else, and three to four months salary.

We are on HN, you can easily find them.

</comment></comment></comment></comment></comment></comment><comment><USER54> I wonder why there aren't other cross platform sketch equivalent.

Question for cross platform experts:

If today, you were to create an app supporting Linux, Windows, Mac - <USER2> toolkit/framework we must use?

<comment><USER55> There exist a great one, which is called Figma. They use electron in combination with WebAssembly to make it fast. I'd say that's a pretty decent choice.

<comment><USER30> jumping straight into webassembly! very brave ... or is it actually more mature (production-mature?) than I thought?

<comment><USER55> Well, the support is pretty decent in evergreen browsers (and it already was for a while), and in case of electron, you have precise control over your runtime, so it's not really a problem. Also many engines have already done quite substantial optimizations for handling wasm modules in combination with JavaScript. It's all done with backward compatibility in mind, so what works today will continue to do so.</comment></comment></comment></comment>


Algorithm can create new Van Gogh or Picasso in an hour - <AUTHOR> http://www.washingtonpost.com/news/innovations/wp/2015/08/31/this-algorithm-can-create-a-new-van-gogh-or-picasso-in-just-an-hour/?postshare=9081441069630944

<comment><USER2> This article has a clickbait headline and no technical details. Here's the actual (pre-print) paper on this technique: [http://arxiv.org/abs/1508.06576](http://arxiv.org/abs/1508.06576)

<comment><USER3> HN discussion of the paper: [https://news.ycombinator.com/item?id=10141516](https://news.ycombinator.com/item?id=10141516)

<comment><AUTHOR> Thanks for both these extra links -- I missed the previous HN discussion (of the paper) due to searching for Van Gogh / Picasso rather than anything else.

Whilst I agree the Washington Post article is rather lacking in technical details, it does provide a pretty nice visual idea of what the paper is about, which I think helps (and this comment thread means people can now find the paper very easily too!).

</comment></comment></comment><comment><USER4> _Of course, the machines don't have a style all their own. They can only copy existing styles. True creativity is a greater challenge that machines have yet to master._

It seems to me that human artists take styles they have seen, blend it with their experiences and create their own style.

Blending multiple painting styles is just a tweak in the training....

<comment><USER5> Well, that isn't the only thing. I guess what others might complain about is the lack of composition, structured use of color, etc.

As much as paintings look similar, generated ones do not have a proper structure, the applied colors do not match the original intent and are often misplaced.

One of the obvious flaws is the reflection of the houses in the water, the painting isn't structured and the system isn't capable of discovering that kind of structure.

Paper on the other hand shows a very nice method of finding unique filters from given examples, and the results are amazing.

</comment></comment><comment><USER6> Meanwhile, you can play with this:

[https://github.com/Lasagne/Recipes/blob/master/examples/styl...](https://github.com/Lasagne/Recipes/blob/master/examples/styletransfer/Art%20Style%20Transfer.ipynb)

</comment><comment><USER7> What's more interesting than the article are the comments below it. The average person isn't commenting on what a cool deep learning breakthrough this is.

If AI is ever _actually_ realized, it will occur along with a fit of conniptions about how "fake" it is. Well... at least until people fail to pass a double-blind test distinguishing between human and AI creations.

<comment><USER8> Yes, we're all fakes to that extent. People who are unconvinced should read Braitenberg's Vehicles (1984).

</comment></comment><comment><USER9> I wonder what the output of the inverse would look like.. If it's fed a database of "real world" and run on a Van Gogh.

</comment><comment><USER10> This Algorithm doesn't create a Van Gogh or a Picasso, but rather merges an artists style with another. If the algorithm were given two different photographs, what would the result be?

This is clearly pointed out in the Gandalf example. Though the resulting image may mimic Picasso's style of line and color, as a whole, it was unable to recreate the randomness and asymmetry of Picasso's style.

</comment><comment><USER11> This was already shared 6 days ago by user midko ..

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

</comment><comment><USER12> I wonder which camera app will implement first.</comment>


Fat JSON - <AUTHOR> https://www.tbray.org/ongoing/When/201x/2014/05/05/Fat-JSON <comment><USER3> An update on Keybase, since it was chosen as the example. The API now supports field declarations. For example, these all work:

       https://keybase.io/_/api/1.0/user/lookup.json?username=chris&fields=basics,pictures
       https://keybase.io/_/api/1.0/user/lookup.json?username=chris&fields=basics,pictures,profile
       https://keybase.io/_/api/1.0/user/lookup.json?username=chris&fields=basics,public_keys

This change was intended from the beginning, but we are still in alpha. It was a quick addition, so the HN post made it timely. The nice thing is that this isn't just a client-sensitive change. Loading a user's info is module, so those above examples should be faster and less work for our server than getting everything about someone.

<comment><USER3> I should add that we're not fundamentally opposed to some kind of query language in the API requests, but most of our API objects lend themselves pretty well to just passing a list of fields you want. The above technique is very simple and seems to work well.

Aside, it also has cross-origin support (as does search), just added for anyone who wants to interface with Keybase on another web page, in the front end.

</comment></comment><comment><USER4> I'm a little surprised not to hear any mention of JSON Pointer (RFC 6901). It deals with exactly this:

[http://tools.ietf.org/html/rfc6901](http://tools.ietf.org/html/rfc6901)

With JSON Pointer syntax, it would be something like:

        JWalk.getStringPtr(user, "/them/public_keys/primary/bundle");

It's concise, complete/unambiguous, and has implementations in a growing number of environments, so I think it could be worth mentioning as an approach. It also defines a useful URL fragment syntax for referencing nodes within documents, which would be a good thing for the JSON world.

<comment><USER5> Oh dear, I've probably hurt some feelings for having missed 6901. Interesting that when I googled around for JSON analogues of XPath, I didn't turn that up. Having said that, it's not obvious that _any_ syntax is a win; an list of strings is an excellent selector that hits an 80/20 point & meets all my needs.

</comment></comment><comment><USER6> I make heavy use of a similar thing in PHP. I have a function "lookup" which lets me say:

        lookup($foo, array('bar', 'baz' 15, 'quux'))

This is equivalent to any of the following:

        $foo->bar->baz[15]->quux
        $foo->bar->baz[15]['quux']
        $foo->bar['baz'][15]->quux
        $foo->bar['baz'][15]['quux']
        $foo['bar']->baz[15->quux
        ... and so on

It's useful in Drupal when the required data is often at the end of a long chain of objects-containing-arrays-containing-objects-....

I've been a bit naughty with its types for the sake of convenience: if a non- array is given as the second argument, it's wrapped as a singleton array, ie.

        lookup(array('foo' => 'bar'), 'foo') === 'bar'

Also if any of the components aren't found, it returns NULL, ie.

        lookup(array('foo' => NULL), 'foo') === lookup(array(), 'foo')

It would be theoretically better to return an empty array on error and a singleton array on success, since they can be distinguished, but in practice that's so far down the list of problems with PHP that it's not worth the effort of adding such wrappers at the moment.

A really nice thing about this function is that it curries nicely:

        $find_in_foo = partially_apply('lookup', $foo)

        $get_blah = partially_apply(flip('lookup'), 'blah')

        $find_in_foo('x') === lookup($foo, 'x')

        $get_blah($foo) === lookup($foo, 'blah')

Actually, my argument-flipping function is already curried, so I can just say:

        $get_blah = flip('lookup', $foo)

This currying is great for filtering, mapping, etc.

<comment><USER7> Hi, Drupal dev here. Got to the point yesterday afternoon where I'm going to have to implement exactly what you've already done in order to put out some reasonable JSON from a node_load_multiple call. Don't suppose you have this function in a gist anywhere, do you? Please?

<comment><USER6> Here's the definition and a few tests.

[https://gist.github.com/Warbo/9d8425fcdd7c026c795a](https://gist.github.com/Warbo/9d8425fcdd7c026c795a)

The SimpleTest test class probably doesn't work as-is, since it is originally derived from our own class hierarchy, but shouldn't be too hard to fix.

</comment></comment></comment><comment><USER8> Honestly, what's happening here is that you've hit the limit of JSON. JSON trades fairly significant verbosity for ease-of-use... when it stops being easy-to-use, well, you've stopped needing JSON. While you may be forced to hack around it, I'm not sure I'd spend _too_ much time trying to figure out how to be principled in that hacking, because hacking it shall ever be.

JSON's nifty and convenient, but it's _huge_... with JSON from "the wild" I often find it gzips by a factor of 16. And that's just gzip, which isn't even the best at this sort of thing. If the API provides only a vague question that you can ask it, and it hands you back a huge chunk of very fluffily-serialized data, well... in a lot of ways you've already lost, twice (once for fluffy serialization and once for a presumably-foreign API giving you too much data).

<comment><USER9> Not too long ago on a personal Android app I was dealing with huge JSON strings that would take 2 seconds to decode on my test phone. I started cheating by plucking substrings out of the response and parsing them, cutting the parse time down by a factor of 10. Thankfully the server never changed the order of their response fields.

<comment><USER10> Sounds robust... Doesn't that defeat the purpose of JSON?

<comment><USER9> Hence why I called it "cheating" and I was "thankful" that the server never re-ordered fields (since proper JSON fields have absolutely no guarantee on order).

</comment></comment></comment></comment><comment><USER11> I feel like Tim (like a lot of people connected to the web standards community and systems-oriented folks in general) rushes too quickly to thinking about how to standardize and generalize an approach to breaking down large JSON documents like this. But this isn't a standards failure, it's just an API failure. APIs will always need to be refined in various ways after they're released. A "standard" method of asking the server to chop up a JSON document for you would solve this particular problem, at the expense of creating a lot more work on the server side (likely a new layer of abstraction), and there's a limit to how useful that is. Versus just tweaking the API to make it more focused and flexible is a process that's _always_ going to be necessary, no matter what JPath/JWalk/etc standards are developed.

<comment><USER12> > ...it's just an API failure

This. As far as the bandwidth issue goes, effective use of caching and compression can go a long way. Schemes varying the responses via the URL compromise schema validation based on media type (see JSON Schema, for example). Specific cases where fat or thin requests truly make a difference can be addressed with additional media types.

</comment></comment><comment><USER13> I had this exact problem in Python and wanted to be able to use dot-notation (i.e "book.metadata.title") to query the structure (like MongoDB, etc do) so built my own library for doing it:

[https://github.com/imranghory/pson](https://github.com/imranghory/pson)

(Also available from pypi via "pip install pson")

<comment><USER14>
      class MyDict(object):
        def __init__(self, d):
          self.__dict__.extend(d)
        def __repr__(self):
          return repr(self.__dict__)

      import json
      r = json.loads('{"body": {"translations": [{"tr...', object_hook=MyDict)

      >>> r.header.title
      u'Hello World'

      >>> r.body.translations[1]
      {u'translation': u'guten tag', u'language': u'german'}

      >>> map(attrgetter('language'), r.body.translations)
      [u'french', u'german']

<comment><USER13> The code in the library is actually pretty simple, but deals with many practical edge-cases (stepping into an array, handling missing values gracefully, etc.) that the above code doesn't.

My longer term intention is adding other useful json manipulation and search functions to the library.

<comment><USER14> Yeah. I just don't like putting syntax in a string; I'd rather use Python itself.

By the way, you should remove the pprint import from the library, since you don't use it :)

<comment><USER13> I considered that approach but found the JSON returned by some third-party apis contained characters in keys (dashes, spaces, etc) which have special meanings in python so can't be used natively.

</comment></comment></comment></comment></comment><comment><USER15> Somewhat related, jq is a command-line utility which allows filtering JSON data, and uses its own path/filter syntax:

[http://stedolan.github.io/jq/](http://stedolan.github.io/jq/)

<comment><USER16> Quite related to this somewhat related thing, jgrep also does filtering and selection on JSON data:

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

<comment><USER17> Somewhat in relation to these things that are related, pipeline is a DSL for manipulating JSON in a Unixy manner.

[http://github.com/qnectar/pipeline](http://github.com/qnectar/pipeline)

</comment></comment></comment><comment><USER18> This is immediately solved by Lenses

        _Object . key "them" . key "public_keys" . key "primary" . key "bundle"

which you might complain saying that this is yet another idiosyncratic method of traversing data types. In fact this whole thread is full of examples of other idiosyncratic methods of traversing (JSON only) data types.

Except lenses aren't. Lenses are _highly principled_ and compose and combine in ridiculous ways while maintaining their exact behavior. Half the features proposed in this thread exist naturally and "emergently" by the nature of lenses. Finally, they follow mathematical laws describing how everything should work together all to the T.

At the highest level a Lens is a getter plus a setter bound together. You can extract either component to get or set a subpart of a value.

At the next level, you can take note that lenses "compose" (as a category) by letting you reach deeper and deeper into a structure. This is what I took advantage of with the JSON example above: composing them with `(.)`.

At the next level, lenses generalize naturally to "traversals" which target multiple subparts all at once and "folds" which build exotic "getters" over multiple targeted subparts.

At the next level, lenses "dualize" to prisms which deal with branching types. This is hard to explain if you haven't used a language with a true sum type (Scala, Haskell, ML, and lets not get into lazy/strict sums) but I used one above to traverse into the "Object" indicating failure if my assumption of the structure of the JSON blob were wrong.

At the next level you generalize these into isomorphisms which have nice mathematical properties determining when two types are identical by giving you invertible mappings between the two. This is like a lens which focuses on the entire type as its "subpart".

([http://hackage.haskell.org/package/lens](http://hackage.haskell.org/package/lens))

\---

At the end of the day there are even more steps in that hierarchy. It sounds ridiculously complex, and it is a little bit to learn. The advantage is, however, that the intuition of "focusing on a subpart" applies over any data type and with pretty near any weird combination of "lens-like" operators you can dream up.

\---

Usually when someone first hears about lenses they say "Oh, getters and setters. I have those already, no big deal". That's really far from the case, however... Lenses end up being the XPath of _everything_.

<comment><USER19> Haskell's Lens package (linked to above) is indeed nice. For a practical quickstart guide, I'de recommend the Github page over the Hackage page:

[https://github.com/ekmett/lens#lens-lenses-folds-and- travers...](https://github.com/ekmett/lens#lens-lenses-folds-and-traversals)

<comment><USER18> Apologies for the self-plug, but I tried to write up a "friendly" intro to the Haskell lens library as well

[https://www.fpcomplete.com/school/to-infinity-and- beyond/pic...](https://www.fpcomplete.com/school/to-infinity-and-beyond/pick- of-the-week/a-little-lens-starter-tutorial)

</comment></comment></comment><comment><USER20> I just don't see how

      JWalk.getString(user, "them", "public_keys", "primary", "bundle");

is better than

      user.them.public_keys.primary.bundle

What am I missing?

<comment><USER21> That JWalk library is in Java so there won't be something you can use dynamically like that.

<comment><USER22> You can use GSON and just parse your objects into POJOs and access them with dot notation.

In fact, now that I think about it, I wonder if you can rig up your POJOs as Java 8 Option<> and remove some of the null checking. I'll have to look into that.

<comment><USER18> That's a good place to start. Basing it on the list monad instead of the option monad gives you traversals with monoidal summaries.

</comment></comment></comment></comment><comment><USER3> Happy to see one of our Keybase API responses used as the example here. I can share our intentions with that API call in the long run, and how it'll end up smaller, which is especially important for mobile devices.

The dictionary describing the user you requested comes back with some high level sub-dictionaries in it: "profile", "basics", "public keys", "pictures", etc., and the API replies, currently, with _all_ the data to which you're entitled. This is quite huge as Tim mentioned in his post.

Server-side we have a module for loading user information, which allows you to request which of these fields you want when loading a "user object". For example, on a certain page of the site we might load a dozen users but only need [user.BASICS, user.PICTURES], so that's the only data that will be loaded.

The API simply doesn't expose this filtering mechanism, yet, as calls the API hit [user.ALL] which is a combo of everything available about a user. So, in essence, all we need to do to trim these down is allow you to pass a filtering parameter.

Btw, going in the other direction, there'll be a way to query for multiple users at once, fattening things back up :-). So for example you could request just basics + pictures for an array of usernames or userids.

</comment><comment><USER23> Help me out here HN... I remember _somewhere_ seeing an API format where you passed up the empty JSON object which you wanted filled and returned.

Something like:

      (request)
      {username:"",address:"",credits:""}

      (response)
      {username:"Manilow, Barry", address:"Hollywood Bowl", credits: 99}

Clearly not optimal, but it worked pretty well and was very intuitive.

<comment><USER24> I think you might be looking for this: [https://news.ycombinator.com/item?id=7681973](https://news.ycombinator.com/item?id=7681973)

<comment><USER23> Not it, but it does about the same thing. Thanks!

</comment></comment></comment><comment><USER25> If you generate your JSON with Java using Jackson, it offers Jackson-Views, a very nifty way to define sets of JSON properties according to use case.

* [http://wiki.fasterxml.com/JacksonJsonViews](http://wiki.fasterxml.com/JacksonJsonViews)

* [http://techtraits.com/programming/2011/08/12/implementing-ja...](http://techtraits.com/programming/2011/08/12/implementing-jackson-views/)

<comment><USER26> Neat! Jackson also has a tree data model that can be used like so:

        user.path("them").path("public_keys").path("primary").path("bundle").textValue(); // null if any node is missing

</comment></comment><comment><USER27> So we're ending up with JSON with schema and query support.

In a couple of years: XML is the new best thing (as people finally realise that they've needed it all along).

<comment><USER28> It's easy to argue with strawmen like you do, but query and schema support was never the problem of XML.

The problem was that XML is a markup language, and JSON is an object notation. It's right in the name. And this results in different tradeoffs for both.

The XML schema was designed to create schemas for documents. This is why different types of schemas evolved specifically for services (like SOAP) but having to be slapped on top of a markup language base, it couldn't be good even though it tried. JSON doesn't have that initial complexity and the goal matches the use.

Just like it'd be silly to write a manual in JSON, it'll forever remain silly to serialize generic object structures in XML.

Now I could also argue XML is a mediocre markup language, and show alternatives, but as they say, that's a whole 'nother story.

<comment><USER29> You're right. It's so much sillier to do this:

        <fruit id="10" name="orange"/>

Than this:

        {"fruit": {"id":10, "name":"orange"}}

because the first one is called a "markup language" and the second one is called an "object notation". I'm not buying it.

<comment><USER30> It can be done like this too:

<fruit> <id>10</id> <name>orange</name> </fruit>

Which one is better? I find it hard to decide, and I believe most people do. And that's why we see it mixed, often in the same XML document.

<comment><USER27> The one you use is better (correct).

<comment><USER31> Utterly disagree. Attributes can actually have validated contents, such as enumerated lists, etc, and are attractively terse.

Over-reliance on elements are why Maven pom files are such a verbose disaster, and probably the main reason why web developers puke when trying to stream data. Restating element names make for illegible, bloated data. Attribute- heavy XML is attractively terse and benefits from validation (unlike JSON).

<comment><USER27> But you can't change an attribute to a composite type in the future easily.

As for maven POMs, I use Netbeans "add dependency" and that's about it so it's a non issue for me.

</comment></comment></comment></comment></comment></comment></comment><comment><USER32> THANK YOU.

I've been raising cain about this in the chef community for some time - <USER2> objects can easily be as large as 128kb+ of json, which can consume over 1-2MB once parsed into a ruby json object. An empty search of a system with over a thousand nodes can consume over a gigabyte of ram!

The worst case I experienced this was writing out an /etc/hosts file, for which you only need two fields : name and ip, of each host, but you still get a list of every cpu core, dimm, etc..

Excited to see the potential examples, I might try to work on into chef if I get time. The chef solution has been to have 'whitelisted attributes' which is a whole mess unto itself.

</comment><comment><USER33> Once you have used a parsing library to create generic data structures (in your programming language) from your JSON all of this no longer has anything to do with JSON, right? That's something that confuses me about this blog post. To me it seems that it talks about a very generic issue in very specific terms.

<comment><USER34> Agreed. In something like JS (or dynamic C#) one could simply access obj.results[0].address.street, which casts the object nesting as useful/self- documenting rather than needlessly complex.

</comment></comment><comment><USER35> Given that someone uses fat JSON, it seems plausible that you'll have to face those sorts of problems (either simple selectors with logic for potentially dealing with multiple responses, or complex selectors into the tree). What you're really saying in JSON-land is something like, "this whole object should be destructured; I just want a flat object with short keys."

That's the right design approach for the "structs" of JSON; it's wrong unilaterally (JSON also has "hashes" with the same syntax, and they should be separated from that context. Similarly you don't want to destructure an array from {data: [1, 2, 3]} into {data_0: 1, data_1: 2, data_2: 3} unless you absolutely have to.)

Once you flatten it, then partial responses for things which return a struct do exactly what you want; you say e.g.:

        ["myQuery", {on: "stuff", _fields: ["a", "b", "c"]}]

and you just get {"a":1,"b":2,"c":3} as your JSON response.

So what I'm saying in summary is that if you write your own APIs you can get this sort of functionality without building a magic tool; the reason that the magic tool is not mainstream is because it's only right for dealing with structs and not hashes (because if there's a hash elsewhere in the object a user might register their own key in the hash called "ctime"); and given that some API gives you a complex structure, flattening it the way you're doing is potentially a little risky because later updates might say that there's another ctime to some other part of the Users object.

</comment><comment><USER36> I must be missing something obvious. How is Tim's JWalk example different than doing:

      try {
         var key = json_object.them.public_keys.primary.bundle;
      } ...

Is it to better allow dynamic keys? More consistent error handling?

<comment><USER37> Well, it's in Java, for one thing.

<comment><USER38> So this "fat JSON" problem is Java's problem, not JSON's, then? The above code could be perfectly valid C#, as well as valid JavaScript.

On the other hand, if you're hardcoding assumptions about the JSON structure into your Java (which you're doing even if you pass a string literal to some API to look up a value for you), you could probably employ some lightweight code generation to spin you up some classes with strongly typed public fields named things like 'them' and 'public_keys' to help you write more idiomatic JSON access code.

<comment><USER37> > So this "fat JSON" problem is Java's problem, not JSON's, then?

Pretty much.

I would expect that Java could offer some sort of solution to this problem, ideally with an accessor syntax similar to what you'd find in Javascript or, as you say, C#. On the other hand, I've never delved deeply enough into Java to know whether it's feasible; I suppose it's possible that the language simply isn't flexible enough to make such a solution workable.

</comment></comment></comment></comment><comment><USER39> If path features became common it would likely lead to even more bloated and less thoughtful APIs.

</comment><comment><USER40> My security senses are tingling. A server evaluating potentially hostile client provided expressions? Proceed with extreme caution.

</comment><comment><USER41> I know everyone is saying this is an oversimplification and just another person rushing to create a library etc, etc. But the fact of the matter is if you ask any Java developer who has dealt with JSONObject they'd probably want to use this. And that says something.

Why can't I make a contract with my JSON parser. Saying: look, last time there was a 200 OK response all of these fields were there. I promise, they'll be there next time too. I don't need to try { get field } catch {} every single time.

The best way around this currently is to hope that the API has a client library, but that just means that every API maintainer now has to write my Java for me too.

I'm not sure what the solution looks like, but I want a modern Java JSON parser that understands how the API landscape looks today. This extends to other languages that are static typed and have exceptions as well.

Edit: for the record OP is Tim Bray who invented the XML spec, so he has some experience with traversing documents.

</comment><comment><USER42> First world problem, man. Important only to the performance obsessed. Most developers concerned about this have too much time and not enough commercial imperative.

<comment><USER23> As we move intelligence to the client, we're starting to use a lot of data queries which were never meant for the wire. (Particularly in IT applications.)

Having a way to filter in those cases would save having to write & maintain a whole new CRUD layer. In the long run, it could even lead to more efficient queries when objects are composed of many records.

</comment></comment><comment><USER43> If only there were some kind of structured query language we could invent that allowed us to choose the fields and records we needed to look at. We could get some kind of standards institute to ratify it so everyone used the same interface.

A pipedream, I know. A crazy, wild pipedream.

<comment><USER31> While we're pipedreaming ....

how about some way to validate streamed data against a schema? Offering such advanced features as ... an array with a single element? Or even crazier, enumerated values.

Maybe even a way to transform streams using a selector-based query syntax. What a world ...

</comment></comment><comment><USER44> I rolled my own solution to this for a mobile turn-based game I have in development. Most of the time, the device is just polling to see whether there's anything that needs updating. As part of my polling query I pass a signature of the current game state (game-round, with a few other bits). On the server, if that checks out, then the reply is tiny. If there's the need for an update, I send back what's changed and update my views on the client- side. It's definitely not the right solution for every scenario, but I've found it works well for my specific situation.

</comment><comment><USER45> RFC 6901 specifies a simple XPath-esque notation.

</comment><comment><USER46> I had a similar idea[0] that I haven't actually had time to finish. The README.md kind of explains where I was thinking of going philosophically. It's a bit out-of-reach with my current workload but I'd love to contribute with others that could tackle the areas I find difficult.

[0] [https://github.com/sebinsua/jstruct](https://github.com/sebinsua/jstruct)

</comment><comment><USER47> The Open Data Protocol (OData) specifies ways to declare server-side filters and to restrict the fields sent in the response.

</comment><comment> zupa-hu This is the typical nice-to-have feature. It takes time to implement, adds server-side overhead, adds complexity but adds very little value. OP is arguing that it costs him resources to traverse the entire JSON. There are way more clients then servers, thus increasing server-load to make it cheaper for the clients sounds weird to me.

<comment><USER48> > There are way more clients then servers, thus increasing server-load to make > it cheaper for the clients sounds weird to me.

It matters if your client is a 1ghz phone with a poor cellular connection. The user _can_ do the filtering on their end, but you're paying for that offloading in terms of a worse experience for the user because of the larger download.

</comment></comment><comment><USER49> JSONSelect lets you do queries on JSON objects using CSS-style selectors. There's an interactive demo here:

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

The code is on github:

[https://github.com/lloyd/JSONSelect](https://github.com/lloyd/JSONSelect)

</comment><comment><USER50> [http://agave.js](http://agave.js) includes (prefix)getPath by default on any object.

        var mockObject = {
          foo: 'bar',
          baz: {
            bam:'boo',
            zar:{
              zog:'something useful'
            }
          }
        }

So:

       mockObject.getPath('/baz/zar/zog')

or, alternatively:

        mockObject.getPath(['baz','zar','zog'])

will return:

        'something useful'

It's also got a bunch of other useful stuff like 'kind' (closest prototype of an object, that works consistently everywhere), number methods like (2).weeks().ago(), and reads more cleanly than underscore as it uses actual methods.

<comment><USER51> The main problem with string-based paths is that the keys are just a string, so an object with slashes embedded in the keys is perfectly valid. So, ambiguity.

<comment><USER50> Yep, that's one reason for the array version.

</comment></comment></comment><comment><USER52> Letting clients choose the fields they want to receive leads to the awkward realization that any generic, flexible and future-proof mechanism for doing this leads to system where a client can suck down an entire website with a single request.

(If clients can choose _not_ to receive some information, then by symmetry, they should also be able to choose to receive some additional information that's not included by default. And since everything is linked to everything else (orders are linked to users, etc.), you end up with a single resource that potentially embeds everything else.)

These systems also break caching, of course, and also to some extent the principle that within-server links are indistinguishable from cross-server links. The web is not optimized for performance or file size.

<comment><USER53> That's really a non-issue though. Just because they can decide to receive less information, it doesn't follow that they _should_ be allowed to receive more. I don't see why this particular type of symmetry would be important or desirable.

The way I've implemented this in the past is to start with a standard API endpoint with a defined data-set that it returns. Then I allow the client to select to receive only a subset of those fields, or make no selection and receive all of the defined fields. The client cannot request fields that are not part of the data-set defined by that endpoint. This is at least as easy to work with going forward as an inflexible return object. The API can be updated to include more data without affecting clients who don't care about that. If there is a breaking change, then that requires a new version, just as it would normally.

</comment></comment><comment><USER54> One of my pet theories when I developed intercooler.js ([http://intercoolerjs.org/](http://intercoolerjs.org/)) was that, by targeting specific UI elements with only the data necessary, you might actually cut _down_ on the amount of data transfer between the client and server when compared with some general JSON APIs, despite the fact that HTML is a less efficient data format.

I'd expect this to hold, in particular, in areas where JSON isn't particularly a particularly efficient encoding mechanism (e.g. tables)

It's an interesting thing to consider, at least.

</comment><comment><USER55> This is definitely a problem. I work with an existing API and am building a mobile client based around it, and while there's limited support for selecting which fields you bring down, it doesn't work for nested object.

This results in a bloated response, which on mobile is a real problem for responsiveness and data costs.

We considered building a proxy which would form responses tailored for the mobile client, but that felt like a hack. Mind you, so does Google's partial response solution.

Maybe some services could allow you to build your own response, creating a custom version of an API just for yourself?

</comment><comment><USER56> Weird I also made a small dot-lens javascript library to do the same thing just the other day...

[https://github.com/jb55/dot-lens](https://github.com/jb55/dot-lens)

It even works for zooming into arrays

</comment><comment><USER57> As I understand it, there's a lot of places overhead creeps in that tends to make this sort of thing vastly more efficient than making multiple calls. Sure you'll maybe send data people don't want this time, but it will probably save processing and networking overhead that would be spent building and sending a long list of the fields they want. When designing an API I tend to lean to being a bit more verbose than I need to be, if only to save the HTTP overhead of another request. At least until HTTP2 helps us out there.

</comment><comment><USER58> Use JSONPath, it's a JSON version of XPath and it's awesome.

[http://goessner.net/articles/JsonPath/](http://goessner.net/articles/JsonPath/)

</comment><comment><USER59> It is important to note that when you accept selected fields to output you must validate those field names as well.

Sometimes people has a giant object from database, and on return they return a subset of it. But someone may make a mistake by iterating over that object to return selected fields.

        if options:
           return {key: object[key] for key in options}
        else:
           return safe_output_for_this_api(object)

So collapse that into safe_output_for_this_api instead :D

</comment><comment><USER60> I do this on a current project. Certain fields are rarely need and turned off by default, others are usually needed and turned on by default. It's not done via a special syntax though, just query parameters, so something like /person/123?bio=false&salary=true. A standard path syntax might be nice but for handcrafted APIs this works well.

The front-end models are reusable and don't really need to care so long as the properties they need are available.

</comment><comment><USER61> The Play framework has JsPath, which I like quite a bit. It allows for traversals of the kind I assume Tim would want to do with XPath.

[http://www.playframework.com/documentation/2.1.1/api/scala/i...](http://www.playframework.com/documentation/2.1.1/api/scala/index.html#play.api.libs.json.JsPath)

</comment><comment><USER62> That sort of syntax reminds me of Objective C's key paths.

      [object valueForKeyPath:@"them.public_keys.primary.bundle"];

which is part of the larger, more in depth, Key-Value coding interface. It was definitely something I missed going back to PHP, Javascript and other languages after using Objective C.

</comment><comment><USER63> We built a jackson extension to offer this sort of friendly filtering automatically with JAX-RS endpoints: [https://github.com/HubSpot/jackson- jaxrs-propertyfiltering](https://github.com/HubSpot/jackson-jaxrs- propertyfiltering)

</comment><comment><USER64> I'm a little late to the party, but I recently wrote something that can help with this problem. It has the added benefit of acting as a kind of reverse proxy:

[http://github.com/alexose/sieve](http://github.com/alexose/sieve)

</comment><comment><USER65> Couldn't a "possibly null" member access operator help here? E.g.:

       var key = user?.them?.public_keys?.primary?.bundle;

where

        object?.property

is equivalent to

        object ? object.property : null

<comment><USER66> I'd rather just have a functions similar to clojure/clojurescript's _get-in_ [0], _update-in_ [1], _assoc-in_ [2], _dissoc-in_ [3] for working with nested objects/arrays. These are pretty easy to write in Python, Ruby, and Javascript, although I'm not aware of any public library that implements them. It really makes working with JSON-returning apis a breeze.

[0] - [http://clojuredocs.org/clojure_core/clojure.core/get- in](http://clojuredocs.org/clojure_core/clojure.core/get-in)

[1] - [http://clojuredocs.org/clojure_core/clojure.core/update- in](http://clojuredocs.org/clojure_core/clojure.core/update-in)

[2] - [http://clojuredocs.org/clojure_core/clojure.core/assoc- in](http://clojuredocs.org/clojure_core/clojure.core/assoc-in)

[3] - [http://clojuredocs.org/clojure_core/clojure.core/dissoc- in](http://clojuredocs.org/clojure_core/clojure.core/dissoc-in)

<comment><USER67> The authors JWalk is basically get-in. Lenses, as popularised by Haskell, solve a similar problem.

</comment></comment></comment><comment><USER68> underscore.js does this with a pick function

_.pick( {a:1,b:2}, "a" );

underscore is cool.

<comment><USER69> If you think underscore is cool, you'll go bananas over lodash.

<comment><USER70> Yet another single letter namespaced project to collide with other single letter namespace projects.

<comment><USER71> lodash is a replacement for underscore, so it's definitely not as bad as all those '$' libraries. Just make sure lodash gets loaded after underscore, since it's a superset (and faster)</comment></comment></comment></comment>


Why Canada's cannabis bubble burst - <AUTHOR> https://www.bbc.com/news/world-us-canada-50664578 <comment><USER2> It seems that convenience is an important factor; access to retail in the most populous province is low, so alternative means of access to the good are still in favor (i.e. black market). Purport the bubble is bursting after examining the system when it is functioning in a less constrained way that rivals the current system (i.e. black market).

"This is especially true in Ontario, Canada's most populous province. Red tape and a cap on the number of cannabis retail outlets have made rollout slow. Retail licenses were awarded by lottery, and the province held the number of licenses at 24, to serve a population of 14.5m."

"In December, the Ontario government announced that after a slow and fitful start, the province will open itself up to more cannabis retail. It will do away with the lottery system, the cap on the number of private stores and cancel some pre-qualification requirements."

List of Canadian Provinces by Population: [https://en.wikipedia.org/wiki/List_of_Canadian_provinces_and...](https://en.wikipedia.org/wiki/List_of_Canadian_provinces_and_territories_by_population)

<comment><USER3> Is it even constitutional for a province to sandbag a federal regulation like this? Retail marijuana sales in Ontario are still effectively illegal.

<comment><USER4> Because it is unconstitutional for the federal government to but into commercial law that is not under it's purview?

<comment><USER5> Provinces aren't states. The powers of the Canadian provincial governments are delegated to them from the Canadian federal government, not the other way around. Canada does not have a constitution that constrains federal power, since it was not formed by the uniting of states wary of federal power, but rather the uniting of colonies which all considered themselves to be under the aegis of a single sovereignty (Britain).

Fun fact: rather than each province having a plain-old governor, Canada (as any Commonwealth country) has one Governor General for the whole country; and then each province has a Lieutenant Governor, _also_ appointed by the Queen, to serve _under_ the Governor General.

<comment><USER4> Provinces aren't states, but, for example, I live in a distinct nation to you (I assume, if you are under the "aegis of Britain" ;)

There is no written constitution, but there are specific acts, charters and traditions that form constitutional law, and define the clear divisions of responsibility between the provincial and federal government. That includes my government's right to set laws about signage of commercial establishments, specific consumer rights I get, and also the commercial law around the sale of both alcohol and cannabis.

<comment><USER5> > I assume, if you are under the "aegis of Britain" ;)

Not me, but certainly the provincial legislative assemblies of 1867 :)

> there are specific acts, charters and traditions that form constitutional > law, and define the clear divisions of responsibility between the provincial > and federal government

The difference is that these powers are a delegation of federal power _to_ the provinces, rather than reservation of state power away _from_ a federation.

The relationship between the federal and provincial governments in Canada is a lot like the relationship between the Queen and the parliament in Britain: in practice, right now, the Queen is powerless; but technically, the parliament's power derives from the Queen, and there's nothing _legally_ stopping a monarch from revoking that delegation of power. In the current cultural climate, that'd be unthinkable; but all it would take is "mere" sectarian shift to allow for it.

<comment><USER6> No, that's not correct. Provincial and federal power are both derived equally and in parallel from the Crown. One is not subordinate to the other.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> You see the same problems in the American market too. Contrast the following experiences. To buy legally, I have to go trek out to my local dispensary, sit outside for 30 min - 1 hour, hope they have what I want when I get inside (no way to check in advance as they have no inventory management), pay 100% more than black market value per quantity, deal with ridiculously arbitrary restrictions on how much and what I am allowed to buy, I have to pay with cash, and I receive product with low potency.

If I want to buy illegally, I can call ping my friend, they tell me the whole inventory in advance, I tell them what I want, they bring it to me for free, I get very high quality product, it's very cheap, and we hang out for a few hours.

Which experience do you think most people choose?

<comment><USER8> Legal. I'm not a heavy user, but legal has been the amazing. I can pick up edibles of known amounts of thc. The sales people are friendly and knowledgeable.

Buying illegally was always sketchy, never knowing if someone would show up, how good the product was, if it actually was indica or sativa or hybrid, it was always just "good shit", which wasn't always true.

Prices feel the same and it's defiantly not lower potency in my experience.

<comment><USER9> I agree, I am in Australia so no legal weed here but I would happily pay more to be able to buy edibles as well as know exactly what I am buying and what the dosages are.

</comment></comment></comment><comment><USER10> Another reason for users turning to the black market that this article did not mention but that I've heard mentioned elsewhere is that Canada purportedly limits the potency of legal cannabis to relatively low levels, so the black market remains the only source of high potency cannabis.

<comment><USER11> Maybe, but the real issue is that anyone is allowed to grow the stuff. And it is really easy to grow. So everyone knows somebody who is growing. Why pay commercial prices when your neighbor can provide you the same quality at a fraction the cost? It may be a "black" market in the sense that it isn't the regulated market, but those who smoke the stuff see little difference between buying a neighbor's pot and buying carrots. They both come from the same garden.

[https://aglc.ca/cannabis/using-cannabis- responsibly/growing-...](https://aglc.ca/cannabis/using-cannabis- responsibly/growing-storage-and-transportation)

<comment><USER12> Why also explains why rolling back Prohibition in the US was an unmitigated failure, with everybody still drinking their buddies' homebrews and driving all the pro breweries to bankruptcy.

Since that didn't actually happen, and I'm also buying my carrots at the supermarket, we can probably deduce that it's not home-grown supply that's the problem here.

<comment><USER13> Growing a plant in the backyard is several orders of magnitude easier than buying the equipment and taking the time to brew beer.

... but your underlying point is correct. A better analogy is probably basil, which a large percentage of buyers actually just keep their own plant at home.

<comment><USER14> Homebrewer and gardener. Home brewing is easier. Maybe requires a tad more money up front.

<comment><USER15> Cannabis just requires seeds and some ground outside. Sure it won't be the best, but it won't need any equipment or attention this way. Brewing beer requires at least some active effort.

<comment><USER16> Also requires no sense of smell. It stinks for kilometers.

<comment><USER17> Not necessarily. It depends on the type of strain, and the number of plants.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> You could also blame the government inefficiency in QC. The stores are government ran. The one in Montreal on St Catherine has permanent bread lines at any time of the day. Some of the product is sold out first thing in the morning and you need to arrive an hour before opening. It's like Soviet Union of weed.

<comment><USER13> Quebec is always a special case of bureaucracy and government mismanagement.

Remember that all liquor stores in Quebec are government stores too. I suspect they'll start distributing them there - possibly dependent upon neighborhood approval.

I'll note that the neighborhood I'm in - the older folks are not happy about the new constant pot smell around.

<comment><USER18> In ON the liquor is also controlled by LCBO, yet marijuana was given to the private sector. I guess they learned their lesson with liquor control.

<comment><USER19> I wouldn't say so. The original plan was to have the LCBO handle sales of marijuana as well.

The Liberal government that was drafting this plan lost the provincial election and the Conservative government scrapped that it.

So it nobody learned any lessons, we just had interesting timing with our election.

</comment></comment></comment></comment><comment><USER20> The lack of edibles for the initial launch is a big blocker for casual adoption IMO.

As per the visuals, cannabis use has not grown dramatically since legalization. Oils and raw bud are simply not as accessible as a bar of chocolate.

I imagine that won't cause a significant bump either, but at the least, it opens up the market to the casual user -- which simply has not happened yet in Canada.

</comment><comment><USER21> Way too much illegal vs legal supply for legal demand to keep up. Same glut we're having in California, excepting half of that is caused directly by zoning laws and such making it almost impossible to open a legal dispensary despite it being legalized in the state.

<comment><USER22> Speaking as a Canadian (and utterly uninterested in cannabis) - this is closest to accurate. Many jurisdictions are openly hostile Most parts of the country limited access, supply and transportation.

It's hard to make a legal business work when most are still against it functioning.

That said, it ain't dead yet.

</comment></comment><comment><USER23> Since 90s or so I've viewed Canada as quasi legal. Very low enforcement compared to my US experience. It seemed like a larger amount of homegrown and related technologies came out of Canada. Maybe I'm wrong. But if that is true, for consumer there's really no advantage to going retail and lots of disadvantages as mentioned. So the "black market" sounds bad it's really like a local artisan. Not some terrorist funding cartel run thing. Just your friend from down the road that shares his bounty.

<comment><USER24> Very true, the RCMP in my hometown were rarely doing raids/busts or anything of the sort. Unless you we're trying to muck around with hard drugs or driving around in a hotboxed car.

There were multiple parents/working class people with tables/setups in their garage. Come over for a cup of coffee, catch up about the kids, grab a few grams until next week! Nothing nefarious.

On the consumer end the logistics is really the benefit of legal weed. You don't have to know a guy, play a game of telephone, wait around. Instead you can visit a professionally run store filled with people that know about the products and gear that is stocked. Makes it much easier to add into the routine right beside picking up groceries. That being said you pay a premium for that, and there's still black-market services doing Amazon style home delivery.

<comment><USER25> Also, drug crimes in Canada are prosecuted by the feds, not your local prosecutor. And I don't think there's been much federal prosecutorial interest in those cases, even if your local RCMP thinks its a problem.

It likely explains why Toronto had to go the bylaw infraction route to close down shops. Which was still a waste of money...

</comment></comment></comment><comment><USER26> another more hn reason

why would i bother putting my info into a govt database of people consuming products that are illegal in most areas of the world?

my friend recently got banned from the us for having a small amount for personal consumption

would rather get higher quality/better priced product from friends that get shipped to me at my convenience than deal with the headache of legal weed

<comment><USER27> Just for clarification, your friend tried to cross into the US with weed?

</comment></comment><comment><USER28> In downtown Vancouver the government website only lists one "legal" cannabis store yet a quick google search shows +20 listings:

[https://justice.gov.bc.ca/cannabislicensing/map](https://justice.gov.bc.ca/cannabislicensing/map)

I would suspect that many people purchasing on the black market are in fact purchasing from stores (not just "their weed guy") but don't realize the store is not properly licensed.

<comment><USER29> Don't trust that; unlicensed shops have been closing down much faster than google's been keeping up. Source: I'm a customer that preferred the unlicensed shops because the product and pricing was better. I was never ignorant about their legal status.

In licensed shops you get a very limited selection and typically, a low inventory. They've got little sniffer pods where you're supposed to be able to smell the product but it's nothing like the old shops where they'd have a canister where you could really get a good whiff. Packaging requirements mean that there's a limited selection of quantities; and typically, the packaging is at least 3x bigger (and significantly more expensive) than previously.

My preferred purchasing pattern is to buy a single gram of a few unfamiliar strains, test them out, and then come back in a few days to get an ounce of the best one. With this pattern, I only need to go to the store a few times a year. With the new shops, they don't carry single grams, and you can't save on packaging by buying in bulk -- if you want an ounce, you'd have to buy 10 of the 3.5g canisters.

I was pro-legalization for obvious reasons but now I wish I had a good black- market hookup.

</comment></comment><comment><USER30> The only reason cannabis cost $6-8 per gram was the illegality of it all. There were paid shocktroops(The Police) helping the criminals keep the price high. Grown on it's own it waould be a little more expensive than hay, something that is grown from seed in fields acres in size can be waay under $1. Some states have huge gluts. EVen the hybrid seeds where 10,000 seeds come from one large plant, each one female, each one prefertilized (feminized) [https://shop.ilovegrowingmarijuana.com/collections/feminized](https://shop.ilovegrowingmarijuana.com/collections/feminized)

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

So the growers can always beat the legal price because the goverment has encumbered the legal growers with red tape and other restrictions to help the illegal market continue to prosper. Remove the limits = $1 a gram or even less

<comment><USER31> I think you're right about the market constraints, but in terms of a crop it's more labor intensive — more like strawberries or tomatoes than hay. It'd be great to see a shift towards low input natural farming for cannabis, but at present it's very input and labor intensive.

</comment></comment><comment><USER32> I'm under the impression that the market will grow with time. The product happens to be great enough for my standards. The obvious downside is the requirement from a person needing to explore the dosage intake themselves and contrary to how everyone can dive into coffee for a different type of high. I'm skeptical of the price being where it should be because I think it's too high resulting in the profits being worse then what could be achieved. Interestingly all the high THC strains are usually all sold out online in my province's store but I think most people that would enjoy the benefits from the high would prefer a low to medium THC or even CBD strain. Edibles are in my opinion dangerous and I'm curious to see how that will likely make no difference in sales. I think what needs to happen is the ability to micro dose safely without any unpleasantness and be affordable. Vaping can make it affordable but dosing isn't as accurate as I believe it should be.

</comment><comment><USER33> I don't think it burst because of the Canadian market. It burst due to the Canadian LPs building out infrastructure like there was going to be this giant international market in Europe and the US. The Canadians haven't been able to penetrate either market. The US seems to be handling itself and the tiny legal international cannabis export/import market is being targeted by Colombia aggressively. The Canadians only ever had the advantage of first mover and now that legal barrier is collapsing.

What else grows in Canada?

Check out these pics from Colombia: [https://medellinguru.com/colombia- cannabis/](https://medellinguru.com/colombia-cannabis/)

In Colombia, you can grow year round with only tarps up to catch the rain.

</comment><comment><USER34> What I've noticed here in Ontario is that everyone is growing their own instead of buying it. Even my mother's book club is basically 15 minutes of book talk followed by 2 hours of people trading grower's tips.

<comment><USER35> It is insanely easy to do. I even made clones, and gave them to anyone that expressed interest in growing their own.

</comment></comment><comment><USER36> I'm guessing there's a market if it's available and convenient to buy and of good quality and reasonably priced.

</comment><comment><USER37> My dealer pulls up within half an hour of texting them, with a full ounce they grew themselves. They know everything about the plant, and breed it for high THC. No delivery fee. Friendly. Great weed. No packaging. No bullshit. And great deals. Most dealer you buy from you won't be paying $280 ($10/h per O). Why would I _ever_ go the "legal" route?

<comment><USER38> You don't have a guilty conscience for putting people behind bars by your behavior?

<comment><USER39> Shouldn't you be asking the law makers and law enforcers that question?

If you support such laws, shouldn't you ask yourself the same question?

Illegal != immoral, after all.

<comment><USER38> I don't support these laws

</comment></comment></comment></comment><comment><USER40> This story is really a parable for government involvement in anything vs. the free market.

<comment><USER41> How about monopolies?</comment></comment>


Dave Goldberg died from severe head trauma after collapsing on treadmill - <AUTHOR> http://mashable.com/2015/05/04/dave-goldberg-cause-of-death/

<comment><USER2> Previously: [https://news.ycombinator.com/item?id=9487055](https://news.ycombinator.com/item?id=9487055)</comment>


PG on Bloomberg: Don't Look at Groupon's Numbers - <AUTHOR>

I found this sort of strange. He mentioned that Andrew Mason is a smart guy, and by definition, smart guys end up figuring out that a bad idea is eventually bad.
But I don't think investors and money money managers know the leaders of their portfolio companies as well as they know the companies themselves.
Would this generally apply to equities investing as well?
He's on now, live, by the way.
Update:
Re: Hipmunk - No money from flight search. The money's in hotel search.
Exciting trends: online rentals (spaces), smartphone/tablet apps.
Show's over. <comment><USER2> Comment on the title: He didn't say "Don't look at Groupon's numbers". That's what Bloomberg flashed. He said something like "I wouldn't be looking too closely at Groupon's numbers if I were to invest in them. I would look at Andrew Mason instead and he's a smart guy."

<comment><AUTHOR> He actually did say that. Your quote is more of a paraphrase.</comment></comment>


Show HN: Dev.to-Where devs share ideas and help each other grow (Not my creation) - <AUTHOR> https://dev.to/ <comment><USER2> This is just a blog.</comment>


Million dollar gas hack. - <AUTHOR> http://greenwala.com/?p=83 <comment><USER3> I wonder how much fuel could be saved by avoiding unnecessary residential deliveries. How many delivery attempt notices does UPS leave every day?

If shippers provided UPS with an email address for the recipient a notice could be sent by email the day before a package is to be delivered. This notice could provide options to let UPS know to wait a day or two to attempt delivery when someone will be there or redirect the package to a commercial address (e.g. the recipient's place of employment).

I recently had a package delivered that required a signature. After the first attempt I called UPS and had it redirected to my work address. Unfortunately they already had it on the truck so I was told they would attempt delivery to my home address the next day before redirecting it.

<comment><USER4> I was waiting on the front lawn for a UPS delivery to show up while surfing on my laptop one day since it was a nice day. I occasionally took a look at the online tracking page and flipped out when it went from "out for delivery" to a failed delivery notice because the recipient wasn't there. Since I saw no UPS truck driving past my house, and the front door is the only way to make a delivery short of climbing over walls of other houses, you can probably understand why. Called up UPS customer support, asked them to please redeliver the next day because I would be leaving home soon and I didn't want to wait for the delivery, wherever the guy was, so he could save himself some time and effort.

The UPS delivery guy actually came over 4 hours later when I was definitely away from home to put up a delivery attempt notice saying I wasn't there. After I explicitly told two separate customer support folks NOT to deliver the package after I talked to them because I will not be there to pick up - <USER2> those two were separate from the initial call I made. This guy seemed to have an absurd sense of humor, because he marked the one and only notice I received that I didn't want as a second delivery attempt.

Your idea will only make sense if UPS actually did their job. They failed catastrophically for me in that incident. Since I seem to get delivery attempt notices quite often, I wonder just how many times they actually stopped by (unfortunately I usually take the car out when I'm going, and that's a different exit..).

</comment></comment><comment><USER5> Presumably, the most efficient delivery path to take must include left turns... right? I wonder if the efficiency gained by only turning right is greater than the efficiency lost by taking a less efficient route?

<comment><USER6> What makes you think it's less efficient? They are driving all around the city. The system organizes the deliveries into an efficient route that favors right turns.

I'm sure the system is smart enough to not have them go all the way around the block to backtrack. It just has them hit that location before advancing. I would love to see an illustration of the type of route it outputs.

<comment><USER5> > The system organizes the deliveries into an efficient route that favors > right turns.

Yes, I just wonder how much less efficient "the most efficient route with only right turns" is than the true optimal route. Based on my limited experience with optimal TSP problems, I bet they're fairly close.

I'm imagining a route which gives each driver a chunk of several blocks, then has them hit all locations within the chunk with a right-hand spiral inwards... But I'd love to see the actual routes.

<comment><USER7> According to the article, the system doesn't really plot an only-right-turns route, it's more like an 80%-right-turns route. But the fact that the software knows enough to know that left turns are worth avoiding is a pretty good piece of work.

</comment></comment></comment></comment><comment> patrickg-zill I dunno, I did this (right hand turns whenever possible) like 20 years ago in my first job, when I had to drive around Toronto. So I doubt I am the only one who thought of this before ...

<comment><USER8> No doubt, I've been doing it too for a while (although my reasons are safety- based). But not everyone has access to a modeling tool (and the data) to create a business case that convinces a big multinational to make it into corporate policy.

</comment></comment><comment><USER9> Unmentioned but also significant: avoiding left turns means fewer accidents.

<comment><USER4> UPS trucks in particular would be in a position (at least in the United States, where we drive on the right side of the road) to make less lane changes since stopping for a delivery usually means stopping on the right side of the road. Possibly safer as a result of that as well.

</comment></comment><comment><USER10> >You see it seems that some analyst at UPS got some modeling software and came up with this plan.

This was a little beyond "some analyst"... even if it was originally the idea of one person, the actual plan took many, many people to implement. Solving real versions of the traveling salesman problem takes a lot of manpower. UPS hires more Industrial Engineers than anyone else.

</comment><comment><USER11> I'm curious how they optimized for this. Perhaps some sort of linear programming or variation of the "traveling salesman" problem?

<comment><USER10> <http://en.wikipedia.org/wiki/Operations_research>

This is one of the things that Industrial Engineers actually do. In my opinion the pay is much too low for how hard the math is. Lots of linear/dynamic programming + statistics and all sorts of fun algorithms.

<comment><USER11> I know, I have a degree in it. :)

</comment></comment></comment><comment><USER12> without putting too much thought into it. i would assume that the most common route looks like a inward decaying clockwise spiral.</comment>