3 ms·

Restrictive static typing creates a lot of problems that wouldn't exist... if you didn't use restrictive static typing. Maybe because my language designs are to

Restrictive static typing creates a lot of problems that wouldn't exist... if you didn't use restrictive static typing. Maybe because my language designs are toys I use in my projects (for now), but everything is nested heterogenous sparse sequences, so it's a list, but also a map, and I can attach any associative keys to it without breaking the pattern match on the rest of it, and I'm never out of place to add information should I need it. I think the problem is we write compilers like it's the 90s, and it's not the 90s. But also it's full of data structure solutions to this even for static types: give nodes a simple autoincrementing id (if your language has no object maps), then put any extra information in a sidecar if you want. Think relations and joins. It's easy.

Joker_vD 3y ago
Yes, and you can also just use parallel arrays of ints (or of constant-sized arrays of ints), because who needs structs with fields, really? #define NUM 0 #define BOOL 1 #define VAR 2 #define IF 3 #define LAM 4 #define APP 5 int nodes[MAX_NODES][4]; int next_node; int mkIf(int condExp, int thenExp, int elseExp) { assert((condExp < next_node) && (thenExp < next_node) && (elseExp < next_node)); nodes[next_node][0] = IF; nodes[next_node][1] = condExp; nodes[next_node][2] = thenExp; nodes[next_node][3] = elseExp; return next_node++; } Need additional data to stick to a node? Declare another array of MAX_NODES length and put it there! That's how Real Programmers wrote compilers in the seventies because real programmers write FORTRAN.
- 3cats-in-a-coat 3y ago
  I'm unsure what's the point of your satire. Sidecars are not just something people did in the 70s, it's a pervasive pattern seen in databases (there known as columnar storage), distributed services, gaming engines (like Entity Component System architectures) and so on. What are you even making fun of?
  - Joker_vD 3y ago
    That's not a satire. That's how people used to write code. Heck, I wrote a toy multi-pass compiler exactly like that in a B-like toy language that only had ints and arrays of (arrays of...) ints for data. But that's incredibly old-fashioned; I am making fun of your "we write compilers like it's the 90s, and it's not the 90s" because you propose the technique from the early 70s. It's not the 70s.
    - 3cats-in-a-coat 3y ago
      Well, if I must clarify my statement, my point was we sometimes write compilers like we're restricted by 90s limitations and understandings, and we aren't. I'm not rejecting something, simply because it was invented in the 90s, or 80s or 70s (or even before computers existed). Naturally, the way we run systems is as old as the world. We just have faster, smaller and more complicated systems now.

Joker_vD 3y ago

Yes, and you can also just use parallel arrays of ints (or of constant-sized arrays of ints), because who needs structs with fields, really? #define NUM 0 #define BOOL 1 #define VAR 2 #define IF 3 #define LAM 4 #define APP 5 int nodes[MAX_NODES][4]; int next_node; int mkIf(int condExp, int thenExp, int elseExp) { assert((condExp < next_node) && (thenExp < next_node) && (elseExp < next_node)); nodes[next_node][0] = IF; nodes[next_node][1] = condExp; nodes[next_node][2] = thenExp; nodes[next_node][3] = elseExp; return next_node++; } Need additional data to stick to a node? Declare another array of MAX_NODES length and put it there! That's how Real Programmers wrote compilers in the seventies because real programmers write FORTRAN.

3cats-in-a-coat 3y ago
I'm unsure what's the point of your satire. Sidecars are not just something people did in the 70s, it's a pervasive pattern seen in databases (there known as columnar storage), distributed services, gaming engines (like Entity Component System architectures) and so on. What are you even making fun of?
- Joker_vD 3y ago
  That's not a satire. That's how people used to write code. Heck, I wrote a toy multi-pass compiler exactly like that in a B-like toy language that only had ints and arrays of (arrays of...) ints for data. But that's incredibly old-fashioned; I am making fun of your "we write compilers like it's the 90s, and it's not the 90s" because you propose the technique from the early 70s. It's not the 70s.
  - 3cats-in-a-coat 3y ago
    Well, if I must clarify my statement, my point was we sometimes write compilers like we're restricted by 90s limitations and understandings, and we aren't. I'm not rejecting something, simply because it was invented in the 90s, or 80s or 70s (or even before computers existed). Naturally, the way we run systems is as old as the world. We just have faster, smaller and more complicated systems now.