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.

https://github.com/cotowali/konryu/blob/main/konryu.li

and the generated shell script

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/

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.

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.

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".

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.

Eh. I'm not saying one way or the other that FP is good or bad, but the software industry is incredibly young and changes a lot. Even in a relatively short period - 10 years, let's say - things are pretty difference. 20 years, still a short time, and things are radically different.

And on top of that, it is still the case that a lot of stuff takes a long time to get adopted. It's hard to build and popularize a programming language, regardless of how good or bad that language is, because they tend to lack interoperability with other languages if they're very different, which is usually a requirement if they want to be considered worth looking at.

So I'd just as easily buy that people haven't used a lot of FP due to inertia, a lack of the right external inventives, etc, and not by any virtue of the paradigm.

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.

After that, https://fsharpforfunandprofit.com/series/why-use-fsharp/ and pretty much anything made by Scott Wlaschin is very accessible, and to the point.

In practice you can write imperative code using either of them but the focus on immutable data structures, and (in Rust more than Scala) functional error handling means that many manipulations are easier to do with FP constructs, so they appear quite naturally (Option, Result/Try, iterator maps etc.)

As a bonus IME they are very similar in many respects so experience in one translates well to the other.

I'm a backend developer by trade and Elm made me fall in love with frontend development, which I've rather hated before.

I was mostly wondering how/if it does any type checks for function input; it does not. Also raytracing.sh unfortunately fails to run on my system as it is.

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.

This is an odd example. TypeScript compiles to readable JavaScript for nearly everything except the odd runtime behavior (eg enums) and “downleveling”, which is increasingly unnecessary. Minification is still a separate step AFAIK (if you’re using tsc; obviously ESBuild and SWC are another story, as will be Bun).

Whereas if I’m compiling TypeScript/CoffeeScript/anything to JS, it’s pretty likely I already have JS as a built in constraint and I probably want to be able to read the output so I can debug it.

But even so, I would never expect any transpilation output to be more than technically readable.

The part with the high level meaning is the part the human wrote. That's the entire point of any language.

The output can not be considered source, regardless that it's possible to also write source in that same syntax.

The only reason to even bother with transpiling instead of just requiring the necessary interpreter, is to ship something that the target already supports. It's very very little different than shipping a binary.

The differences are just that a .sh is at least possible to read and hack vs not-possible. Not convenient or good, merely possible vs not-possible. And a .sh is more portable than a binary in that it doesn't care what the cpu or os is.

If you want anything more high level meaningful instead of some 90's web page generator html output, you have to write that yourself. An automated tool cannot reverse engineer some code into an elegant expression of the original intent of that code. In that way a compiler or transpiler is not much different from a decompiler.

Though, I admit there is room for levels. I don't know just how crude this tool's output is, but I know there is a range of what's possible, it does't have to be

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).

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.

It's a bit overambitious IMO, but it tries taking a relatively different approach to the problem that I find to be quite interesting.

Do you actually want a statically typed _imperative_ language for generating configs?

Or do you want a sane, statically typed, declarative language for configs?