Awesome that you're responding to feedback like this!
Another suggestion around `let`: consider splitting it into two operations, for creating a new column and for modifying an existing one. E.g. called `let` and `set`. Those are in effect pretty different operations: you need to know which one is happening to know how many columns the table will have, and renaming a table column can with your current system change which operation is happening.
Splitting them into separate operations would make things easier on the reader: they can tell what's happening without having to know all the column names of the table. And it shouldn't really be harder for the writer, who ought to already know which they're doing.
I encountered something like this at my previous job. We had a DSL with an operation that could either create or modify a value. This made the code harder to read, because you had to have extra state in your head to know what the code was doing. When I rewrote the DSL (the rewrite was sorely needed for other reasons), I split the operation in two. I was worried people would have been too used to the old language, but in practice everyone was happy with it.
> Another suggestion around `let`: consider splitting it into two operations, for creating a new column and for modifying an existing one. E.g. called `let` and `set`.
Couldn’t we just not allow modifying an existing column? Ie. we would not allow
count = count + 1
But force the use of a new variable name:
new_count = count + 1
I think this makes for much more readable code, since the value of a variable does not depend on line number.
Awesome that you're responding to feedback like this!
Another suggestion around `let`: consider splitting it into two operations, for creating a new column and for modifying an existing one. E.g. called `let` and `set`. Those are in effect pretty different operations: you need to know which one is happening to know how many columns the table will have, and renaming a table column can with your current system change which operation is happening.
Splitting them into separate operations would make things easier on the reader: they can tell what's happening without having to know all the column names of the table. And it shouldn't really be harder for the writer, who ought to already know which they're doing.
I encountered something like this at my previous job. We had a DSL with an operation that could either create or modify a value. This made the code harder to read, because you had to have extra state in your head to know what the code was doing. When I rewrote the DSL (the rewrite was sorely needed for other reasons), I split the operation in two. I was worried people would have been too used to the old language, but in practice everyone was happy with it.
Yes this is a good idea. dplyr has something similar with `mutate` & `transmute`.
This could _mostly_ be enforced by PRQL. There's a case where we transpile to:
...where we don't know whether or not we're overwriting an existing column. But it's a minority of cases, and the contract could stand within PRQL.
I opened an issue here: https://github.com/max-sixty/prql/issues/6
> Another suggestion around `let`: consider splitting it into two operations, for creating a new column and for modifying an existing one. E.g. called `let` and `set`.
Couldn’t we just not allow modifying an existing column? Ie. we would not allow
But force the use of a new variable name:
I think this makes for much more readable code, since the value of a variable does not depend on line number.