One of my goals for #mollytime is to avoid introducing a concept of errors into the language.
-
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.
-
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.
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
-
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
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
-
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
@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.
-
undefined oblomov@sociale.network shared this topic
-
@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.
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)
-
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
@aeva have you ever seen ProGraph
-
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
@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 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.
@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 I do like C++ for being something that strikes an ok-ish balance between making me stop and think, and letting me iterate quickly.
@aeva i do like C++ for allowing me to write LRDL in it. (which acts as a DSL for C++)
-
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
@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 have you ever seen ProGraph
@glyph no. what is it?
-
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
@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 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.
@Camwin oh yeah totally like, this is super obvious:
float Fnord(float A, float B, float C, float& D, void*** E, int F);