One of my goals for #mollytime is to avoid introducing a concept of errors into the language.

[aeva@mastodon.gamedev.place]

One of my goals for #mollytime is to avoid introducing a concept of errors into the language. Every patch that is possible to construct (so far) is a valid patch. Mollytime will not let you construct an invalid patch and then tell you to go fucking fix it.

So far this has worked out great, and I have no regrets.

[aeva@mastodon.gamedev.place]

This is wonderful affordance is made possible by having control over the editor environment and not making it a text based language.

I was thinking about this earlier when a typo in C++ resulted in a valid program that did not do what I wanted, where I wrote:

double Fnord = ReturnsDoubleRef();

instead of

double& Fnord = ReturnsDoubleRef();

and how in a sense this is a similar property (though C++ doesn't strive to be error free), and how in this case it is not a positive quality

[aeva@mastodon.gamedev.place]

anyways that got me wondering if the worth of a strongly typed language is that it is simply hard to write a valid program on accident, and nothing else

[lritter@mastodon.gamedev.place]

@aeva hehe.

LRDL has strong types but also relational inference. you can leave out types for the most part and it figures it out. that makes it much easier to write a valid program by accident.

it's the bureaucracy that murders flow. making you restate information that is obvious. good as a guard, but not every door inside a home needs a padlock. the C(++) folks eventually gave in and added auto. not that it would ever be enough.

[oblomov@sociale.network]

@lritter @aeva

Bureaucracy is friction and in the right measure it's actually good. The hard part is finding the right measure, or at least the right tooling to account for it (e.g. rather than making it possible to skip declaring types, make the inference logic available to editors who can thus reduce the user effort to fill in the stuff)

[glyph@mastodon.social]

@aeva have you ever seen ProGraph

[rygorous@mastodon.gamedev.place]

@aeva certainly my experience - in essence, the function of most types of compile-time checking is to intentionally increase the minimum Hamming distance in the set of inputs the compiler accepts

[aeva@mastodon.gamedev.place]

@lritter I do like C++ for being something that strikes an ok-ish balance between making me stop and think, and letting me iterate quickly.

[lritter@mastodon.gamedev.place]

@aeva i do like C++ for allowing me to write LRDL in it. (which acts as a DSL for C++)

[lesley@mastodon.gamedev.place]

@aeva To paraphrase one of my favorite professor: "there is a tradeoff between how many correct programs you exclude, and how many incorrect programs you can exclude"

[aeva@mastodon.gamedev.place]

@glyph no. what is it?

[camwin@infosec.exchange]

@aeva I think one of the benefits is that declarations are more self documented. In statically typed languages, I can go read a function signature or variable declaration and know all the information about it. I don’t need to go read the return statement of a function to know what type a variable will have. I don’t need to research what arguments are valid for a function, it just says it in the prototype.

[aeva@mastodon.gamedev.place]

@Camwin oh yeah totally like, this is super obvious:

float Fnord(float A, float B, float C, float& D, void*** E, int F);

[darkyen@mastodon.gamedev.place]

@aeva @Camwin If this seems obtuse, wait until you encounter this monstrosity in a language without upfront types. The type constraints will still be there, but implicit, maybe poorly documented or hidden in asserts. No thanks 🙃