Hillel

I'm prouder that my vim-brainfuck interpreter inspired this post than I am in the interpreter itself. And I was pretty damn proud of that interpreter!https://twitter.com/light_rook/status/1033468061964103680 …

Same with the solver backend; The slowest by an order of magnitude became, with an optimization, the fastest by an order of magnitude. I get the feeling a lot of it is dark magic unless I get very deep into the internals.

Constraint solvers are weird. I'm working on a MiniZinc project, first version took 3 minutes. With two optimizations it takes <1 second, but either optimization by itself it takes 5+ minutes. I've no idea how to find optimizations besides "try every combination of everything."

But I can find almost no online blogging about Minizinc (or or-tools, or optaplanner, or Picat...), so I'm guessing that outside of a few small niches, these tools are super obscure. Are they worth making more broadly known?

I've been learning Minizinc and I'm realizing that there were a few problems at my last couple of jobs that might have been appropriate to use constraint solving on. We rolled our own solutions, though, which worked okay for the most part.

If you've encountered a constraint problem at work (maximizing some value, making sure times don't overlap, etc) how did you solve it? Did you use an off-the-shelf constraint solver or write your own algorithm?

There is much more to the story, of course, and there's other factors besides the three I mentioned. And not just one factor explains everything; it's going to be a mix. But "programmers suck at marketing" is one I never see brought up, hence my tweetstorm.

I don't think better demos were available back when Smalltalk and Lisp were big deals. I think that failure of persuasion is one part of why these ideas never went mainstream.

The OT lists accomplishments like "homoiconic code" and "coroutines". Most demos on homoiconic code I've seen either apply it to toy problems, apply it to extremely niche problems I don't think I have, or don't really justify why I need macros, specifically, to solve the problem.

But it has to be a real problem, and it can't look contrived. People can tell when a demo is contrived and it makes them rightly suspicious. Most examples I see are contrived.

To take a personal example: I'm a big advocate of formal specification to solve complex design bugs. Usually the objections are something like: "I'm not making airplanes or NASA probes" "I don't need specs because I have TDD/Types/Agile/Haruspex"

Okay, so how DO we persuade people? I'm obviously no expert here, but here's what I THINK is important: For any solution X to problem P there are usually two forms of objection: "I don't have P" and "I don't need X when I have W/Y/Z".

Don't believe me? Here, read the following two pages and tell me how you feel about it makes you feel about lisp programmers: http://wiki.c2.com/?SmugLispWeenie  http://wiki.c2.com/?SocialProblemsOfLisp … (Clojure programmers are exempt from this exercise)

And some don't even bother finding common ground, and those people can irreparably sabotage the discourse. If you read something like "programming without X is MORALLY UNETHICAL" you're won't think "advocates for X are ethical". You'll think "advocates for X are smug assholes."

Persuading people is a skill! It's one a LOT of us are bad at. We often advocate for things we can't imagine working without... so we can't empathize with people who DO work without it and so struggle to find common ground.

No matter how good an idea is, people won't naturally accept it. You have to convince them, which is hard. Most people are skeptical of new ideas in programming, which I think is usually a good thing. For every idea like Quickcheck there are a dozen like Tonal Bitcoin.