EvanMiller's comments

I cut my teeth on Perl 5 in the early 2000s, and I've been curious about Perl 6 for a long time.

Last year I sat down with Perl 6 for long enough to form opinions on the language's merits, which are many. I'm told many of my criticisms have been addressed in the five months since the article was published, but perhaps some of you will enjoy reading the original review. Cheers!

https://www.evanmiller.org/a-review-of-perl-6.html

I recommend the approach described in this article:

http://www.evanmiller.org/ranking-items-with-star-ratings.ht...

In this formulation, s_k equals utility. Like the Wilson score formula (and unlike the linked article), the provided equation takes into account the variance of the expected utility.

This Economist article's a bit chatty and superficial (surprise), but in an age of mass anxiety and digital distraction, I think the goal of the Epicureans is as important as ever: How does one go about producing a calm mind? It's not a simple task, and I think correctly has to analyze the mind in relation to everything else.

The atomic hypothesis of the Epicureans seems like a side quest into physics, but the fruit of the journey is that everything's just combinations of atoms and the mind must be made of atoms too, so let's think of it as a physical system with inputs and outputs, and forget about any grander god-narratives. With this perspective comes some very practical advice; Lucretius for instance has an extended passage on how to deal with a "crush". I'll paraphrase but he points out that your crush exists purely as an image in your head, and you really have no idea what the person behind the image is like, and if you finally get together the sex will probably be very awkward, so it's better to direct your mind and amorous intentions elsewhere. I believe the phrase he used was to find smaller pleasures that carry no penalty -- because seeking the larger rewards almost always leads to misery.

Lucretius is a good read and the Latham translation has some felicitous turns of phrase. It's fun imagining arguing with the ancient philosophers about their physical theories, which they support (as best they can) with the available evidence about what wind, liquids, lightning, thunder, earthquakes, smells, tastes, sights, etc. are made of. It's a shame philosophy got distracted with "higher things" for so long (i.e. 2,000 years) because here we are realizing again that everything is made of atoms, and it sure would be nice to have more advice on living life in the face of this fact.

Nice interactive examples but I'm afraid the basic setup here doesn't make sense to me. The "atom" is defined as the average encoding of inputs with the feature ("faces with a smile"), but I'd think the proper definition should subtract off inputs without the feature (i.e. "smile" = "faces with a smile" minus "faces without a smile"). The way it's defined you end up adding an extra "average face" along with the feature of interest, which is clearly seen in "The Geometry of Thought Vectors" example -- the non-smiling woman isn't so much forced to smile as to have her face merged with that of a generic smiling woman.

I'm a fan of this library -- I used it to build Hecate (https://github.com/evanmiller/hecate), a terminal hex editor. If you get creative with Unicode box and box-drawing characters, you can build some interesting interfaces (tabs, progress bars, etc).

The method described here is simple because it's only looking at the mean of the belief about each item; it uses the prior belief as a way either to sandbag new items or to give them a bump. I tend to advocate methods that take into account the variance of the belief in order to minimize the risk of showing bad stuff at the top of the heap.

I have a newer article (not mentioned here) that ranks 5-star items using the variance of the belief. It ends up yielding a relatively simple formula, or at least a formula that doesn't require special functions. Like the OP I use a Dirichlet prior, but then I approximate the variance of the utility in addition to the expected utility:

http://www.evanmiller.org/ranking-items-with-star-ratings.ht...

The weakness of the approach (as well as the OP) is that it doesn't really define a loss function for decision-making (i.e. doesn't properly account for the costs of an incorrect belief), which one might argue is the whole point of being a Bayesian in the first place. In practice it seems that using a percentile point on the belief ends up approximating a multi-linear loss function, but I haven't worked out why that is.

This is a compelling little essay. I think the author left out a couple of important points, though.

1. Design systems may be "algorithmic," but they're primarily mathematical, and equations remain stubbornly hard to use. Metafont failed to attract designers because no one wanted to cook up high-order polynomials to express their visual ideas. (In contrast, Adobe came up with a good-enough interface for Bezier curves, and now the world uses non-algorithmic fonts.) The new class of designers will need solid grounding in at least high school algebra to get their curves and easing functions right.

2. Any argument about "XXX should learn to code", where XXX is anything other than "aspiring professional software developers," means that there is a significant market opportunity for creating usable software that does not require coding. If people are willing to spend thousands of dollars on bootcamps to learn to code -- when they'd really rather be focusing on their domain problem -- then they're theoretically willing to pay thousands of dollars to not have to learn how to code.

I don't know the state of design software, but if it's anything like other professional desktop tools, it's horrible, creaky software stuck in the early 1990s with very little competition in sight. When I read this essay I can't help but think there's an opening for usable algorithmic design software -- whatever that may look like.

I really like the analysis of finding versus maximizing product cycles. There are a few aspects of "Moral authority" that I think have been left out.

1. The rank and file know (or at least think) that a professional CEO is less likely than a founding CEO to be around in 5 years. So when a new professional CEO says "Jump" it's much harder to get people to change their way of doing things, particularly if they suspect the next CEO will undo all the changes. When a founding CEO says "Jump," you might as well get with the program because the change is likely to be permanent. (For the economists in the audience, this is a version of the Lucas critique applied to organizations.)

