TopShell looks very interesting, thank you for sharing!
This is a problem domain which I've been thinking a lot about recently. I write tons of shell (bash) scripts. I hate bash and its peculiarities, but it remains one of the quickest ways for me to get work done; I've tried to use many other languages to fill the gap of writing scripts that start as quick one-offs but have the potential to evolve into a more refined piece of software over time, but so far haven't had much luck.
Most languages force me to go to great lengths for everything I want to do in this domain:
- implementing command-line arguments/flags/subcommands: either overly-simplistic (getopts) or overly complex (cobra)
- force me set up error handling for everything that could possibly go wrong
- aren't flexible enough to transform 'soupy' data between various representations without basically writing a full-blown custom parser
- can sometimes be difficult to distribute a minimal-dependency release to remote machines or other users
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.
So far, what I gather from your readme/wiki is that TopShell is:
a) A functional language seemingly inspired by ML, Haskell, et al.
b) A reactive development environment for the language, à la Jupyter
I love the code examples in the readme; I think this is something most people want to see but a lot of projects overlook. However, I think the readme is a bit barren on the philosophical front. You have a great wiki page [0] for that - I think it could be condensed and integrated into your readme so new visitors have a good idea of your vision.
As someone who would consider using TopShell, my concerns are:
- I can't find documentation on how I can use my own editor/environment if I want, rather than the web interface (which is nice for its notebook-like experience, but I don't see it fitting into my normal workflow)
- I want to continue to integrate with programs which adhere to the unix philosophy; how does TopShell fit into this?
- How dedicated are you to the development/maintenance of the project?
- Do you forsee growing a community of contributors (and if so, how?), or do you want to keep this as a personal pet project?
- Do you think the project will be alive in 1, 3, 5 years?
> I've tried to use many other languages to fill the gap of writing scripts that start as quick one-offs but have the potential to evolve into a more refined piece of software
Groovy is pretty great for this. I have tonnes of things that start off as one liners and end up as full blow JVM (Java/Groovy) applications.
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.
> 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.
That actually sounds perfect. If you were able to implement this, I could see this tool coming in very handy for tons of things.
I’ll be keeping a close eye on the project, thank you for your thorough response!
This is a problem domain which I've been thinking a lot about recently. I write tons of shell (bash) scripts. I hate bash and its peculiarities, but it remains one of the quickest ways for me to get work done; I've tried to use many other languages to fill the gap of writing scripts that start as quick one-offs but have the potential to evolve into a more refined piece of software over time, but so far haven't had much luck.
Most languages force me to go to great lengths for everything I want to do in this domain:
- implementing command-line arguments/flags/subcommands: either overly-simplistic (getopts) or overly complex (cobra)
- force me set up error handling for everything that could possibly go wrong
- aren't flexible enough to transform 'soupy' data between various representations without basically writing a full-blown custom parser
- can sometimes be difficult to distribute a minimal-dependency release to remote machines or other users
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.
So far, what I gather from your readme/wiki is that TopShell is:
a) A functional language seemingly inspired by ML, Haskell, et al.
b) A reactive development environment for the language, à la Jupyter
I love the code examples in the readme; I think this is something most people want to see but a lot of projects overlook. However, I think the readme is a bit barren on the philosophical front. You have a great wiki page [0] for that - I think it could be condensed and integrated into your readme so new visitors have a good idea of your vision.
As someone who would consider using TopShell, my concerns are:
- I can't find documentation on how I can use my own editor/environment if I want, rather than the web interface (which is nice for its notebook-like experience, but I don't see it fitting into my normal workflow)
- I want to continue to integrate with programs which adhere to the unix philosophy; how does TopShell fit into this?
- How dedicated are you to the development/maintenance of the project?
- Do you forsee growing a community of contributors (and if so, how?), or do you want to keep this as a personal pet project?
- Do you think the project will be alive in 1, 3, 5 years?
[0]: https://github.com/topshell-language/topshell/wiki/TopShell:...