EvanMiller

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.

Thanks for the suggestion. The code is somewhat complex, though I've tried to isolate the really hairy parts in separate libraries (e.g. OpenCL code). I'm really not sure what the ramp-up time would be, and whether it'd be too much. Where would you look for a Mac freelancer?

For the record the Yosemite issues are the most glaring ones, but there are deeper crashes and bugs (think "mysterious Core Data error") that have eluded me.

You're right, it's a fair amount of money, and I'm lucky to have this problem. Right now I'm doing everything I can to focus on another app. I'm trying to give that app 100% of my time and attention, even if I could be making more money in the short term doing something else.

I personally find it difficult to work on multiple large software projects at the same time. There's just so much I can keep in my head at once. If it were a few thousand lines of code, maybe, but Magic Maps weighs in around 35 kLoC, and the other one is pushing 100 kLoC. It takes a fair amount of mental bandwidth to dig into deep bugs, and I'd like to save that bandwidth for my other app.

Thanks. The only Mac-only competition I know of is Cartographica, which is $500 vs $40 for Magic Maps.

It's mostly Objective-C. The core map-projection library is C and OpenCL, which I had a lot of fun with! I open-sourced that library (ProjCL) a while back: https://github.com/evanmiller/ProjCL

For some context, ArrayFire is a product of AccelerEyes, which began life selling a GPU booster for Matlab (a product called Jacket).

This and today's .NET announcement shows how hard it is to sell proprietary developer tools. I had considered using ArrayFire for some of my own commercial work, but in the end decided to roll my own OpenCL code in order to have better control. If you require cutting-edge performance (which is the reason you'd consider ArrayFire in the first place), there's just too much risk involved if the vendor doesn't get details like memory access order right on complex matrix problems. Open-sourcing reduces that risk quite a bit; if this decision had been made 3 years ago, I would have given the product a closer look.

From a business perspective, open-sourcing will murder their margins so they're basically gambling on their ability to jump-start volume. I think the product is in a tough position because most of the action these is going towards "Big Data," where data doesn't fit on a single machine -- let alone a GPU -- or towards heavy number-crunching, where hand-rolled kernels will outperform generic array libraries. They might have luck serving as a kind of backend to NumPy, but then they're two steps removed from the customer so it'll be hard building a relationship that leads to a sale.

As a side note, it seems odd to me that "native CPU" is a target distinct from OpenCL, which already runs on both CPUs and GPUs. I understand that kernels written for GPUs sometimes need to be rewritten for CPUs to take advantage of the different computation and memory architecture, but since their native CPU target isn't vectorized or multi-threaded, it seems like any further effort should be spent adapting the OpenCL kernels for CPU platforms rather than reinventing the wheel with a distinct C or assembler target.

I admire the general goal of making GPU processing more accessible, but it's a problem with a lot of nuance and requires a significant amount of customer education. GPUs are sort of like quantum computers in the limited sense that they're totally awesome at some tasks and totally suck at other tasks, and you need a solid grounding in the theory to distinguish the two sets of cases. Open-sourcing should at least help with the education angle, since ArrayFire now represents a respectable percentage of publicly viewable OpenCL code. (The open-source scene for OpenCL is pretty depressing right now.) In any case, good luck out there.

Why You Don't Want To Use The Panini Presses in the Downstairs Cafeteria (bothsidesofthesandwich.com)

We all know the downstairs cafeteria is changing fast. Others have discussed the new panini presses and greater variety of pizza recently added to the cafeteria menu. Most of these developments have benefited diners, although I've previously written about the darker side of things in these blog posts:

* Why I Don't Love Meat-Lovers Pizza

* Ham Is A Sandwich Best Served Cold

Now, you might think that the panini presses to the downstairs cafeteria are an unmitigated good. They only increases the number of things you're able to eat, right? Hot sandwiches in addition to cold?

Wrong.

Let me give you an example from just last week.

I was at the panini machine heating up the Mark Suster Special -- an culinary invention whose ingredients, until recently, were known only to myself -- when a classmate of mine asked if he could put his sandwich into the machine at the same time. Normally I don't let other people use the panini machine at the same time as me, since it takes longer to heat the sandwiches with two in there instead of just one. But sometimes, their sandwich ingredients will infuse the Mark Suster Special with extra aromatic zest, so this time I agreed.

The sandwich turned out fine. Or so I thought at first. What I didn't know was that this individual -- who I will not name, but who sits in the front row of Mr. Boyd's 3rd period English class and the last row of Mr. Lowry's 7th period chemistry class -- would later go around claiming that he invented the Mark Suster Special and its near-perfect ratio of meat to cheese. In fact he divulged this ratio to everyone sitting in the second row of Mr. Vining's 4th period algebra class.

When I found out about this, I was flabbergasted. This classmate was trying to get all his friends to try out a sandwich that wasn't really his -- a clear violation of my intellunchual property rights. I only found out about it because this unnamed individual was bragging about the sandwich while sitting in the second row of Mrs. Roth's 2nd period history class, just to the left of my friend Ken.

I don't know how this will play out, but I've already filed a complaint with the appropriate authorities. The only reason I tell you this story is that it's becoming more and more clear to me that you can get "burned" by panini presses in more ways than one. If you absolutely must use the panini press, it's best to wrap your sandwich in tin foil first, lest unnamed individuals -- who are co-captain of the JV lacrosse team -- try to claim your sandwich idea as their own.

These days, it seems the thieves aren't just in the second-floor study area. They're in the downstairs cafeteria as well.

