Programming is not a craft - <AUTHOR> http://dannorth.net/2011/01/11/programming-is-not-a-craft/ <comment><USER2> Meta note to authors: if your essay has a big TL;DR at the top of it, I'm going to read that, and then maybe read the rest. Probably not.

If you can really boil down all of that text into 2 sentences, _then delete the rest of the text_. The entire purpose of essays like this is to take a position that I might not agree with, slowly introduce it to me, then convincingly make the case that I should change my mind. Sticking a big TL;DR at the top just invites me to take issue with your conclusions, and convincing me of your conclusions are the entire purpose of your essay. So folks who agree (and agree a lot) will read your essay all the while muttering to themselves about how right you are. Those that disagree will just blow it off, thereby defeating the entire purpose of writing it.

The "art versus craft" discussion has potential, so I was intrigued enough to skim. I just didn't feel the article was well-formed and engaging enough, however, so I can't recommend it. Sorry.

<comment><USER3> I don't think that's fair. In the academic world we call it an "Abstract." In the bureaucratic world I've seen it called an "Executive Summary." Putting your conclusions first is also called a thesis statement: this is what I intend to demonstrate. I actual prefer it when authors just say that up front, and aren't coy about their conclusions. Some authors can pull off being coy about their conclusions, but it takes a level of craft (ha!) that most aren't able to muster.

<comment><USER4> Academic papers have abstracts because a very large percentage of their readership won't read the main article.

(For one thing, the abstract has traditionally been free to read and is indexed by library tools like PubMed, while the whole paper has traditionally cost a small fortune and/or required a subscription and/or required a trip to the library stacks and a very tedious photocopying session. What scholars used to do _before_ the photocopier I have no idea. Maybe they had that tidy handwriting because they got a lot of practice.)

