5 ms·

This seems neat. I love that there are examples front-and-center on the README page. This is exactly what I want and the first thing I would think to put when d

This seems neat. I love that there are examples front-and-center on the README page. This is exactly what I want and the first thing I would think to put when demonstrating a new language, but sadly this is rare. I'm not sure how I'd use something like this, but I've often found myself wanting simple statically typed scripting languages for generating YAML/HCL/etc configs. Dhall seems close, but config is something that every engineer has to touch and the burden of making everyone learn its syntax and functional programming idioms probably negates the advantages of using static typing. I've also looked into CUE, but it seems like it's largely neglecting the problem that I'm trying to solve DRY configs in favor of some problem I didn't know I had (unifying a bunch of layers of mostly-static configs?). This seems even worse than Dhall with respect to burden:reward ratio. I haven't yet checked out Nickel (the statically typed Nix language)--would be curious to hear from those who have. EDIT: just skimmed Nickel. It seems like it's trying to hew closely to Nix syntax and functional programming conventions, which suggests it probably shares many of the same problems as Dhall. Too bad. It seems like no one understands the assignment.

lakecresva 5y ago
The functional stuff in Nickel is really pretty vanilla, and the syntax seems much more inspired by ML than Nix. There's some info in the repo's `RATIONALE.md` that specifically answers "how is this different/better than Dhall/JSonnet/Cue/Starlark".
kazinator 5y ago
> I'm not sure how I'd use something like this. It seems that you could use this to program embedded systems that have a shell, yet which don't support any other usable language (due to flash space concerns, product management approval or whatever).
sdevonoes 5y ago
What I miss in the README page is the output of the transpilation.
- JyB 5y ago
  I guess the output is not really meant to be readable in any way
  - em-bee 5y ago
    if it transpiles to sh then the output should be an sh script. that should be at least somewhat readable.
    - xyzzy123 5y ago
      Yes although it might be readable in the same way that autotools configure scripts are readable -- technically you can, but you probably don't want to, and if you need to then something has gone badly wrong.
      - em-bee 5y ago
        yeah, that's kind of what i meant. especially if the script has external commands you should be able to at least recognize something.
        deleted 5y ago
        [deleted]
      - xg15 5y ago
        I mean yes. Things do go wrong, especially with bleeding-edge projects such as this. You'll have to look at that output if you want to debug things, understand error messages. As such, I'd absolutely see it as a quality measure for a transpiler how readable the code it produces is.
    - hnlmorg 5y ago
      I think you can liken this to web assembly. The output might be text but it’s not intended to be human readable.
    - ketralnis 5y ago
em-bee 5y ago
I love that there are examples front-and-center on the README page except that those examples are to simple. for something that transpiles to sh i would like to use it to write better shell scripts. so i'd like to see examples that resemble actual shell scripts in that they call lots of external commands, do file operations, terminal interaction and other things commonly done with sh.
- smoe 5y ago
  Felt the same. Most complete example seems to be the installer for the language which is written in it. This covers some of the things you mentioned https://github.com/cotowali/konryu/blob/main/konryu.li https://github.com/cotowali/konryu/blob/main/konryu.li and the generated shell script https://raw.githubusercontent.com/cotowali/konryu/dist/konryu.sh https://raw.githubusercontent.com/cotowali/konryu/dist/konry... There is also the website, heavily under construction, but has some more documentation on the language than the readme https://cotowali.org/ https://cotowali.org/
  - remram 5y ago
    So this 366-line script compiles into 588 lines of shell, 2,229 lines if we count the parts that seem to come from the imported modules. That includes a lot of auto-generated names like `_cotowali_tmp_166` or `first8b04d5e3775d298e78455efc5ca404d5` and replacements for built-in shell functions like `eprintln` or `rm_r`. In fact that script seems to use `eprint`, `eprintln`, `println`, `print`, AND `echo` which seems a little much. It would have been nice to see something more transparent, e.g. a type-checked extension to shell, like TypeScript is for JavaScript. Something to make it easier to write correct shell scripts, but would generate understandable, editable shell scripts.
Willamin 5y ago
> simple statically typed scripting languages for generating YAML/HCL/etc configs Do you actually want a statically typed _imperative_ language for generating configs? Or do you want a sane, statically typed, declarative language for configs?
- throwaway894345 5y ago
  I haven’t seen a sane declarative language. I’m pretty sure what I want is an imperative language, especially since that’s already well-understood by the target audience. I’m open to persuasion, but I gave Cue an honest shot but it seemed to regard reuse as an afterthought at best rather than the main problem to solve (I think reuse was possible, but it wasn’t obvious and it seemed like it was only supported by accident).
kirbyfan64sos 5y ago
You might find Cue interesting: https://cuelang.org/ https://cuelang.org/ It's a bit overambitious IMO, but it tries taking a relatively different approach to the problem that I find to be quite interesting.
- sidpatil 5y ago
  Parent already mentioned their investigation of CUE.
