Carol Tuttle's Energy Types relate to ReasonML

There's a pretty good chance you're a type 2

There's a pretty good chance many of your co-workers, especially those you need to convince, are type 3.

Type 3 is about getting sh*t done. Period. You may say, "But I like to get stuff done too!" Yes you do, but not like type 3's. The difference between you and them is your primary goal. Type 2's get stuff done by assessing the options, asking lots of questions, figuring out the best strategy, and once comfortable, start doing it.

Type 3's start the task, ask questions later, stop when it's done. Move on to the next TODO. If they run into problems they find the quickest solution and take it, move on to the next task.

They use JavaScript because it doesn't get in their way very much. They can quickly understand the language and get productive, which is what they are all about. They don't read docs, they don't ask questions, they copy and paste example code and modify it to do what they want, they leave that code and never take another thought. They are all about upward and forward movement.

Many of these tendencies would irk you as a type 2 personality. You may find things like using float in css when flex box is obviously better. Don't they know or care? NOPE, they do not, because float gets the job done, they won't be too interested until they try to align something vertically, then they'll do a google search, find that someone said that flex box can do it, they will copy and paste the code, then do it.

Another example is they'll probably use Class components for everything. Why? Because it's easier, and works for everything. They have to know 1 thing to accomplish everything they need to know.

Type 3's don't like to spend lots of time learning and assessing options. That's not "getting things done". Learning often slows down a task. If you have to learn something to do it, that's time wasted.

Selling to a Type 3 person

The only way you're going to sell to a Type 3 person is difficult. The main problem you're going to run into is that they don't usually care very much about doing things best way. They care about the clearest path to success. Usually the quickest path to success is not looking, discovering, learning, then applying a tool. It's applying a tool you already have in your repertoire.

HARD FACT: Doing something in JavaScript is often faster than ReasonML, especially if you don't know ReasonML.

If you're a type 2 you probably have a much higher tolerance for reading a learning about things than a type 3 does. Which is fine on both sides.

So How do we sell?

Step 1: We have to make Reason the most productive language!.

well isn't it already?. In my opinion: "Kinda".

What's really productive in ReasonML:

  1. Changing a type, seeing everywhere it breaks
  2. Refactoring! This is really easy in ReasonML. So long as the compiler errors make sense.
  3. Compilation times! Love to see the browser refresh sooooo fast. This is a huge thing to talk about and we should all be very proud of this.
  4. Bundle size reduction. Having to take a day or two to trim down bundle size is work nobody wants to do, what if by using this language you would just naturally get small bundles? This could be huge. JavaScript really doesn't do well with this and never really will. Nor will TypeScript.
  5. No Imports! This takes a bit to get used to, and can lead to some confusion initially, but with some good tooling this could be a huge strength.
  6. Less bugs in production!
  7. Expressing things via types like Author(id) | Commenter(id, email) | Guest

What will probably always be harder in ReasonML:

  1. Functions can't take different type of arguments this means that in React you have to do this, when you didn't previously. This is an OCaml design choice, although maybe will change in the future.
<div>
"asdf"->ReasonReact.string
2->string_of_int->ReasonReact.string
</div>
  1. Understanding Types scope when you can write type annotations, when you don't need them can be tricky. Typed languages are a skill, they aren't going to be something people can pick up without trying like JS.

What could make ReasonML more productive (given some work)?

  1. Editor Tooling!!! This is HUGE for a type 3 person, if ReasonML means 2. If you type <div you should immediately get all the properties that a div could have. Better yet, if you type <Route you should immediately get all the properties that that component could take. 1. If there's required arguments <Route should quickly expand into <Route to="string" render={} /> or something like that. 3. If you type foo( you should see the signature of the function floating there, *even if it's an opened module function 4. cmd-clicking a function should always take to the right place
  2. Type and Syntax errors should always point you to the problem with a quick and convince description. This is not true right now. But it could be!
  3. Writing Mobile/Desktop native apps. Right now the tooling for JS native apps is very lacking. This is something ReasonML could really succeed at.
  4. Debugging runtime exceptions.
    1. You may say "the code is soooo readable" It's not. Especially if you're writing a React component. I can read it OK but I'm familiar with Reason.
    2. Because the JS is generated and doesn't look much like JS, it's hard to debug these kinds of things. We need source maps and easy way to JS.log something with the proper types in ReasonML's terms. Yes this is possible but it needs to be easier.

Step 2: Just use it.

This is how pragmatist do things. They just start. They make something useful. If they run into problems, they solve them. If they run into problems a lot, they make libraries. Rinse and repeat.

reasonconf2019 reason Carol Tuttle's Energy Types