(Even in the modern era, abstracts can be useful because scientific papers have a required format that makes them bulky and hard to skim. But, a hint: It's often better to skim the first few paragraphs and the last few paragraphs of a scientific paper than to read the abstract. The first section contains the references to prior work, which help you put the paper in context and give you hints about where to look next; the ending has the more-detailed version of the conclusions, with fun bonus features like attempts to pre-empt the obvious criticisms, speculation about what the work might _really_ mean, previews of coming attractions, and sometimes even hints about where the bodies are buried.)

Meanwhile, bureaucratic memos have Executive Summaries because they serve at least two audiences. If you delete the executive summary nobody with any political power will read your memo -- executives read only one sentence at a time -- and your proposal will die alone. If you delete the body you will lose all of the ass-covering detailed analysis that you carefully larded it up with, and six months later someone will accuse you of not thinking your crazy idea through.

But essays don't have abstracts. It's like telling a story by first spoiling the ending, or telling a joke by leading with the punchline. If the story promises to be so boring in the telling that it's not worth following along, don't tell the whole story.

<comment><USER3> I see no problem with it if the essay's primary purpose is to relay an argument for an idea as opposed to entertain the reader (and author). It's basically a thesis statement.

</comment></comment></comment></comment><comment><USER5> Mixing up and cherry picking the concept of an art and a craft made this a pretty annoying read for me.

> Non-programmers don't care about the aesthetics of software in the same way > non-plumbers don't care about the aesthetics of plumbing

I personally care about the 'aesthetics of plumbing' if I'm able to see them (which I might not be able to).

When we're talking about aesthetics, it means to me that I value the thing because it's a clever solution to a problem. A solution that requires the minimum amount of effort/energy/material and delivers the expected result. I don't really care if somebody designed a lock, a valve , a differential gear, a sorting algorithm or an API.

We can also talk about aesthetics in music or paintings, but those will be subject to the person looking at them and the society that person lives in. Some people think skyscrapers are aesthetic, some people dislike them. While aesthetics in art tend to be more subjective, the engineering solutions are more objective in that regard.

<comment><USER6> > A solution that requires the minimum amount of effort/energy/material and > delivers the expected result

As good a definition of code beauty as I've ever seen... even if not as popular.

<comment><USER7> Why are comments like getonit's getting downvoted on Hacker News now? I'm obviously assuming it's dwnvoted because it is appearing in a much 'lighter' font. But has something I don't understand changed about downvoting? Every article has several constructive comments at the bottom, seemingly downvoted for absolutely no reason. It's really ruining the comment threads.

<comment><USER6> Because the Emperor is _not_ naked, dammit, and people like me shouldn't be encouraged to spread rumors that he is :)

Fear not though - as someone with an entire menagerie of unpopular opinions about programming, business and life in general, karma as a measure of agreement with the opinion is more useful to me than as a measure of people's opinion on the constructiveness of the comment. It's also feeding a spectacular persecution complex, which comes in handy when I discover I've been talking rubbish on a subject :)

</comment></comment></comment></comment><comment><USER8> > Non-programmers don't care about the aesthetics of software

So what? All software isn't built for non-programmer end users. Enormous amounts of software is built for other programmers to extend or use.

In software _libraries_ , for example, aesthetics and craftsmanship are vital. To follow the plumbing metaphor, a _plumber_ cares deeply about the craftsmanship of the pipes and pressure regulators.

<comment><USER9> But once we engage in writing software purely targeted at other programmers, we're in the tool business and I think any plumber will agree that there can only be so many companies producing monkeywrenches. And no customer cares if your monkeywrench is the latest version or 5 years old, or even if it works. They care about getting their water running, their toilet flushing or their washing machine washing.

<comment><USER10> "...no customer cares if your monkeywrench is the latest version or 5 years old, or even if it works."

...aaaand, if you have a crappy monkey wrench, you won't get the pipes tight enough and something will leak. I don't want to see my plumber tightening pipes with his hands because even I know that it's not going to work well.

The customer just wants a working piece of software, yes. But great tools - OS, editor, language, development framework, design patterns, UI principles, etc - help you to fulfill that requirement. The user doesn't know about them, but indirectly, they do care.

Example: our company had an internal app written in 100% custom PHP. It had taken a year to create. The developer left and a new one took over. He rewrote the whole thing in Rails in a week and quickly started making big improvements.

(Yes, a lot of the time difference was due to work ethic and talent of the new programmer, but still, the tools were a factor.)

Did the customer - his boss - care about the tool set? Heck yes, he did! Getting drastic productivity gains and many more iterations of development convinced him to care. He's now on board with Rails development and willing to send developers to RailsConf. He has seen that because results matter, tools matter.

</comment></comment></comment><comment><USER11> This was painful for me to read. It's an important topic, but the author's argument isn't even false.

The Software Craftsmanship movement does make assertions about the aesthetics of software, but more importantly it links the cleanliness of the design with the quality (read: capabilities) of the software. By saying your client doesn't care about the aesthetics of your software, they only care that it works, and therefore software is not a craft you're committing the fallacy of denying the premise because you're asserting those two things are disjoint and independent. The idea of "software as a craft" assumes the two are inextricably linked.

I'd like to add that people who have seriously thought about our field would know how futile it is to make analogies to different discipline. Software is sort of a meta-engineering discipline, where we try to come up with processes and practices that we could use to produce applications that have completely different domains. I think this makes Computer Science intrinsically self- referential and therefore intrinsically different from any other engineering practice or craft. By using analogies you're demonstrating that you don't know or accept this, which ought to automatically disqualify you from the discussion.

I know I stated a lot of the above more pompously and strongly than warranted. It's hopefully a better read this way and more of a conversation starter than a reflection of my character.

</comment><comment><USER12> Consider whether there is a trade-off between software that delivers value, is aesthetically pleasing to the craftsman, and its cost in time and/or money. You know, "Value, craft, cost, pick two."

If this tradeoff constrains the development of software, then this essay is important because it implies that to deliver software with value, it is more expensive to do so with craftsmanship. If this tradeoff does not constrain the development of software, the entire essay is irrelevant because you can deliver value at good cost while maintaining any standard of craftsmanship you like.

This much is obvious. What is not obvious from the article is that the author has convincingly defined what craftsmanship is and shown that the tradeoff is in effect. Instead, I read cherry-picked examples that beg their own conclusion. Any number of people can play that game if you don't provide a good definition of craftsmanship that is independent of the tradeoff and the value.

For example, if I define "craftsmanship" as reformatting software that already delivers value to be more readable, we have a definition that is not independent of the tradeoff, because readability for future programmers is a component of value. This reframes the discussion from craftsmanship vs. value into how much value is sufficient. That argument has nothing to do with craftsmanship, you can talk about whether software should work for all browsers or just IE, or how fast it is, it's a product management problem, not a question about the nature of programming. Engineers have the exact same argument about how strong a bridge ought to be.

Or maybe I define "craftsmanship" as spending extra time making value-less changes to code. Again I've dragged value into my definition, and cost as well. This argument now becomes a True Scotsman fallacy. If I say that I'm a Java programmer and that I use patterns as part of my craft, I can also claim that they save me time, so you say this isn't part of my craft because it saves me time. You mean the over-engineering patterns, just the ones that are in there for the sake of having patterns. WTF, we can't argue on that basis, the goalposts keep moving.

</comment><comment><USER13> Due to the sheer volume of responses to this article the author posted a rebuttal to many complaints here:

On craftsmanship <http://dannorth.net/2011/01/15/on-craftsmanship/>

His rebuttal is, as the author admits, better edited and more pithy. Some key parts are:

"If I gave the impression that I wanted the cheapest or quickest cobbled- together solution then I certainly didn't mean to. I want the best value software, something that's fit for purpose in this specific context, to solve this specific need."

...

"I used the metaphor of negative space to illustrate that the point of programming isn't the software - it's the information flow or utility that the software enables. Programming is not fine art."

...

"People want software because they want to solve a problem, not because they like the notion of software. Some software practitioners risk losing sight of that. That's all."

...

"Some people self-identify as 'rock stars' or 'software' 'craftsmen' in an unfortunate attempt to differentiate themselves from regular jobbing professionals, whom they regard as less talented or valuable than themselves. I don't have much time for these people."

</comment><comment><USER14> I work on legacy applcations.

Big, horrible, poorly designed applications. Applications with their own custom string libraries and XML serializers. With bad plumbing and an eye for "making it work."

12 years later and they have to call me in to help them out. It crashes sporadically. It has memory leaks. It's useable but users want new features and programmers can't add them. There's no documentation anywhere. Most of the code is practically unreadable.

A craftsperson is one who practices a trade or skill. The _art_ of craftsmanship (craftpersonship?) is the method and rigor one employs in their studies. To be a craftsperson with good craftsmanship, one must continually practice their skill and endeavour to become better at it.

If you're not a craftsperson and your philosophy of work is to simply "get 'er done," then you don't care about the quality of the work or your skill as a person performing the work. This kind of person will produce the kind of software I described above. True, the users of this software have been using it for years without caring or even knowing what programming language it's written in -- but they do notice the memory leaks when the application sporadically crashes. They do get frustrated with convoluted "features" that are really work arounds to flaws in the initial design of the program.

The quality of your output as a programmer _matters_. In the case of producing software, the ends do not justify the means. If you write bad code that works, you have only sold your customer short. In my opinion, they pay you for your skill and trust that you will use the best tools available and write software with a high degree of quality.

To use your analogy, people trust the plumber to provide the quality and skill to do the job and do it _properly_. Not to hack together the first thing that works.

</comment><comment><USER15> Even a non-plumber can appreciate craft. Here is what a bad plumber does (and tried to charge for it). This is a perfect analogy to a terrible piece of software:

<http://i.imgur.com/BIBOS.jpg>

<comment><USER6> Context - In a 5 star hotel, that would be appalling. In a house you've just bought, that would be crap, but at least it works until you get to the part of the list where you remedy it. In a toolshed/garage/stable/whatever, that would be prioritising effort - a good thing.

</comment></comment><comment><USER16> I don't see much point in the argument over whether or not programming is (or is not) a craft. In my book, you can imagine yourself as whatever you want as long as it gets the job done-- "engineer", "artist", "craftsman", "fry-cook", "architect", whatever works, whatever you what call it.

If anything, programming today is beset with workers who just don't care about what they're doing. Perhaps a little bit of the care and attention that a "craftsman" ethos brings would be a good thing. It certainly doesn't hurt.

<comment><USER17> I do not recall seeing any field besides programming that tries so hard to make analogies of itself to other fields.

It's an art! It's a science! It's engineering! It's craftsmanship! It's architecture! It's culinary arts where FOR loops are part of an NP-complete breakfast!

Not to say that such analogies aren't fair or sensible, but I feel like we try much too hard to defend what we do by putting in terms that other people (or maybe even we ourselves) can understand. I reckon part of this stems from the fact that we aren't even agreed on what to call ourselves: I'm a software engineer! I'm a computer scientist! I'm a programmer! I'm a developer! I'm a chef of the digital cuisine!...

But then, maybe it's not even a bad thing. The fact that we have such mixed feelings about what we do is all about suggests that people with different backgrounds can come to our field, bringing their own perspectives to the table. People who are well-versed in art can come to the field and develop software from the perspective of an artist. People who understand engineering concepts can develop software from the perspective of an engineer.

Perhaps there's a spectrum of different styles of software projects, each of which can make use of different perspectives and different styles of development. I've worked on avionics software; this is not very creative development, but it's very strict, and, in my opinion, perhaps some of the most true software "engineering". I've worked on web applications, where you can push out a quick version 1 and then iterate even while the user is using it. A totally different development style. I've worked on mobile applications where I can't just push a new version, but it's also nowhere near as serious as avionics; this might fall somewhere in between avionics development and web development.

Maybe we need software engineers. And maybe we need programmers. And maybe we need computer scientists. And maybe we need software architects. And maybe we need software artists. And maybe these all describe someone who builds software, but with a different style and approach.

Or maybe it's time for breakfast; I wish I had a box of FOR loops.

</comment></comment><comment><USER18> Ugh, I don't have the time/focus to wade through all of this. With that qualification, a few comments:

# Crafts-men (-persons) used to be a mainstay of useful products. There was an aesthetic, but they were also successful because they made the best that was available in a locality.

# A significant portion of "craft" is creation and maintenance of tools. Good craftsmen spent considerable effort acquiring and maintaining the best tools for the job. And many were rather inventive in coming up with their own tools an processes. Some caught on and spread; some never escaped their locality and isolation. Many were replicated independently and frequently.

How much of this sounds like today's software industry? A lot, to me.

Programming is a craft. Anyone who's had a brush with e.g. UML, automated systems, etc., knows it's not a hard science (the underlying mathematics is, but we're talking about "programming", here).

I'd say that craft begets artisans beget art. It's a continuum, not an either/or (XOR, as it were).

P.S. Artists would be lost -- at least, to perpetuity -- without the "craft" of their profession. How to make and choose materials that provide for expression and for durability, for example. Canvases, pigments, binders, instruments, notation, sociological/anthropological (whether formal or otherwise) studies (folk songs, dances, etc.).

</comment><comment><USER19> Everyone programs differently. Every artist paints differently, plays differently or sculpts differently.

Programming is an art. Instead of brushes we have ADTs, instead of paint have the UI. If we use the right strokes in the right places, we end up with a master piece.

If we slap it together to make a deadline, people can tell that. Sloppy UIs with stupid data structure decisions really do make a difference.

<comment><USER20> Let me broaden your argument: because everyone does everything a different than everyone else with different tools - such as artists do - everyone is an artist.

No, programming is not an art. Painting is also not an art per se, etc. Don't devalue art by attaching the label to every creative task you do.

</comment></comment><comment><USER21> Personally, the most important take away point from the software craftsmanship movement [well, as I see it] is that it gets programmers to feel good about themselves, take pride in their work, and keep on improving. I am sure for many who burn nights, calories and eyepower against never-ending deluge of deadlines from incompetent managers, this is good.

Now, expending real energy, effort and time agonizing over whether it is a profession, a trade or a craft? Is arguing over semantics really important? Instead of doing that, I say why not spend that energy helping out your team mates struggling with a particularly hard to trace bug or doing more data analysis for the next round of features?

</comment><comment><USER22> Open source and extendable software makes this argument redundant, surely?

We write good code (as opposed to quick code) in order to make it re-readable and updatable later; making the logic machines more dynamic and, ultimately, functional to end users?

Equally rock star, ultra-pretty code like rails (or even ruby itself) which writes 9/10 of the program for you is also a massive win for customers who get the benefit of cheaper logic machines (because people only have to write the unique/problem-domain components.)

also, I agree with DanielBMarkham, putting a TLDR at the top means I don't read the whole post (which was definitely TL...)

</comment><comment><USER23> I know how to do something people will pay me money for. I can wander from urban center to urban center around the world (today literally or via the internet), and people will still pay me money to use my knowledge to build stuff, much like medieval stone masons (who didn't just cut and lay stones to build beautiful cathedrals, but utilitarian structures too). Meets my definition of a craft.

</comment><comment><USER24> I really liked this blog response: [http://thinkingbox.wordpress.com/2011/01/12/craftsmanship- is...](http://thinkingbox.wordpress.com/2011/01/12/craftsmanship-is-not-art- and-we-care-like-craftsmen-do/)

How long before the Software Carpentry Manifesto?

Bonus link if you want a laugh: <http://www.artisanalpencilsharpening.com/>

</comment><comment><USER9> It's a shame the author never touches on the subject of maintainable code vs. spaghetti code. Some part of the craftsmanship is to create code which can be built upon in 6 months by someone else, because you've left for another job. I'll admit that this is becoming a smaller and smaller part of the definition.

</comment><comment><USER25> Since we're dealing with metaphors, we're free to invent whatever we want - the metaphor should be judged on it's usefulness to ourselves and our fellow programmers.

Which of the following would you rather be? Which would you rather work with?

\- ninja \- craftsperson \- rock star \- artist \- resource

Pick your poison. Craftsperson works for me.

</comment><comment><USER26> What's the big deal? Why can't it be a trade _and_ a craft?

Problem is, if you don't have the craft, then you're not gonna get the end result. Just don't shove the craft down the customer's throat. That stuff is for colleagues. The customer wants to hear a different but not necessarily competing message.

</comment><comment><USER27> _"There's a really cool word for this phenomenon - when you only become fully aware of something when it fails - but I can't recall it right now."_

The better a design, the less you notice it.

At least, that's what sprung to mind for me.

</comment><comment><USER28> People often do care about aesthetics of the things they buy, from stone work to plumbing to woodworking

<comment><USER29> "People often do" usually means "some people do", which implies "some people don't".

If it's a biz, you want to look at the size of each group and what their members are willing to pay to "get it their way".

If you're doing something to satisfy your itch, you're a customer. How much are you paying to get your way?

</comment></comment><comment><USER30> Here's my take:

Art starts where (prior) science/utility/craft/trade stops giving you answers.

Take an abstract painting. The only functional requirements are that it covers a canvas which you can hang on a wall, and that it will interest viewers. Beyond those things there are really no 'answers' or 'directions,' so the 'artistic territory' begins immediately. If you've ever tried to make an abstract painting, you'll know that even when you don't know what the hell you're painting, you still know there are bits you like and bits you don't. The art is in exploring this uncharted territory to create a whole work that somehow pleases, albeit due to little understood principles ('why is this splotch of green more appealing than that blob of red?').

Take another piece of visual art, say a portrait - it's supposed to capture the likeness of the person, as well as fit on a canvas etc., so there's a bit further to travel before you're in pure artistic territory. If it's a piece of graphic design, an architectural sketch, _most_ of the journey is just applying techniques to capture the functional requirements.

In a discipline like maths or engineering, most people, most of the time, are working well within the established techniques, to solve problems that have been solved countless times before. You need to go a long way to reach the cutting edge, where mathematics can become an art.[1]

Programming, however, sits somewhere in between. While it's nothing like abstract art, as we _do_ have vast sums of established knowledge, plus best practices, standard techniques, etc., I'd wager that most programming projects have a very large quotient of 'the unknown' (as evidenced by the failure and lateness rate of IT projects). Therefore programming is in large part an art - there are often no well trodden routes to success, but the great programmers always seem to get there. They tame the unknown, but not in a way that can easily be transmitted to other workers/programmers.

When you see a piece of embroidery, it's artistic in the sense that we don't know exactly why it is appealing, but the person who 'crafted' it was probably not exercising any great artistic expression, just repeating an old design. Just because something's functional requirement is to be aesthtically pleasing, doesn't mean it's a 'craft' which is intrinsically different from disciplines which lack that particular functional requirement. We need to rethink what we mean by art and non-art. In paintings or music, the jump-off point is almost immediate: you have few functional requirements, and few relatively rules to guarantee results. From there onwards it's down to insight/ability on a fleeting, individual basis. With other disciplines, you have many functional requirements and many rules/procedures that let you meet those requirements if followed diligently. Sometimes aesthetic appeal is one of the requirements, sometimes not. But there comes a point once again where only individual insight/ability can bring further progress. Our only choice is to rely on talented people.

Have you ever seen the film, 'A River Runs Through It?' It's about two estranged brothers who are reunited in adulthood, and they think back to years before when their father would take them fishing. Their father said the most important thing for a man to have was 'art.' He didn't mean owning pictures, or painting them, he meant whatever vocatoin/profession/trade you choose, you need to make an 'art' of it. The narrator/protagonist's brother (played by Brad Pitt) was a failed person in some respects, but he had developed an incredible technique/knack for fishing that nobody else understood. Thus, he 'had art.'

So anyway, programming does not usually involve aesthetic appeal as a functional requirement, but it is sometimes an 'art.' I would conclude therefore that we need to listen to the advice of our greatest artists... but you can never replace the art with a formula.

[1] of course, we very often operate on the edge of our _own_ abilities, but until we've reached a frontier where no one else has gone, our 'art' wont deserve any audience

</comment><comment><USER31> > _Non-programmers don't care about the aesthetics of software in the same way > non-plumbers don't care about the aesthetics of plumbing_

At least you can witness how non-programmers put up with the most absurd and downright horrible software shenanigans on a daily basis as long as the thing somehow helps them, or rather does not completely hinder them, in getting something done. And it is remarkable how quick some of them can pick up on it and how high their levels of tolerance really are.

If anything, this really shows and explains why so many absolutely abysmal "solutions" and "quick hacks" can very well keep on running forever, so to speak, until the day it comes to a screeching halt and some poor, completely unsuspecting fella is called in to "have a quick look at it".

</comment><comment><USER6> I think of this as avoiding 'premature polishing', much as I try to avoid premature optimisation. The evils are of a comparable nature, IMHO, even though I don't seem to be in the majority on that one.

'Clean lines' is my mantra. Whether it be done through a remote API, a database queue or a multitude of classes, loose coupling and sensible, strict and adaptable communication between clearly separated units is my number one priority. Everything else has, at the very least, the danger of encouraging the traces of the architecture astronaut within me... and he's enemies number one, two and three :)

The units themselves can be as good or as thrown-together as circumstances demand, but the separation/communication being of a professional standard is set in stone.</comment>


Free America Again (Elon Musk) - <AUTHOR> https://twitter.com/elonmusk/status/1255380013488189440 <comment><USER2> Guess what? A factory owner and a doctor disagree on how bad things are.

Elons track record speaks for itself:

[https://mobile.twitter.com/elonmusk/status/12407546572631449...](https://mobile.twitter.com/elonmusk/status/1240754657263144960)

Edit: one more

[https://mobile.twitter.com/elonmusk/status/12407534300013568...](https://mobile.twitter.com/elonmusk/status/1240753430001356801)

</comment><comment><USER3> I just read some of the replies. What a cesspit Twitter is when it comes to politics.

</comment><comment><USER4> I thought Musk had finished with his coronavirus rants:

[https://jalopnik.com/elon-musk-has-played-an-extremely- dange...](https://jalopnik.com/elon-musk-has-played-an-extremely-dangerous- game-1842416407)

But apparently not. I really don't see how his tweets will contribute to achieving better outcomes for anyone.

</comment><comment><USER5> I agree. Everyone is getting destroyed economically and the government is just bailing out wall street. This shut down is just insane and needs to come to an end. The cam just make masks mandatory!</comment>


AMD Responds to WSJ 'Keys to the Kingdom' Story - <AUTHOR> https://www.amd.com/en/corporate/wsj-response <comment><USER2> Earlier HN thread on the WSJ article: [https://news.ycombinator.com/item?id=20300100](https://news.ycombinator.com/item?id=20300100)

</comment><comment><USER3> Hypothetical question: Let's say a news source writes a story that tanks a company's stock price and then, over the course of time the company is able to prove the story is false and/or the news source is unable to back up the story. Can the company sue the newspaper for damages?

<comment><USER4> Oh, like Bloomberg's _The Big Hack_?

<comment><USER5> First thing that came to mind. As far as I know they're still claiming it was accurate.

<comment><USER6> And it certainly hasn't been proven false

<comment> lame-robot-hoax I mean they're the ones making the claim, the onus probandi lies with them.

</comment></comment></comment></comment></comment><comment><USER7> >The Wall Street Journal story omits important factual details, including the fact that AMD put significant protections in place to protect its intellectual property (IP) and prevent valuable IP from being misused or reverse engineered to develop future generations of processors.

Without knowing what those protections are, I'm not sure we have learned much.

Also the US government not objecting, I'm not sure changes the gist of the story does it?

<comment><USER8> Eh, the lean of the article and the comments on the original HN thread were knocking AMD for it as if they were going against American interests by being successfully bullied by China into giving up valuable IP.

AMD is saying that a) the IP was not of the highest value or performance, and b) it's unlikely to go against American national security interests when DoC and DoJ both give explicit sign-off. Remember too that this was in the Obama era, when the likelihood of sailing the country down a river for $$$ was lower.

<comment><USER9> I think you've got it backward. The likelihood is that the Obama administration treated China more like an ally and less as a hostile power than Trump has treated them.

<comment><USER10> Obama spent a lot of political and reputational capital on the TPP. The only purpose of TPP was to counteract China. I think it would be very surprising if they were treating China as an ally.

</comment></comment></comment></comment><comment><USER11> Intel did (probably forced by recent at the time $1B Qualcomm penalty in China) the very same thing with Atom IP, twice!

[https://www.anandtech.com/show/8061/this-is-huge-intel- enter...](https://www.anandtech.com/show/8061/this-is-huge-intel-enters- strategic-agreement-with-chinese-soc-maker-rockchip)

[http://linuxgizmos.com/intel-invests-1-5-billion-in- chinese-...](http://linuxgizmos.com/intel-invests-1-5-billion-in-chinese-chip- designers/)

Not only Intel gave away its CPU IP, it also "invested" $1.5B in Tsinghua Unigroup. Whats more last year they shared 5G modem IP with Unisoc, part of Tsinghua Unigroup holding.

</comment><comment><USER12> My understanding of the structure of the arrangement when I first heard about it was that it was designed to _not_ transfer IP, but to allow China to make their own chip, in a manner of speaking, without actually having the important IP. Even ignoring national obligations, it would just be bad business to hand that over.

"AMD put significant protections in place to protect its intellectual property (IP) and prevent valuable IP from being misused or reverse engineered to develop future generations of processors."

That being said, I wouldn't be surprised if they got the IP anyway, just that wasn't the intention. AMD CEO Lisa Su made some comments a few weeks ago that the joint venture was already dead in the water and was just for one project only. I get the feeling AMD wasn't too happy about the way it all turned out.

</comment><comment><USER13> Transferring lower speed tech still could be a huge jump from what China had, the main point is architecture is hard to put a value to it. For what is known, maybe slower means lowering the hertz

<comment><USER14> > "could be a huge jump" ... "maybe slower means lowering the hertz"

This is so painfully obvious it's sad that it has to be said out loud. There is no credible information about exactly what AMD means when they claim lower performance. Nothing meaningful is said about the nature of their 'protections.' And the fact that everything was supposedly blessed by all the various US government TLAs under the Obama administration is almost a confirmation of the WSJ lede; that this was yet another backdoor sellout of US tech to China.

<comment><USER15> >that this was yet another backdoor sellout of US tech to China

what does this mean? It does not seem to be something secret or illegal.

</comment></comment></comment><comment><USER16> I'm sure the timing of this exposé (of a years-old story) has nothing to do with AMD's imminent release of a product that will seriously threaten if not outright beat Intel for years to come.

FUD

<comment><USER7> There's got to be a law or something where for a given thread there is some user who has a conspiracy theory about it.

<comment><USER16> Conspiracies, eh

[https://www.agner.org/optimize/blog/read.php?i=49#49](https://www.agner.org/optimize/blog/read.php?i=49#49)

[https://en.wikipedia.org/wiki/Advanced_Micro_Devices,_Inc._v...](https://en.wikipedia.org/wiki/Advanced_Micro_Devices,_Inc._v._Intel_Corp).

Full disclosure, I'm long $AMD ;)

<comment><USER7> Unless I'm misunderstanding aren't you just proving the point / following the usual example of proof people give of a conspiracy?

Every conspiracy claim has some related story people point to and draw a line from.

The claim is that the article was FUD.

The fact that companies who are competitors can compete fiercely doesn't prove anything.

<comment><USER16> Sure, saying there are ulterior motives to this story is a conspiracy theory. Without, say, video evidence of the author getting handed a bag of money by Bob Swan you're free to dismissively label it as such.

Without more information we're left with:

\- Everything in the WSJ article was known years ago.

\- AMD is a week away from likely taking the x86 performance crown from Intel in nearly every metric.

\- The last time this happened, Intel engaged in outright illegal non- competitive behavior to preserve market share.

>It's like what Lenin said... you look for the person who will benefit, and, uh, uh... You know what I'm trying to say...

<comment><USER7> Couldn't you also argue that any bad news about say a politician that comes out would be a conspiracy too as that would be a benefit to someone...?

</comment></comment></comment></comment></comment></comment><comment><USER17> This was my impression from the beginning, but I'm glad to hear it directly from AMD.

</comment><comment><USER18> AMD "laundered" IP through Chinese partnerships. The fact that the legal goalposts have moved since their partnership began does not absolve them of this fact. If China suddenly becomes massively more capable in X86 CPU's, it will be obvious why</comment>


My University Treated Me Like a Criminal Over a Joke - <AUTHOR> https://www.jamesgmartin.center/2017/07/johns-hopkins-university-professor-treated-like-criminal/ <comment><AUTHOR> > "the imposition of "vindictive protectiveness" encourages students to think > pathologically."</comment>


Nothing to be frightened of : The frightfulness of Death - <AUTHOR> http://www.weeklystandard.com/Content/Public/Articles/000%5C000%5C015%5C891pkjol.asp?pg=1 <comment><AUTHOR> I still don't get it. If the author is scared of possible problems accompanying death, he just needs to make sure he has a ready supply of tranqs. What is it that scares people, rationally, about death? I think the irrational fears can be countered in various ways.</comment>


Paradise lost: SatNav "destroys" local knowledge - <AUTHOR> http://news.bbc.co.uk/1/hi/magazine/8133890.stm

<comment><AUTHOR> I submit this for a few reasons.

The first is that when I use SatNav I arrive at my destination having no real idea where I am. I remember in a science fiction book reading a statement like "We claim to have explored space, but in truth, we have explored the small bubbles that surround individual planets. Of the great depths of true space we have no knowledge." I feel a little like that now when driving longer distances with the SatNav.

Secondly, it's interesting how often the SatNav produces "obviously" sub- optimal routes. The Travelling Salesman Problem is well-known to be NP- Complete, so it's not surprising, but some of the foibles are incomprehensible. It's no wonder some people distrust them, and quite surprising that others seem to have complete faith in them.

Finally, stop for a moment to consider the miracle that is the modern SatNav. Despite its short-comings it contains a device to tell you where you are to within a fathom, maps that know where you are and where you're going, enough power to compute a sensible (if not always optimal!) route between the two, a suer interface that non-technical people can usually drive, and all for the cost of a few hours work.

Addendum: GPS works by computing varied flight times of radio pulses. Light travels about a foot per nano-second, so a GPS receiver has to work with time differences less than a typical clock cycle (for the on-board computer). If you have a 1GHz computer, light cannot travel across the motherboard in a single clock-cycle.

Stunning.

PS: Yes, I do know the details, and I know the inaccuracies in the above.

<comment><USER2> What does the Traveling Salesman Problem have to do with typical GPS navigation? Typical use of a GPS device involves a start and an end point, and every once in a while a couple points in between, that ideally you may want in optimal order (though I doubt typical devices can do that for you). But there's nothing intractable about the scale of that.

<comment><AUTHOR> Sorry, you're right. My recent work has involved pathological cases of dynamic spanning trees, and I've recently proved that a sub-class is NPC, and I mis- spoke myself here. The SatNav problem is obviously easier. Given the power of the processor, limited memory, and complexity of streets (in the places I typically deal with) I still find it surprising.

But you're right. Dijkstra's algorithm clearly solves this problem simply enough in _O((|E|+|V|) log |V|)_ for the sparse case.

Apologies.

</comment></comment></comment><comment><USER3> I think this is an interface design problem, not something intrinsic to GPS navigation.

Provided that I set the unit to show my position on an always-north-facing map, I arrive at my destination knowing _exactly_ where I am. If, by contrast, I leave it in its default mode of rotating the map around an always-up- pointing car, then I get completely confused.

I also never use the spoken directions, precisely because I want to know where I'm to go, not when to perform atomic actions like turning; and the map shows me where to go. If I need to get on I-93 N, and the map shows me as being near I-93 N, then I'm smart enough to follow the signs and to reckon when to be in which lane, which are more likely to be correct than the map in the GPS unit.

A constantly changing, map-like rendering of what I see out the windshield accompanied by context-free commands is not helpful. A map that magically shows me my current position and direction is.

</comment><comment><USER4> Pffft... GPS. All you need for navigation is a South-Pointing Chariot: <http://odts.de/southptr/>

</comment><comment><USER5> I can't really complain about them. I used one this weekend and it saved me from having to buy a very expensive train ticket. In normal instances the shortest route between 2 points is a straight line. Which would have taken me through a very busy downtown. The Satnav had me drive 5 minutes out of my way to find an artery and saved me 30 minutes. I arrived at the station with 10 minutes left.

If I had chosen the logical route I might still be waiting for the next train.

Also, if you are in unfamiliar territory local knowledge is useless. And if you are local then the navigation is barely useful.

</comment><comment><USER6> _The technology for sat-nav, in other words, was around for several years before it was developed. All these different inventions simply needed to be brought together._

The computer revolution hasn't happened yet. It's still in progress. In any tech revolution, culture lags tech. Galois fields were around for well over a century before we figured out the practical use for them. The electric arc was discovered in 1802, and we still might find additional uses for it. (Relatively low-tech high-impulse+thrust drives using electric arcs to superheat hydrogen.)</comment>


The "Google banned our entire company" story was likely a fake - <AUTHOR> In the interests of correcting potentially misleading news, a couple of responses from Googlers on HN https://news.ycombinator.com/item?id=17120223 and Reddit (same content as on HN: https://www.reddit.com/r/google/comments/8l231x/google_banned_an_entire_company_gsuite_accounts/dzcw5vg/) suggest the original post was fake (as some had guessed). <comment><USER2> Regardless, having lost access to my first Google account, it's still a good cautionary tale.

In my case, for whatever reason, Google stopped believing that I was the owner of the account, even though I knew my password and secret questions, and was coming from the same IP I had been for years. In addition, a friend inside the company who personally vouched for me was still unable to fix the problem.

Google is a point of failure. Be sure you're prepared for the day your account disappears.</comment>


Show HN: Delivery route planner on stereoids - <AUTHOR> https://deliveryplannerapp.com <comment><AUTHOR> This is my first "successfull" side project I have been working on and off on these last couple months. I would appreciate any feedback on UX experience. I am myself not too good on this regard and these last days I have been improving usability. For instance I have removed mandatory credit card on sign up and made it only neccessary after the trial has expired. I also tried to improve the copywriting of the app so it's more action oriented.

The stack is Java 1.8 + Spring Boot + JavaServerFaces. It's not a modern stack but pretty solid. I have deployed it on AWS Elastic BeansTalk and the database is hosted in AWS RDS (latest PostgreSQL).

EDITed: typo</comment>


If we're living in a simulation, this UK startup probably built it - <AUTHOR> http://www.wired.co.uk/article/improbable-quest-to-build-the-matrix <comment><USER2> [https://news.ycombinator.com/item?id=14319922](https://news.ycombinator.com/item?id=14319922)

</comment><comment><USER3> The title is very clickbaity and should be changed. Not the OPs fault.

<comment><USER4> > "UK Virtual Reality Startup, Improbable, raises $1billion in Funding"

Probably a more reasonable title.

<comment><USER3> I agree. The post title rule doesn't always work.</comment></comment></comment>


Ask HN: Is there an open source license which prevents commercial use? - <AUTHOR>

I am planning on open sourcing a project I worked on. I am trying to find a license which gives others the freedom to use the code in whatever way they want to, with the caveat that they can't make money off it. I don't think anyone will try but still I just don't want others to be able to make money off my work. So do you know of a license which does what I am looking for? <comment><USER2> By definition, a license that discriminates against commercial use would not be open source, if I understand correctly (<http://www.opensource.org/docs/osd>).

That said, the GPLv3 would probably meet your needs well. It ensures that if anyone modifies your program and distributes it, they are obligated to release their changes to the source code (also under the GPL). I suppose they could still bundle your code up and sell it, but at least any value added by them in terms of program-modification should come back to you.

</comment><comment><USER3> Creative Commons CC-BY-NC-CA (<http://creativecommons.org/licenses/by-nc- sa/3.0/>) comes closest, I believe, even closer than the GPL, but it might not be as good for software as the GPL is (I've never used a CC license for software).

Other than this, the GPL(v3) is the closest thing, as has been said before.

However, the downside of restricting it to non-commercial use is that hardly anyone if at all will use your software, and it probably will never make it into any of the mainstream distributions, rendering it fairly irrelevant. I don't think that's worth the price, so I'd go with the GPLv3.

</comment><comment><USER4> Something that legally prohibits this falls outside the definition of open source. Dual licensing with part of it not available as open source can fulfill your need although many including me somewhat dislike that and consider that against the spirit of open source. The GPL prevents people from modifying/distributing modified source without releasing the source and is highly disliked by a number of companies who would have nothing to do with it. They can still use it without distributing it like on a server without releasing changes as open source.

</comment><comment><USER5> Why does it concern you that others not make money off the project? Why not just choose a license that allows you to charge money for commercial uses?

<comment><AUTHOR> That would work as well. I didn't realize there was an open source license which lets me do that.

</comment></comment><comment><USER6> "Make money off it" is rather vague. If you're just talking about reselling the software, the GPL3 might work. It's legal to copy GPL software and resell it, but since you have to provide the source (and GPL3 removes the Tivoisation loopholes), as a practical matter it doesn't happen.

<comment><AUTHOR> Yup reselling the software without any significant changes is the main thing I want to avoid.

<comment><USER7> If you care about "tivoization", you may want to look into the AGPL.

</comment></comment></comment><comment><USER8> Look into how Ghostscript is capitalized. It might be good to look at some other case studies too so you understand the broader range of possibilities. To get help on that you might need to phrase the question a little differently.</comment>


The Order of the JSON - <AUTHOR> https://blog.almaer.com/the-order-of-the-json/ <comment><USER2> Next installment: how flipping an innocuous switch introduced a subtle bug that was silent for years and cost us millions.

You can't just flip that switch, run _"a client to post the JSON to that instance"_ , see that test _"worked just fine"_ , and call it a day.

The POST might just store it, for later processing to wreak havoc (say by ignoring a value that isn't in the expected place in the JSON), or only rarely seen JSONs might cause problems, or it might 'only' break the yearly run, etc.

<comment><USER3> How do you justify ever changing anything with that attitude?

This change made parsing more lenient which is generally considered fine [1] and made the software actually follow the spec, since it specifies object entries are unordered.

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

<comment><USER2> _"This change made parsing more lenient"_

How do you know? It makes the outermost layer of the system accept more liberal in what it accepts, but that doesn't guarantee that the inner layers can handle that more liberal content.

For example, the code may assume that "<user-ID>" always is the first node in the _json_. If you start sending "<car-ID>" instead, things may go fine until you get two customers who share a car.

 _"and made the software actually follow the spec"_

How do you know? The spec of _this_ piece of software may state it has a JSON- like API that requires the "<user-ID>" to be the first node in every request.

And yes, most of its code may handle that change fine, but it only takes one piece of code to break things.

 _"How do you justify ever changing anything with that attitude?"_

In the case of _"a service running IBM DataPower Gateway which sat on top of WebSphere which sat on top of the COBOL."_ where _"Much of the system was so old that it was hard to find anyone who knew how it actually worked, and it's maintenance had been outsourced "_ : very carefully.

This change may have been fine, but you have to check that.

</comment></comment></comment><comment><USER4> This sounds very familiar. A lot of companies are full of people who have no curiosity and no ability to think for themselves. I have seen it multiple times where someone claimed a change is impossible or takes insane effort. Then you have someone competent look at it and you have a solution in an hour. I think stuff likes this is the real price of not hiring really good people.

<comment><USER5> I had the same thing happen to me lately, but I was at the stupid end. I am not a programmer by profession, so it matters very little to me, but I had been struggling to produce a correct solution to a seemingly simple problem (writing a macro to allow definitions in expression context in r6rs scheme). My solution worked but had the side-effect rewriting obviously bad syntax into correct one and not in a good way.

I was struggling with how to do it correctly, and then one of the people in the r7rs working group simplified the problem by a very large factor by pointing out to me that I was trying to solve a non-existant problem, because I tried to add definitions to expression contexts where it simply made no sense. In fact, instead of supporting all forms, I could get a better result by just focusing on one of them and add simple wrappers for another 5.

It was all quite humbling. Had I taken a step back and actually analyzed the problem I would have come to the same solution, but I immediately tried the, to me, most obvious and also hard-to-get-right solution.

<comment><USER6> You had trouble writing a scheme macro? I think most pro software developers would struggle to! I don't think this is dumb.

<comment><USER5> I do not have any problems writing macros (in fact, I recently finished my guile scheme version of rackets for loops) It is just that the macro I wrote did a lot more work than it had to, and led to weird syntax behaviour. I didn't delimit what I was trying to do. John over in #guile put me on the right track.

<comment><USER6> I didn't mean to imply you had trouble writing all macros. But as someone who is trying to learn some c-lisp on the side I can see why they can get a lot more tricky than "regular" coding that one might do say in Java. So the point is you are probably doing something more advanced there.

</comment></comment></comment></comment></comment><comment><USER7> (I've used both DataPower and COBOL - I've got a healthy respect for robust, long-lived legacy systems).

I must admit I was scratching my head on this.

The JSON spec might not specify order, but the serialized JSON is ordered by nature. JWT needs it for example (and I'd assume many signature models). Or you might have a caching layer that needs it. Maybe unchecking this causes the legacy backend to get hammered? There are valid non-spec concerns with order.

Replies here seem to assume stupidity here. It's a valid reason, but it's not the only one. Equally, the author doesn't ask "why" \- why would it take so long, why was that option enabled?

<comment><USER8> > JWT needs it for example (and I'd assume many signature models)

You almost never need canonical representations for signing things. I would even say that if you need a canonical representation to sign your things, then that is a design smell of your cryptographic protocol.

<comment><USER7> I didn't mention canonicalization. My point is that serialized JSON is ordered - which I think is exactly the same property you're referring to.

<comment><USER9> That's an implementation detail. Serialized JSON can also be printed, but your systems shouldn't depend that JSON is always ink on paper.

</comment></comment></comment></comment><comment><USER10> >I got to learn that we were talking to a service running IBM DataPower Gateway which sat on top of WebSphere which sat on top of the COBOL.

As soon as you read IBM you know you have bigger problems than COBOL in your system.

</comment><comment><USER11> > How does world not break due to technology more often

My own theory is that most (not all) of technology is there to support BS jobs and they are irrelevant for the normal functioning of society. It simply doesn't matter when (most) technology breaks.

</comment><comment><USER12> I agree the system described is crazy. However, I find it frequently useful to use ordered JSON as a data format and I think it would be handy if more languages supported it. For one, it makes it a lot easier to write integration tests using a "golden file" of ideal output, because your program that outputs JSON now usually deterministically has one correct output. For two, it lets you hash a json-encoded object deterministically.

<comment><USER13> OK. I _totally_ prefer ordered JSON, because it is so much easier to eyeball - to visually compare JSON with different ordered keys is quite a lot more difficult (O() complexity?) than if they are in the same order. It also enables _diff_ to help see _where_ the differences are (diagnosis, not just binary identical or not).

And, in fact, I do use ordered JSON for comparison in testing, as you describe.

 _However_... comparison of JSON as objects (i.e. in memory) is order independent. Hashcode is also order independent (the trick is to sum the elements' hashcodes e.g. [https://docs.oracle.com/javase/7/docs/api/java/util/Set.html...](https://docs.oracle.com/javase/7/docs/api/java/util/Set.html#hashCode\(\))

Diff for ordered JSON is possible using longest common subsequence for trees, but has terrible complexity, and lacks diff's clever optimizations both general and specific to typical input.

<comment><USER14> +1 for all reasons above for ordered JSON, highly convenient in practice.

And if it doesn't impact performance significantly, these are all pretty good reasons for JSON outputters to default to sorting objects deterministically by keys, or at least to provide a flag to do so. (Even if there's no canonical sort order between JSON libraries, all that matters is it's deterministic for each library.)

BUT... I can't imagine any scenario where you'd want to _validate_ that JSON content was ordered on the _input_ , which is what was enabled in this article. Why does IBM even have that as an option?!

Be strict in what you emit and liberal in what you accept, and all that...

<comment><USER13> I guess because OrderedJSONObject is ordered, not sorted. Like java's LinkedHashSet, it maintains the order keys are added.

If you're going to rely on a specific order for comparisons, it makes sense to alert the user to any JSON in a different order (instead of silently, liberally accepting it), or you'll get false negatives elsewhere. Easier to check for a sorted order, but also possible to define a specific order. IDK what IBM did here.

funfact: jq used to sort keys; now it retains ordering.

<comment><USER15> Indeed, and remember this JSON message is going to a mainframe. Mainframes don't have much memory and typically process record-by-record, or event-by- event. So the implemenations probably streams the JSON in and constructs COPYBOOK from the payload before continuing to invoke the cobol.

So the rework time might be to write a general purpose re-order layer that can re-order any imcoming message.

</comment></comment></comment></comment></comment><comment><USER16> > Much of the system was so old that it was hard to find anyone who knew how > it actually worked, and it's maintenance had been outsourced to some of the > typical IT outsourcing companies of the time.

Some years ago, I worked on an antitrust case involving a firm that had outsourced relevant systems. Multiple times, to different IT firms. And there was literally nobody left who knew how they worked.

After considerable negotiation, they agreed to provide documentation. And what that ended up being was a report by IT company 2 about their understanding of what IT company 1 had done with the firm's systems. Because, I gather, IT company 1 had evaporated.

And yes, the core of it was COBOL.

</comment><comment><USER17> Ha! Stephen Dolan had to add this to jq quite sometime back, making it preserve object key input order on output. And yes, it's infuriating, but it's also somewhat convenient, and yes, there really is software out there that cares about object key order (sigh).

<comment><USER18> Doesn't anything using jwt depend on a specific order?

<comment><USER19> It shouldn't, unless you base64 decode the header, then parse it with a library that causes the order to change, encode it again, and then use your own re-encoding to calculate the signature:

      HMAC-SHA256(
        b64(reencoded_header) + '.' + b64(payload),
        secret
      )

You should really just verify the signature for the provided header + payload in their base64 encoded form.

</comment></comment></comment><comment><USER20> Ha. Creating a layer on top of broken APIs is an thriving business. Every single carrier company has a broken API. That's why companies like aftership exist.

One example I struggled with for days recently was USPS. Not only they use xml in the url parameter, the order of the elements also matters. Unfortunately, the order in the documentation is incorrect.

<comment><USER21> Hell even Amazon's ec2 spec is confusing in some places (the boto python call parameter doesn't always match the restful call, which is less documented, leading to errors in some libraries).

</comment></comment><comment><USER22> I wrote a json serialization/deserialization library for C++ and if you provide the members in the order they are specified in the type you get better performance. It can construct the class without having to bounce the parser back to that location and it is much much more cache friendly.

<comment><USER23> I also would much rather write code that doesn't quite do what it's supposed to if it's easier to do and I can take an extra day off. However, that's not my job.

<comment><USER22> It's an interesting problem. So if all the parser does it put them into a variant like structure, sure whatever. But when you go to put them into the reified data types you would be wasting a lot of resources to parse JSON to an intermediary data structure and then request the members. I parse them directly to their final classes. So I was left with a choice and both have a cost. Parse the json in-order of the file and store the concrete type to grab it later, or store the position/size of that part and move to the next constructing them in the order needed. This was cheaper. It will parse the JSON in whatever order, just the performance can be impacted by the data ordering as many parsers are.

<comment><USER23> Is your parser general-purpose? Is it template-based? Is the performance variance due only to the impact on the processor's cache or are there other factors? Is the code open-source, maybe I could just look myself?

<comment><USER22> It is template based so that each types JSON parser is statically known and to give the compiler more opportunity to optimize. [https://github.com/beached/daw_json_link](https://github.com/beached/daw_json_link)

I haven't had a chance to look at why yet.

</comment></comment></comment></comment></comment><comment><USER24> I just recently dealt with a JS library that was expecting object properties to be in a certain order ("works" in ES2015 [1]), and that object was loaded via JSON. Was a huge pain getting the object in the required order.

[1] [https://stackoverflow.com/questions/5525795/does- javascript-...](https://stackoverflow.com/questions/5525795/does-javascript- guarantee-object-property-order)

</comment><comment><USER25> How were they going to charge him for 9 FTEs for 6 months to uncheck a checkbox?

<comment><USER26> Write some software that reordered it probably.

<comment><USER27> Yep. Probably IBM Data Transform Services™ installed in the cloud plus a custom plugin written to do the ordering. That's a few folks to deploy and configure the server. A few more for the engineering. Oh and there's probably a support contract to support and maintain this new "solution".

</comment></comment></comment><comment><USER28> For what it's worth, I do wish it was trivially easy to customize things like error log output, so that I could say that I _always_ want the timestamp first, followed by severity, followed by whatever else. Our logs are annoying to parse when debugging things locally.

<comment><USER29> all the modern logging libraries does this now i think.

and with app like fluented, we can decorate it with whatever metadata we want (instance name, machine type, container name, etc..)

</comment></comment><comment><USER30> Writers should produce sorted maps, readers need to accept unsorted maps.

It's a security issue, not just convenience. With unsorted maps the internal hash seed can be exposed, together with timing information.

Another famous omission from the specs.

<comment><USER31> I'm no security expert. How is "exposing the hash seed" a problem for the vast majority of applications? What timing information would be leaked and why would that be problem?

On the other hand, accepting unsorted maps seems like it could introduce covert channels?

<comment><USER32> [https://bugzilla.redhat.com/show_bug.cgi?id=750555](https://bugzilla.redhat.com/show_bug.cgi?id=750555)

This led to hash randomization on by default since Python 3.3.

<comment><USER31> Cool. Thanks.

</comment></comment></comment></comment><comment><USER33> This makes my head hurt. I wonder if you end up with sorting differences depending on the locale?

<comment><USER34> It's not sorted, but ordered: The order emitted is the order entered.

</comment></comment><comment><USER35> I built the first popular sports "app" for the original iPhone, back when Jobs claimed that there was no need to write native code.

The backend polled an API that served XML updates on game scores etc. Note that I didn't previously know anything about baseball (and I still don't, not really).

So let's say that a baseball team scores a Double. We'd see some XML like <doubles><double/><double/></doubles>.

Now, suppose a team scores a tripple... You know that there's a <triples></triples> entity. What would you expect to see inside the node?

If you're me, you'd expect to parse <triples><triple/><triple/></triples>.

I got the call during dinner. There was an important game happening, and the app suddenly broke. People were uptight. They loved our app and they were complaining.

In the end, it turns out that we would need to process <triples><double/><double/></triples>. Why? "Oh, it's always been that way." (Says the brusque developer at the service charging $50k/month for access to this feed.)

</comment><comment><AUTHOR> recent twitter thread referenced in the article: [https://twitter.com/therealfitz/status/1161349619659530242?s...](https://twitter.com/therealfitz/status/1161349619659530242?s=20)

<comment><USER34> It's not sorted, but ordered: The order emitted is the order entered.

<comment><USER34> Sorry, that was intended to be a reply to the prev. comment.

</comment></comment></comment><comment><USER36> The tweet at the top of the article says

> _This so far out of the spec it makes my ankles hurt._

This is not in fact out of spec. The JSON spec does not define semantics here but instead quite explicitly leaves it up to the JSON processor and data interchange spec for what to do about ordering of objects.

<comment><USER3> > This is not in fact out of spec. The JSON spec does not define semantics > [...] for what to do about ordering of objects.

What? It is literally on the first page of json.org and section 1 of RFC 7159 [1]

> An object is an _unordered_ set of name/value pairs.

> An object is an _unordered_ collection of zero or more name/value pairs

[1] [https://tools.ietf.org/html/rfc7159#section-1](https://tools.ietf.org/html/rfc7159#section-1)

<comment><USER37> There are multiple standards. [https://www.ecma- international.org/publications/standards/Ec...](https://www.ecma- international.org/publications/standards/Ecma-404.htm) Is more relaxed.

>The JSON syntax does not impose any restrictions on the strings used as names, does not require that name strings be unique, and does not assign any significance to the ordering of name/value pairs. These are all semantic considerations that may be defined by JSON processors or in specifications defining specific uses of JSON for data interchange.

Also it's pretty clear that the keys must have an order going over the wire. And JavaScript objects (which aren't unrelated to JSON have an order now) [https://www.stefanjudis.com/today-i-learned/property- order-i...](https://www.stefanjudis.com/today-i-learned/property-order-is- predictable-in-javascript-objects-since-es2015/)

</comment></comment></comment><comment><USER38> I've been asked by architects to order JSON properties. It's fine until you depend on it. i.e. accessing a map as you would an array

[https://fasterxml.github.io/jackson- annotations/javadoc/2.3....](https://fasterxml.github.io/jackson- annotations/javadoc/2.3.0/com/fasterxml/jackson/annotation/JsonPropertyOrder.html)

</comment><comment><USER39> I have written an app for the menu of my university's canteen. The JSON API that I used returned the meals as fields of a document where the order of the fields was the actual display order. It took me a while to even find an implementation of a JSON parser that keeps the order of the fields.

<comment><USER40> I would assume that any decent JSON parser has at least the option to keep the order of the fields. Especially for CLI tools that automatically add fields to a JSON file thats usually edited by a user e.g. package.json, I feel that it's absolutely crucial.

</comment></comment><comment><USER41> This is an omission from not only the JSON standard but also the JavaScript language, JavaScript has no map order and the rest is history.

The result is that all implementations are broken, f.ex. this is how a tree structure has to be implemented with JSON:

[http://root.rupy.se/meta/user/task/eelzter/44953781393584543...](http://root.rupy.se/meta/user/task/eelzter/4495378139358454353?sort=2)

It's inefficient, ugly and just wrong.

</comment><comment><USER42> Sounds like normal life to me. Please give me $$$$

</comment><comment><USER43> "Why would you care what order we were sending the name value pairs for this?" The article makes it sound like it's somehow IBM's fault. However, questions about preserving order in hashes/associative arrays/maps/whatchamacallit span at least thirty years. Some applications of the format even demand it (e.g. ansible uses YAML - a superset of JSON - or even straight JSON for it playbooks; emitting them out of order is not an option).

Every time the issue surfaces it elicits a large amount of eye rolling among the cognoscenti. However, I'm a firm believer in the idea that recurring demands from the user base need to be addressed, rather then mocked. The coding community appears to me notably tone deaf on this.

'Course anybody can use <insert suitable technique> to send a JSON map in the desired order, except the parser on the other hand will blissfully disregard it. Or you can devise any ordered solution on both ends, which will leave you outside of the accepted standard and open you up to the situation described in the article (where the requirement may well have been frivolous).

I can remember very few - if any - instances of somebody implying that the standard should somehow make room for this kind of scenarios. The standard reply was "use a different format" or "change the requirement". (Somehow remembers me of people asking what can one do to have whitespace-preserving XML, and at least one amusing story about that)

<comment><USER44> Json has a perfectly fine order preserving key-value map:

        [["Key1", "value1"], ["key2", ...

You just need to deserialise it into a specific collection on the receiver. It's within standards and there are no weird parser issues.

<comment><USER43> That's a way. A way that, IMHO, vastly diminishes its expressive power on the reader's side, which I do not consider a very good thing. Most solutions to the issue are of this nature.

Consider serialized JSON already has a natural ordering, which is thrown away for some reason (probably parsing convenience).

<comment><USER44> > which is thrown away for some reason (probably parsing convenience).

It's got nothing to do with parsing. The json comes from JavaScript syntax, where objects represent unordered mapping. Json naturally does the same.

If you want expressive power for reading, json is very poor in comparison to pretty much everything else. Just use it for simple serialisation.

<comment><USER43> Granted, it came from there, but that was back in the days of map=eval(json) and they're gone. There is nothing in json the format (as opposed to json the language construct) to impose the unordered behavior.(Or, for that matters, the 'no comments' bit).

<comment><USER45> > There is nothing in json the format [..] to impose the unordered behavior

That's not true. The spec at [http://www.json.org/](http://www.json.org/) says "An object is an unordered set of name/value pairs".

<comment><USER43> Yes, that's in the specs. But what I meant is that there is nothing intrinsic to the format demanding unordered behavior.</comment></comment></comment></comment></comment></comment></comment>


Farming luck with a portfolio of small bets - <AUTHOR> https://knowledgeartist.org/articles/ff35a372-94b1-4168-b97c-92fc0548a70a/farming-luck-with-a-portfolio-of-small-bets <comment><AUTHOR> This is a discussion about my current approach in life to get more of what I want. Been seeing some good results so far, but more importantly having a blast in the process :D

Would love to hear what others think!</comment>


Proposed Porn Tax to Pay for Wall - <AUTHOR> https://www.yahoo.com/huffpost/arizona-lawmaker-wants-porn-fund-171851269.html <comment><USER2> This seems rather dystopian. Will people allow this to be implemented?

<comment><AUTHOR> In the "before times", I wouldn't have thought so .. now, who knows ?

Imho, it runs afoul of Constitutional issues and "life, liberty, and the pursuit of happiness" .. but nowadays so many things are happening that _shouldn 't_, I'm not sure what "allow" means anymore.</comment></comment>


TikTok famous: How the app is turning teenagers into celebrities - <AUTHOR> https://www.vox.com/the-goods/2019/10/2/20891915/tiktok-famous-teenagers-haley-sharpe-yodeling-karen <comment><USER2> It is also a Trojan horse sent by the Chinese government to test how gullible users are to surveillance.</comment>


Ask HN: Go or Python? Expanding my toolbelt - <AUTHOR> I have no desire to learn JavaScript, and by elimination I'm between Go and Python 3 (CPython?).
I'm talking about really learning the language. Not just doing some quick side project.
What would you choose? The deciding factors for me are: being future proof so my knowledge could be used in the next 5 years, cross platform, and has a solid, consistent standard lib. I'm looking for a "can do several things with it" language that can also help me to be a better developer (by exposing me to new stuff). I might use it for scripting or cli tooling but (ba)sh and powershell served me well so far.
I'm not considering mobile since I'm tired of Java and I have no desire to use the Apple ecosystem. But of course that it would be a plus.
I was also considering C# (is there a TL;DR? so many keywords and revisions that I already lost any desire to learn it) but Microsoft worries me. My tools and workflows are Linux based.
Python being slow worries me and maybe most of my effort would be spent in learning to produce pythonic code instead of learning deeper concepts. <comment><USER2> I think you should go for Python.

1\. Python is definitely future proof. It is most likely going to be THE language in the near future. Machine learning and AI is most likely where most new breakthroughs will happen, and Python is well positioned to leverage this. Read more here [http://blog.hackerrank.com/emerging-languages-still- overshad...](http://blog.hackerrank.com/emerging-languages-still-overshadowed- by-incumbents-java-python-in-coding-interviews/)

2\. Python has a good standard library. It has been around for a while now, so it also has a huge number of high quality third party libraries.

3\. Python is slow and this is a serious disadvantage. However writing Pythonic code is an aspect of Python that I absolutely love. I think Guido's guiding principle "code is read more often than it is written" is quite true and writing beautiful code is a thing worth learning. Other people will love you for it.

<comment><USER3> > Python is slow and this is a serious disadvantage.

Eh yes, and no. I don't wish to argue, because out-of-the-box, it's an interpreted language with a global lock, and it most definitely is slower than most compiled languages. Sometimes orders of magnitude so. On the other hand, computers are damn fast, the developer productivity gains of writing Python are huge, and there is a flip side, especially for somebody who wants to "really learn the language."

Within the CPython ecosystem, there are tons of well-established 3rd party libraries that take advantage of the speed of C, without your code ever needing to know. Take for example numpy/pandas or asyncio with uvloop. A step up from that, there's Cython, which is surprisingly robust and easy to use. It also makes interfacing with C code rather simple, and thus provides an avenue for optimizing speed-critical code paths without needing to know CPython internals to do so.

Outside of using CPython, there's the well-established PyPy, and the up-and- coming Pyston.

My point is, if you need a faster Python, with perhaps a little bit of effort it's out there.

</comment></comment><comment><USER4> Given some of your comments here about learning a new language to experiment without a clear direction I couldn't possibly recommend Python more strongly.

Wanna build a web app? Wanna dabble in Datascience? Oh you wanna do Machine Learning? How about a desktop app? Game? Yep Some powerful scripting?

Just so easy to get productive.

</comment><comment><USER5> My work is primarily Python, and only a few months ago I started learning Go. Both of them have their own weak and strong points, and I can't definitively say you should go for one over the other, but these may help you consider:

\- If you want to get sh!t done, and quickly, go for Python. It's really easy to build things from scratch with Python because of how concise, clean, and clear the language is. Plus, the Python community is huge so there's practically a package for any advanced functionality you need (and it's easy to write one yourself). There's a reason why research giants such as Google, NASA, and the LIGO project use Python -- it's because you get to spend less time getting your code to work and more time actually designing the underlying models. TL;DR: Write and ship code faster, at the cost of actual runtime performance (but PyPy and Python 3.x with asyncio, makes Python more competitive in performance as well).

\- If performance is your focus, go for Go. It's a lot stricter than Python because it's a compiled language and therefore you'll get a lot more compile- time errors with regards to variable typing and conventions (reminiscent to, but arguably even stricter than, C++ and Java). On the upside, you'll undoubtedly incur less technical debt, at the cost of spending a lot of time cleaning your code and getting it to work. Go is pretty young, but it's gaining a lot of traction (spawning the likes of Hugo, Docker, and Kubernetes), so if you need your program to be more performant and highly concurrent, go for Go. TL;DR: Spend more time writing code, in exchange for your program being easily concurrent and performant.

Personally, unless I'm writing OS-level programs that require fine-tuning of things such as memory management, I'd go for Python. Some of Go practices and conventions got tedious and old pretty fast.

</comment><comment><USER6> I've written production projects in both go and python. My choice would be python.

Python has a great standard lib which is mature, and not changing a huge amount. It also has a lot of modules that you can pip install.

If you are really worried about performance, you can pick Go, although you might as well just do C++ if you're super hardcore about performance. While the garbage collector has gotten a lot better, it's still a perf hit.

That being said, for most of the code I write, it's only slow in python if I'm doing something stupid. The threading and pool primitives are also very useful.

For simple web services, there are also a number of mature python frameworks (flask, django) that have more features than some of the basic go http server stuff.

It's also a fair bit faster to bootstrap simple CLI programs with python. Argparse is also great.

</comment><comment><USER7> Python since it's stable and mature. Or if you're deadset on supposedly easy (at the cost of memory) concurrency, Go makes more sense and it's newer and all you'll get e-peen points for being on the cutting edge. Python's been around 20-years.

<comment><USER7> also python need not be slow, but it need not be used for everything. There are jits for it and you're not beholden to CPython either.

</comment></comment><comment><USER8> Both! Python has a fantastic eco-system and you can build lots of things using existing libraries. Go is new and different and useful for server type applications and easy to learn and you can finally figure you what everyone is bitching about when they claim Go is not a good-enough language because it doesn't support generics ;-).

</comment><comment><USER9> I think Go matches your criteria. I've put more eggs into my Go basket than my Python one. For myself, I focus on building networked distributed systems. Go helps me do that (and build useful cli tools). I mostly resort to Python for scripting.

What type of programming do you want to do? I don't think I would recommend Go for game development or embedded systems (though people do it).

<comment><AUTHOR> For personal reasons I have to stay a couple of years at my current job (back- end and some ops), I do some boring stuff but the payment is nice. I don't want my brain to slow down too much so I'm looking for a language to do random stuff without thinking much about what exactly I'm going to create. But probably something related to web development, cli tools/automation, maybe a desktop app just to put in my CV (Qt?).

<comment><USER9> I've seen QT binding libs for Go, but I am not familiar with them. Go shines in the back end, but I think Python would likely be a better choice for a desktop app with far more examples to learn from.

More than becoming an expert in a given language or stack, another thing to consider is learning a domain. I'm partial to distributed systems, but if image or audio processing, or desktop app, or whatever it is what you find interesting, diving into those will keep you from getting stale and make you more marketable if and when you decide to move to a new employer. The tech stack will reveal itself or you will find that it is fungeable. The key for the resume there will be personal projects, meet up talks, and blog posts as opposed to work experience. At my work, we would be very interested in talking to such a person interested in distributed systems.

Whichever you pick, I hope you find fun.

</comment></comment></comment><comment><USER10> One factor I would consider is how different a language is from what you already know. For example, learning something like Haskell, Elixir, or Elm (Elm is fantastic) might help you grow more as a developer because you'll be introduced to entirely new ways of reasoning about and solving problems.

<comment><AUTHOR> I think I'm too dumb to learn how to use something like Haskell (properly). I have a memory/attention problem, medication helps but I almost gave up programming for it. Don't get me wrong, my code is highly praised for being moderately ok, but I have to play my strengths.

I was surprised that all of the Elixir hype seems to have died here.

<comment><USER10> You're not too dumb! You can do anything you set your mind to :)

I totally understand not wanting to dive into something like Haskell though. Between Go and Python, I personally would choose Go for a long term commitment. I think the language is simple yet beautiful, has a robust standard library, and performs really well.

Python can be learned super quickly though, and being able to whip up a script is useful (you can 'import' seemingly anything). I'd say it's worth sprinkling in a little Python on the side.

</comment></comment></comment><comment><USER11> > I have no desire to learn JavaScript... > ... and I have no desire to use > the Apple ecosystem.

I would recommend to take a look at Typescript and Swift.

Typescript is a better JS and Swift runs on Linux too.

</comment><comment><USER12> I had a similar desire to learn another language (after 20 years of Java and JavaScript), and Python was definitely on the list. What helped me decide was to look at the projects and tools that I used or wanted to use (and potentially contribute to) and then see what language they're written in. In my case, I'd been doing a lot of Docker and Kubernetes work, so Go was a natural choice.

If I'd been more interested in "Big Data", then Python (or, if I wanted to stay in the JVM world, Scala) would have been my choice.

Either way, Python and Go will be around for many years to come.

</comment><comment><USER13> It actually depends on what you going to do with your knowledge, Go is definitely more efficient and faster than Python, on other hand Python is more popular, easier to use, has bigger set of available libraries.</comment>