mixedCase 5y ago
Alright, here's the hot take: The assignment is for any developer without basic knowledge of FP beyond .map and .filter to complete their intermediate-level programming education. All problem domains that involve declarative programming, such as configuration (Terraform, Kubernetes, Nix, many build systems), dynamic HTML, relational databases, and pretty much anything that is manipulating data in a pipeline fits functional programming like a glove and is hard to get right in a strictly traditionally imperative fashion. As an industry we should stop pretending FP isn't a necessary part of a professional programmer's education and that we can solve the problem by coming up with the umpteenth "we promise it's not FP" abstraction with its own take on fooling developers into writing functional code through an imperative-looking layer full of foot guns that subtly break imperative developer expectations, like React.
- verall 5y ago
  I think it's a super hot take because the real world has demonstrated (over and over again) that a huge portion of professional software developers have no interest in learning functional paradigms just to write some config files. Just like a huge portion of professional software developers have no interest in learning RTL or digital logic just to program an FPGA. HLS is a massively complex system to solve this problem. People will also build massively complex systems to solve the problem of "No FP here, please".
  - klekticist 5y ago
    I agree with your point here, though imo it's worth drawing a distinction between the FP concepts the language designers / implementors must understand and the FP concepts the language users must understand. Ideally languages prevent bug classes like null deref, use after free while still being familiar enough for most programmers to use. It's analogous to the spectrum of SQL knowledge folks have. For instance knowing what a group by does vs how a group by reshuffles data on a single node / across nodes. Ideally the language design hides the hard details. A very tall order admittedly.
  - mixedCase 5y ago
    That'd be fine if it was just config files, but that's not the problem now isn't it?. It's an enormous amount of problem domains that FP handles trivially and is a complete pain to manage imperatively. We've had entire groups of people coming up with ridiculous ideas like replacing relational databases with key-value stores for relational data just because they find SQL "icky" because it fits a mental model they never developed (syntax issues with SQL aside) and it isn't until they're hand rolling data aggregation that they realize the mess they got themselves into. Which is why I stand by what I said: this knowledge is not optional, and engineers not willing to learn them are going to be stuck with sub-optimal tools, dragging the whole industry down with them. While I can't be confident this is the definitive solution, I believe that the best way to move forward is to start treating basic FP (purity, data transformation pipelines, immutability, favoring data structures over code) as a baseline that everyone needs to know to work as a developer, and stop treating it as if it is on a superior level of difficulty compared to learning whatever bullshit combination of half-templated server side rendering, 4D DOMs and incantations needed to upgrade Webpack we need to know to be "up to speed" nowadays.
soraminazuki 5y ago
> making everyone learn its syntax and functional programming idioms probably negates the advantages of using static typing I think this is an over-exaggeration of the complexity involved because Dhall/Nickel/Nix are just JSON with variables and functions. If you're familiar with JSON and any general purpose programming language, say Python, you can learn the aforementioned languages in less than an hour. > Too bad. It seems like no one understands the assignment. You mean all those language designers for static configuration languages have no idea what they're doing? I think there's a better explanation. For complex configurations that warrant the kind of high level configuration languages we're talking about, declarative syntax seems to a better fit. Tracking mutation and state for large scale configuration would put the burden on everyone, beginners and experts alike.

lakecresva 5y ago

The functional stuff in Nickel is really pretty vanilla, and the syntax seems much more inspired by ML than Nix. There's some info in the repo's `RATIONALE.md` that specifically answers "how is this different/better than Dhall/JSonnet/Cue/Starlark".

kazinator 5y ago

> I'm not sure how I'd use something like this. It seems that you could use this to program embedded systems that have a shell, yet which don't support any other usable language (due to flash space concerns, product management approval or whatever).

sdevonoes 5y ago

What I miss in the README page is the output of the transpilation.

JyB 5y ago
I guess the output is not really meant to be readable in any way
- em-bee 5y ago
  if it transpiles to sh then the output should be an sh script. that should be at least somewhat readable.
  - xyzzy123 5y ago
    Yes although it might be readable in the same way that autotools configure scripts are readable -- technically you can, but you probably don't want to, and if you need to then something has gone badly wrong.
    - em-bee 5y ago
      yeah, that's kind of what i meant. especially if the script has external commands you should be able to at least recognize something.
      - deleted 5y ago
        [deleted]
    - xg15 5y ago
      I mean yes. Things do go wrong, especially with bleeding-edge projects such as this. You'll have to look at that output if you want to debug things, understand error messages. As such, I'd absolutely see it as a quality measure for a transpiler how readable the code it produces is.
  - hnlmorg 5y ago
    I think you can liken this to web assembly. The output might be text but it’s not intended to be human readable.
  - ketralnis 5y ago

em-bee 5y ago

I love that there are examples front-and-center on the README page except that those examples are to simple. for something that transpiles to sh i would like to use it to write better shell scripts. so i'd like to see examples that resemble actual shell scripts in that they call lots of external commands, do file operations, terminal interaction and other things commonly done with sh.

