Thank you for the long and thoughtful comment. I think you bring up a lot of valid points, and I don't have complete answers to all of them yet, but I'll do my

Thank you for the long and thoughtful comment. I think you bring up a lot of valid points, and I don't have complete answers to all of them yet, but I'll do my best to address them here. > Functional languages are awesome for many of these things, but can be awkward when dealing with the side-effects that we normally want when dealing with scripting tasks. I think that's a common sentiment, but I have a different take on it - purely functional programming is actually great at expressing intended effects - as opposed to side-effects! With the right standard library, I think it might be possible to make I/O at least as easy as in imperative scripting languages like Python. As a small example, compare reading a file as a string in Python and TopShell: Python: file = open(“testfile.text”, “r”) text = file.read() TopShell: text <- File.readText "testfile.text" Does that translate to bigger examples? I think it does, but a more serious efford to compare the two would be required for a convincing argument. > I can't find documentation on how I can use my own editor/environment if I want, rather than the web interface This is not yet possible. What I have in mind for this is moving the code execution to the backend and having some way for an editor to communicate with the TopShell server - perhaps through the Language Server Protocol. > I want to continue to integrate with programs which adhere to the unix philosophy; how does TopShell fit into this? TopShell can use such programs, but TopShell scripts can't currently become such programs. I'm still looking for the right way to do this - one way would be to have a `main : System -> Stream Bytes -> Stream Bytes` where `System` contains command line arguments and so on, and `Stream Bytes -> Stream Bytes` is stdin to stdout. > How dedicated are you to the development/maintenance of the project? I'm not sure what an answer to that looks like - though what I can say is that I use TopShell for all my own ad-hoc scripting needs. > Do you forsee growing a community of contributors (and if so, how?), or do you want to keep this as a personal pet project? I hope for a community of contributors, but I have no experience in community building per se. There are many low-barrier ways to contribute though - for example, by extending the standard library. Any tips? > Do you think the project will be alive in 1, 3, 5 years? I do think so, but as it is, there's a "bus factor" of 1. Please don't bet your business on it right now unless you're prepared to take over maintenece on a moments notice. > Can sometimes be difficult to distribute a minimal-dependency release to remote machines or other users To me, a script is a single file I can send to a friend (or put on a machine), and it will just run. Most scripting languages don't really do this, because they assume that package management is handled somewhere else, and implicitly depend on an environment. When TopShell eventually gets a `main` function, the goal will be that all you need to run a script is the script file and TopShell.