2. The "knowledge pyramid" isn't just about the CEO's epistemological state and decision-making apparatus; it's also about communicating the values and identity of the company back to the company. Founding CEOs are in a superior rhetorical position because they can say "I hired you all because each of you ________", and give everyone the warm fuzzies. The professional CEO on the other hand has to speculate or impute motivations to the previous CEOs, which is less motivational. As a recent example, I think Satya Nadella has done a relatively poor job of communicating what makes Microsoft employees different from other employees; instead of saying, "You guys understand the full stack better than anyone" (or something), he can't help but to talk about market opportunities and cloud-first productivity blah blah blah. (Which is to say -- not only was he in an inevitably weakened rhetorical position with respect to BillG, he squandered it when it came to articulating the company's identity.)

3. Founding CEOs are in a better rhetorical position when it comes to navigating value conflicts between quarterly earnings and something else ("changing the world"). When communicating with immediate subordinates they can do a kind of good-cop bad-cop routine with the board of directors ("The board really wanted X, but I thought that'd be bad for customers, so we're doing Y."), whereas a board-picked CEO will be assumed to act only in the interest of the stock price. For many companies (e.g. organizations that profess to be on some kind of higher mission) this sort of CEO will be rather uninspiring, and therefore the professional CEO will be less capable of effecting change throughout the organization.

4. Professional CEOs have to navigate a more precarious political situation because there's a good chance that one or more subordinates want the CEO's job. (I would hazard to guess that insiders usually replace outsiders and outsiders usually replace insiders.)

One thing this article leaves out is a deeper analysis of why the conventional wisdom is to replace a founder with a professional when there are so many famous counterexamples. It could be that at a certain stage in a company's growth investors prefer to be more risk-averse and will give up a potential grand slam in order to get a two-run double, or something. (And by extension the OP is willing to take larger risks than the average VC.) Or that there are hidden social dynamics at play.

That's a great story! What's the app if I may ask?

I received an interesting reply over email which I wanted to share here. With the author's permission I've reproduced it below but blanked out some details:

> I (or we as a company) faced pretty similar situation just a few weeks ago.

> The app is called ______, and it was our first app ever, our child - app that constituted our company brand and still is pretty useful for many small business owners (_______ is an invoicing app, making something like $20k/year on our domestic market).

> Unfortunately(?) business is business, so finally I decided to decline it. Now we’re making some final touches and will release it as open source project - again facing similar problems - the codebase is almost 6y old, app is not trivial, build procedure is not single click etc etc.

> Besides all those risks and problems, I still believe that opening the source code is worth doing. That way we can help other (less advanced) programmers to start their own mac products/businesses. I’m sure that you’ll agree that after a certain point you need to look inside something bigger than a trivial app from examples folder, something that is/was a real thing, something ‘alive'. That’s IMHO a single priceless source of practical knowledge.

> That’s my 10cents :)

There's no desktop section on Flippa.

Yeah, and it's not just APIs. Some of the changes are much more subtle, e.g. how often a particular event fires. If you're not careful these can destroy performance in baffling ways.

If you make an effort to stay on top of all the latest OS releases, life is great, but it's frustrating when you're trying to remain backwards compatible and figure out what the heck is going wrong on the new OS.

Thanks for advice. The main issue is that I have better traction/reviews/revenue on another app, and the work required to get #2 and #3 on your list would seriously detract from the attention I could give to that other app.

There have been a few times where I've followed that exact logic to fix it up, spent a weekend or two on it, and gotten pulled away again. The software has reached a size where it's hard (mentally) to switch back and forth between it and my other app.

The other issue is that now that I have more experience doing Mac development, I'm starting to see that it's not a simple matter of bug-fixing. Some significant development would be needed to bring it up to the same level of polish as my other app, and in the meantime I'm concerned it's detracting from my App Store reputation.

Bugs (including, but not limited to Yosemite) and some significant UX issues. One marketing problem I have is that although it's better designed than the competition, in practice it's not quite as intuitive as it looks. I characterized a "revolt", but in reality there are two camps of users:

* People who come from traditional GIS, who love it (except for the bugs). These are the revolters.

* People who come from MapPoint, who think they're going to love it but find some things confusing and give up. These people were always discontented with the software at some level.

The frustration from the latter group stems a few unintuitive workflows in the software (e.g. how data gets imported and linked), some of which are due to design flaws in the data model IMHO. So although the software looks good in screenshots, and many people get a lot of value out of it, Magic Maps needs some work beyond basic bug-fixing to be a "5-star app" that pleases everyone.

This is a good point. However, in this particular case, the software has reached a size where it's more stressful than relaxing for me to think about. My sense is that this psychological function would be better served by a smaller project.

I like the idea, but it seems a bit risky and would require a lot of trust. I'd be open to this with someone I trusted, but I don't want someone to take the software as passive income and ride it down without fixing bugs etc.

Thanks for the advice. I've basically ignored it for the last couple of years, but with the Yosemite changes the bugs are reaching a breaking point. One of my concerns is that the bad reviews are starting to have a "negative halo" effect on my other app, so I'd like to take some kind of action on it.

In some sense I've been here before. My very first app was an iPhone app, actually one of the first police scanner apps, with a glowing map of Chicago that got me into the whole software-mapping thing. I had to put that one out to pasture a few years ago, even though I thought there could have been a viable little business in the right hands.

Thanks. To sell to a larger company I think I'd need to build a small company first with at least a handful of employees. I'm trying to step away from this code if I can to focus on another app, and generally large companies only want to buy software that come with personnel.

Looks interesting, I will take a look. Thanks for sharing.

Very cool. Let's talk over email. Home page is in my HN profile, email is on my home page.