smoe 5y ago
Felt the same. Most complete example seems to be the installer for the language which is written in it. This covers some of the things you mentioned https://github.com/cotowali/konryu/blob/main/konryu.li https://github.com/cotowali/konryu/blob/main/konryu.li and the generated shell script https://raw.githubusercontent.com/cotowali/konryu/dist/konryu.sh https://raw.githubusercontent.com/cotowali/konryu/dist/konry... There is also the website, heavily under construction, but has some more documentation on the language than the readme https://cotowali.org/ https://cotowali.org/
- remram 5y ago
  So this 366-line script compiles into 588 lines of shell, 2,229 lines if we count the parts that seem to come from the imported modules. That includes a lot of auto-generated names like `_cotowali_tmp_166` or `first8b04d5e3775d298e78455efc5ca404d5` and replacements for built-in shell functions like `eprintln` or `rm_r`. In fact that script seems to use `eprint`, `eprintln`, `println`, `print`, AND `echo` which seems a little much. It would have been nice to see something more transparent, e.g. a type-checked extension to shell, like TypeScript is for JavaScript. Something to make it easier to write correct shell scripts, but would generate understandable, editable shell scripts.

Willamin 5y ago

> simple statically typed scripting languages for generating YAML/HCL/etc configs Do you actually want a statically typed _imperative_ language for generating configs? Or do you want a sane, statically typed, declarative language for configs?

throwaway894345 5y ago
I haven’t seen a sane declarative language. I’m pretty sure what I want is an imperative language, especially since that’s already well-understood by the target audience. I’m open to persuasion, but I gave Cue an honest shot but it seemed to regard reuse as an afterthought at best rather than the main problem to solve (I think reuse was possible, but it wasn’t obvious and it seemed like it was only supported by accident).

kirbyfan64sos 5y ago

You might find Cue interesting: https://cuelang.org/ https://cuelang.org/ It's a bit overambitious IMO, but it tries taking a relatively different approach to the problem that I find to be quite interesting.

sidpatil 5y ago
Parent already mentioned their investigation of CUE.

mixedCase 5y ago

Alright, here's the hot take: The assignment is for any developer without basic knowledge of FP beyond .map and .filter to complete their intermediate-level programming education. All problem domains that involve declarative programming, such as configuration (Terraform, Kubernetes, Nix, many build systems), dynamic HTML, relational databases, and pretty much anything that is manipulating data in a pipeline fits functional programming like a glove and is hard to get right in a strictly traditionally imperative fashion. As an industry we should stop pretending FP isn't a necessary part of a professional programmer's education and that we can solve the problem by coming up with the umpteenth "we promise it's not FP" abstraction with its own take on fooling developers into writing functional code through an imperative-looking layer full of foot guns that subtly break imperative developer expectations, like React.

verall 5y ago
I think it's a super hot take because the real world has demonstrated (over and over again) that a huge portion of professional software developers have no interest in learning functional paradigms just to write some config files. Just like a huge portion of professional software developers have no interest in learning RTL or digital logic just to program an FPGA. HLS is a massively complex system to solve this problem. People will also build massively complex systems to solve the problem of "No FP here, please".
- klekticist 5y ago
  I agree with your point here, though imo it's worth drawing a distinction between the FP concepts the language designers / implementors must understand and the FP concepts the language users must understand. Ideally languages prevent bug classes like null deref, use after free while still being familiar enough for most programmers to use. It's analogous to the spectrum of SQL knowledge folks have. For instance knowing what a group by does vs how a group by reshuffles data on a single node / across nodes. Ideally the language design hides the hard details. A very tall order admittedly.
- mixedCase 5y ago
  That'd be fine if it was just config files, but that's not the problem now isn't it?. It's an enormous amount of problem domains that FP handles trivially and is a complete pain to manage imperatively. We've had entire groups of people coming up with ridiculous ideas like replacing relational databases with key-value stores for relational data just because they find SQL "icky" because it fits a mental model they never developed (syntax issues with SQL aside) and it isn't until they're hand rolling data aggregation that they realize the mess they got themselves into. Which is why I stand by what I said: this knowledge is not optional, and engineers not willing to learn them are going to be stuck with sub-optimal tools, dragging the whole industry down with them. While I can't be confident this is the definitive solution, I believe that the best way to move forward is to start treating basic FP (purity, data transformation pipelines, immutability, favoring data structures over code) as a baseline that everyone needs to know to work as a developer, and stop treating it as if it is on a superior level of difficulty compared to learning whatever bullshit combination of half-templated server side rendering, 4D DOMs and incantations needed to upgrade Webpack we need to know to be "up to speed" nowadays.

soraminazuki 5y ago

> making everyone learn its syntax and functional programming idioms probably negates the advantages of using static typing I think this is an over-exaggeration of the complexity involved because Dhall/Nickel/Nix are just JSON with variables and functions. If you're familiar with JSON and any general purpose programming language, say Python, you can learn the aforementioned languages in less than an hour. > Too bad. It seems like no one understands the assignment. You mean all those language designers for static configuration languages have no idea what they're doing? I think there's a better explanation. For complex configurations that warrant the kind of high level configuration languages we're talking about, declarative syntax seems to a better fit. Tracking mutation and state for large scale configuration would put the burden on everyone, beginners and experts alike.