With respect, I think there's a fundamental error in this reply. You're making a dogmatic statement about what interpretability is taken to mean, which assumes of course that the vast body of work, both in academia, journalism, and business meetings, holds a consistent view. The point of this paper, however, in part, is to point out that this view is mistaken.

You are incorrect in your claim. The paper does make a good point that under the umbrella term "interpretability" there are varied and conflicting understandings of what, specifically, is meant.

That fact has nearly zero relevance to what I'm saying.

When I say that people look for mappings from the model to a space of cognitive structures over which they have authority, it could be (and observed in practice always is) a smattering of all the different things talked about in the paper -- authority over which diagnostics represent 'trust,' authority over which visualizations are adequately informative, authority over explaining 'how' an algorithm works, and so on.

Though all of these are discordant takes on the specifics of interpretability, as discussed in the paper, they still are unified in the sense that the true intention in appealing to any of them is to map things into a domain where someone wields the authority. It's not about actually caring about trusted diagnostics, or caring about quality visualizations, or caring about communicating the intuition behind a model. Those are just the plausible deniability excuses proffered to try to win the battle over which faction's authority gets center stage.

I don't require that anyone have a cross-domain consistent view of the specific definition of interpretability in order for my claims to be a viable explanation, and so it is perfectly compatible with the paper. The paper looks at the on-the-ground specifics used in the arguments over interpretability, meanwhile politics explains the behind-the-scenes motivations of any of those specific choices.

The Moral Mazes chapter Dexterity with Symbols is a good place if you want to read on the evidence about how this is carried out in management bureaucracy. It has actually been formally studied in some interesting ways.

Cool post! I think as technologists seeking to build tools for music creation, browsing, etc. there are some high level points to take from Professor Berger's article. As we deploy machine learning to match listeners and songs, we're often blindly satisfying expectations, when the entire essence of musical experience seems wrapped up in upsetting expectations.

This looks interesting. Am I correct in understanding from your diagram that Kozo generates both the clientside and backend code? In what language does the developer write? Another question: how much control does the developer have over the server once the application is deployed?

Thanks for any response and good luck with this project!

My understanding is that you "describe" your project using XML or JSON or code (which can be written against libraries in "the language of your choice"). Then, Kozo spits out a skeleton project based on that description in the tech stack of your choice.

So, you would (optionally) write code in unspecified languages to describe your project, and then you would have to actually finish the skeleton project, of course.

That's already quite accurate. However, you can also bind against external APIs and deploy Docker applications to fill the skeleton application.

The structure can be written in a JSON or XML format or alternatively be constructed using one of our libs, which are planned to be written in D, Python, Java, Ruby, PHP and possibly/almost certainly others.

We generate client & server side code and you can get the source code out in one of the supported stacks. Alternatively, we can host for you on a scalable stack, so you wouldn't need to care about setting up your own environments. If you deploy on your own stack, you obviously can have full control, if you deploy with us, we'll provide a number of configuration options, but generally it's a compiled server app running on a auto-scaling stack.

FWIW, I think this is a really cool idea. When I was trying to imagine use cases, most of them involved a project being generated on only one stack. Mobile apps are the only exception I can think of. Do you expect that most people will only generate their project once, on a single stack?

Right now, mobile seems to be the "exception". However, when you're thinking of other, "less common" stacks, like cloud-based Desktop applications or Browser extensions, new use cases become evident.

Furthermore, we're getting more and more stacks right now, such as wearables and sooner or later AR/VR devices/platforms - hence, the need for such as cross-platform tool will certainly increase. Plus, we also make developing single stack apps easier/less painful, so even then it will (hopefully ;) ) be helpful for people.

I only listened for about 5 minutes, but it was actually pretty pleasant. Rather unlike your comment.

Unfortunately, I'm 18 points away from being able to downvote, so I'm posting this instead.

My recommendation: chill out and take a 30 second break before re-reading and then posting your comment. Also remember that a human being just like you spend a non-trivial amount of effort working on whatever it is you are looking at it. Then you might feel less inclined to naively shit all over it. One alternative approach, if you have nothing constructive to say: peacefully close the tab and move on with your day.

Humans spend far less trivial amounts of time creating works of literature. A novel may consume three years of an author's life. And yet for years society has been enriched by a lively and often sharply critical literary discourse. By comparison, this is a trivial project, and yet the culture is so much more defensive.

You even threaten to downvote me! (oh my). How can you simultaneously want to change the world and clamor for censorship?

Censorship? Hardly. A downvote is just the easiest way for them to signal their displeasure.

The cultural attitude you see prevalent here defending creators is due to the community's wont to make this a safe place for sharing, especially given the recent efforts at making "Show HN" a first-class citizen.

Constructive criticism is a good thing, but I don't think that's missing from HN. What dwaltrip (and Hytosys below) are suggesting is that your criticism is not in the least bit constructive, and takes a tone that would otherwise negate any constructive bits. I concur.

If you're curious to see how a comment might actually be constructive in the course of being critical, I'd seriously consider erikschoster's comment.

My main point is that you can critically comment without being a dick. I could have been more clear about that.

Also, I wasn't threatening to downvote, I was explaining why I was creating a somewhat low content post.

"Nothing could be less aspirational" and "I think I need to wash my ears" aren't just negative, they are inconsiderate and unhelpful insults.

I think there is a problem with how shamelessly uncritical we can be, especially when imposing ourselves upon other walks of life, especially art. Startup culture should aspire to be more than a Tony Robbins convention.

I wholeheartedly agree that we should be free to critique, and I think that erikschoster (see his top-level comment in this submission) did a good job being negative yet helpful. I believe startup culture is mind-numbingly optimistic, too. With that said, there's a necessary balance between being critical and being empathetic.