5 ms·

I agree they are inherently complicated. The point here is you lose your usual tools available for full-blown programming languages (e.g. tests, type checks or

by rfoo 7y ago

I agree they are inherently complicated. The point here is you lose your usual tools available for full-blown programming languages (e.g. tests, type checks or other static analysis), which makes it harder to assess the conf, leads to more pain.

slifin 7y ago
It's shocking how little effort is put into developing static analysis compared to the insufferable amount of type system work that goes on Here we're discussing destroying a data format and replacing it with a programming language because we can't be bothered to do static analysis on a data format? LSP should have made this the golden era of static analysis, but instead everyone conflates type systems and static analysis so the industry gets myopic on typescript and friends If you took static analysis out of typescript I wouldn't even give typescript a second look, meanwhile something like this where a given key should be one of a set we don't even consider how to do that without a type system A data format doesn't have a type system and that's partly why they're great, type systems don't work across different programming languages but data does, data is a shared composable language Data as a concept is more important than a type system and static analysis is more important than a type system
- rfoo 7y ago
  Sorry, but I don't get how you express constraints you want your static analysis to enforce in stringly typed "data format" without out of the "format" type system e.g. JSON schema. Mind giving some hints? Static analysis is not magic, they need some more inputs other than your code. I can't say for sure but Rust's success told me at least some people are happy to write annotations specifically targeted at static analyzer (Lifetime etc).
- int_19h 7y ago
  Can you define "static analysis" here? It sounds like you're talking about data schemas otherwise, but if you apply them statically, the end result is a type system, no? (XSLT/XQuery would be one example of that)
yellowapple 7y ago
> e.g. tests, type checks or other static analysis You can do all these things for YAML or JSON or TOML or XML or INI or s-expressions or custom bytecode or butterflies or however else you're defining configuration data, too. It might not be present as part of the configuration language itself, but that's true of a lot of full-blown programming languages, too (especially the dynamic and weakly-typed ones). If anything, a static configuration file should be easier to statically verify than a full-blown programming language because it's, you know, actually static. This goes out the window somewhat with YAML or XML (which do somewhat funny things), but once you have that hash table or whatever you've deserialized the config data into, congrats, now you can statically analyze it.

by rfoo 7y ago

slifin 7y ago

It's shocking how little effort is put into developing static analysis compared to the insufferable amount of type system work that goes on Here we're discussing destroying a data format and replacing it with a programming language because we can't be bothered to do static analysis on a data format? LSP should have made this the golden era of static analysis, but instead everyone conflates type systems and static analysis so the industry gets myopic on typescript and friends If you took static analysis out of typescript I wouldn't even give typescript a second look, meanwhile something like this where a given key should be one of a set we don't even consider how to do that without a type system A data format doesn't have a type system and that's partly why they're great, type systems don't work across different programming languages but data does, data is a shared composable language Data as a concept is more important than a type system and static analysis is more important than a type system

rfoo 7y ago
Sorry, but I don't get how you express constraints you want your static analysis to enforce in stringly typed "data format" without out of the "format" type system e.g. JSON schema. Mind giving some hints? Static analysis is not magic, they need some more inputs other than your code. I can't say for sure but Rust's success told me at least some people are happy to write annotations specifically targeted at static analyzer (Lifetime etc).
int_19h 7y ago
Can you define "static analysis" here? It sounds like you're talking about data schemas otherwise, but if you apply them statically, the end result is a type system, no? (XSLT/XQuery would be one example of that)

yellowapple 7y ago

> e.g. tests, type checks or other static analysis You can do all these things for YAML or JSON or TOML or XML or INI or s-expressions or custom bytecode or butterflies or however else you're defining configuration data, too. It might not be present as part of the configuration language itself, but that's true of a lot of full-blown programming languages, too (especially the dynamic and weakly-typed ones). If anything, a static configuration file should be easier to statically verify than a full-blown programming language because it's, you know, actually static. This goes out the window somewhat with YAML or XML (which do somewhat funny things), but once you have that hash table or whatever you've deserialized the config data into, congrats, now you can statically analyze it.