For anyone in the Chicago area, Leah Hanson is giving a free Julia workshop next weekend (11/15):

http://www.meetup.com/JuliaChicago/events/216950712/

Should be a great way to get introduced to the language and pose your nagging questions to a community expert.

The vision here is noble, and I applaud what Chris has done with Light Table, but based on the discussion here, I think the Eve team is setting themselves up for disappointment.

1. By bringing investors on board, and promising Hacker News they're going to change the world, they're basically asking to be stressed out all the time. This is not conducive to innovation.

2. There's a fundamental tension between creating something usable by Joe in accounting and something that is cutting-edge from a technical perspective (highly concurrent etc). 90% of line-of-business programs use less than 10% of CPU, and approximately 0% need high concurrency. Joe in accounting is not going to build the next WhatsApp, and every moment you spend figuring out multi-core whatever, you're not thinking about how to help Joe make his Cash Flow Prediction Tool look slick.

3. From a marketing perspective, creating a new category of software is an enormously difficult undertaking. There are two related problems here:

A. You have to find potential customers. Because nothing like Eve exists, the market does not exist. I.e. the world's "creators" don't all go to the same conferences, visit the same websites, and hang out in the same IRC channels. Light Table at least was addressing an existing market, i.e. "programmers who use X/Y/Z", so you could actually find customers, and they could tell their programmer friends about it.

B. After you find potential customers, you have to educate them, i.e. explain the potential benefits and teach them how to use the darn thing. This requires a major investment from both you and from your interested customers. It is much, much easier to sell something that relieves the customer's pain than something that promises him "superpowers". 95% of "creators" have only vague and incorrect notions about programming, so you'll have a hell of a time explaining the product. Let's say you want to target Joe in accounting: What will the advertisement actually say? "Do you miss VB6?"

4. The fact that the LT team is giving up on Light Table when it's still the proverbial "couple of guys" is not a good sign. From a marketing perspective, Light Table had every advantage in the world: tons of publicity / viral videos, a clearly defined market, and an exciting product that got people talking. The fact that they're throwing in the towel tells me, well, they quit too early, and they'll quit on Eve when the going gets tough.

To be more specific, I think Chris's fears about the market for Light Table are totally unfounded. To wit:

* "The competition has millions of man-hours invested". Who cares? On a day-to-day basis I execute maybe 3% of the code paths in my editor. In my view, Light Table is a classic opportunity to offer 10% of the functionality of the bloated competition but really knock that 10% out of the park. Look at e.g. Pixelmator versus Photoshop or [toot toot] Wizard versus SPSS.

* "Programmers don't pay for software". I'm sorry, but this is a poor excuse, and if I were your drill sergeant, and this were an 80s movie, I'd be screaming in your face right now. Programmers are a wealthy and growing segment. They'll pay for stuff if it helps them get their job done (GitHub, TextMate, books, conferences, heck Visual Studio). Not only that, with the product's positioning, you have a great opportunity to sell to people who want to be programmers, the "ski pants" market, if you will. If you read the comments in this thread, you'll notice that your users are complaining about the Light Table's lack of polish and they clearly recognize the need to pay someone to provide that polish.

In sum, I think the LT team should have worked themselves into a crying, bleeding, starving mess to make Light Table a commercial success, and then pursued bigger ideas once they had the business experience under their belt. Even if it took a few years, they'd be in a much better position both financially and psychologically to tackle a Grand New World-Changing Product once they had the routine down from their Small Life-Changing Editor.

As an indie-app-developer-whatever myself, I would kill for the kind of publicity and market opportunity that Light Table had. I wish Chris & Co. all the best with Eve, and I truly hope they succeed. But based on what I'm reading, I don't think they don't deserve to.

This looks like a nice product. Software companies have been struggling to make a mass-market database program ever since Lotus 1-2-3 (the "3" was a database), but the spreadsheet remains king, despite the fact that for storing structured data, it is almost as bad as a Word document with macros. So I'll be rooting for you.

One complaint: Referring to your Basic plan as being "Free forever" is a bit disingenuous. In my opinion, the FTC ought to prohibit use of this term by tech companies located in the 650 and 415 area codes.

It makes me sad whenever I hear about indie developers feeling oppressed by customer support, which ought to be source of ideas for improving the product rather than a drag on development. In my mind that's actually what sets indie products apart from the others in a crowded marketplace -- customers have a direct line to the developer, and get nearly instantaneous fixes to their problems.

My basic strategy for reducing the cost of customer support -- and making it a source of valuable information to my business -- is to 1) choose a price point so that potential customers will actually read the app description before buying 2) LISTEN to paying customers and fix common issues they're complaining about 3) constantly obsess over product quality, sometimes at the expense of new features.

Right now I spend about an hour per day doing support, and instead of feeling oppressed, I rather enjoy the process of building relationships with customers, even if they initially emailed me out of frustration about something.

As for the other issue -- having time to be a husband and father and all that -- I don't think there's an easy answer. I was only able to get my apps off the ground financially because I was in a situation where I had nearly unlimited free time. It's only been recently that I could even consider taking on other major commitments.

I met David at JuliaCon a couple weeks ago -- he's a physics professor at the National University of Mexico and a charming interlocutor. I haven't made it through this (4-hour) tutorial myself, but the word among the core developers on the Julia mailing list is that it is very, very good.

As others have posted, the 3-hour second part is here: http://pyvideo.org/video/2753/introduction-to-julia-part-2