3 ms·

Publishing a project at this level of immaturity doesn't do it any good. While it definitely "works", it works as an experiment about techniques to write an int

Publishing a project at this level of immaturity doesn't do it any good. While it definitely "works", it works as an experiment about techniques to write an interactive command interpreter in Rust, not as a shell for people to use. Currently there is no documentation beyond the introductory GitHub page. But this isn't a fork of sh that only needs documentation of the minor ways in which it departs from POSIX compliance: there is an unknown set of internal commands, each with a complex table format for its output (it is necessary to know all relevant column names to do anything), which depends on a large set of non-text types, which have complex object-oriented behaviour, with "serialization" to a variety of file formats, with an unspecified script and command line syntax. Such complex features, on par with serious frameworks in full-fledged programming languages, need to be defined and documented very thoroughly, or nobody will understand, trust and use them. Unfortunately, there are many hints that not only documentation is vastly behind schedule, but that important aspects and practical considerations haven't been addressed. For example: how can I quote file names containing nasty characters? How can I use environment variables? What is my home directory? Why is executing an executable program difficult, with complex and unclear mechanisms that mess with the command line? Given a very simple and very portable traditional shell script (e.g. ps -eaf | grep foo | sort) how can I do the same in Crush with minimal effort? If I load a very large file, does the shell choke attempting to load it all to memory, or does it process it in a proper streaming fashion? Other issues are more fundamental. How can I perform relational queries between multiple tables, e.g. a join between ls output and a file listing users? If I can't, what can I do with tables that cannot be done more easily and flexibly with awk, jq, and other established tools?

appleflaxen 6y ago
I have zero interest in this project, but disagree that it "doesn't do any good" to share. People with similar inclinations and interests can collaborate on software that isn't ready, but that scratches their itch. Theres nothing wrong with that, as long as you don't create unrealistic expectations.
- HelloNurse 6y ago
  The problem with novel shells, compared with other kinds of itch to scratch, is that existing shells have had about 50 years of evolution: doing better in a few months of work is quite unlikely. A new shell must be similar to existing ones for compatibility with an enormous ecosystem of command line tools that work well in a typical shell; it must do almost everything that traditional shells do equally well (this includes documentation; documentation is non-negotiable) but it must also have some compelling advantage. The right way to collaborate on designing a shell is to discuss possible designs of command syntax and behaviour, then if some promising idea comes out of the brainstorming refine it to a full specification, then if the idea survives (without mutating into a less ambitious scripting language, or a library for an existing language or shell, or a small change to an existing shell) begin an implementation. Starting with a proof of concept without a well developed and well documented design is the wrong way to offer a "product" but also the wrong way to learn.
  - da39a3ee 6y ago
    You either have no idea about open source software, or you have no idea what it feels like to love programming, or both.
da39a3ee 6y ago
Please define what you mean by "publishing". Where has the author said anything more than "this is a project on my Github and here's what it does"? Assuming the answer is nowhere: Please retract. You appear to be one of those people with no understanding of modern open source culture, and only the ability to criticize. Do you expect everyone to keep their projects private until they meet your personal standards? (a) why the fuck should they? (b) what about a Github user who simply lacks the skills to ever meet your standards? (Evidently not the case here.) It's a shame I'm being overtly aggressive, but I think it's commensurate with the less overt unpleasantness of your comment. I bet you're one of those people who thinks it's "irresponsible" to publish software on Github that could have bad consequences if someone were to rely on it in an important context. Repositories such as Github are free. They are a place for anyone to store whatever creations they come up with. It's a huge and uncuratable mixture of essential backbones of modern computing, art, utter incompetence, and technical genius, and a lot of stuff in the middle. How that is hard for people like you to understand I do not know. I guess you have a very boring job at a very boring company.

appleflaxen 6y ago

I have zero interest in this project, but disagree that it "doesn't do any good" to share. People with similar inclinations and interests can collaborate on software that isn't ready, but that scratches their itch. Theres nothing wrong with that, as long as you don't create unrealistic expectations.

HelloNurse 6y ago
The problem with novel shells, compared with other kinds of itch to scratch, is that existing shells have had about 50 years of evolution: doing better in a few months of work is quite unlikely. A new shell must be similar to existing ones for compatibility with an enormous ecosystem of command line tools that work well in a typical shell; it must do almost everything that traditional shells do equally well (this includes documentation; documentation is non-negotiable) but it must also have some compelling advantage. The right way to collaborate on designing a shell is to discuss possible designs of command syntax and behaviour, then if some promising idea comes out of the brainstorming refine it to a full specification, then if the idea survives (without mutating into a less ambitious scripting language, or a library for an existing language or shell, or a small change to an existing shell) begin an implementation. Starting with a proof of concept without a well developed and well documented design is the wrong way to offer a "product" but also the wrong way to learn.
- da39a3ee 6y ago
  You either have no idea about open source software, or you have no idea what it feels like to love programming, or both.

da39a3ee 6y ago

Please define what you mean by "publishing". Where has the author said anything more than "this is a project on my Github and here's what it does"? Assuming the answer is nowhere: Please retract. You appear to be one of those people with no understanding of modern open source culture, and only the ability to criticize. Do you expect everyone to keep their projects private until they meet your personal standards? (a) why the fuck should they? (b) what about a Github user who simply lacks the skills to ever meet your standards? (Evidently not the case here.) It's a shame I'm being overtly aggressive, but I think it's commensurate with the less overt unpleasantness of your comment. I bet you're one of those people who thinks it's "irresponsible" to publish software on Github that could have bad consequences if someone were to rely on it in an important context. Repositories such as Github are free. They are a place for anyone to store whatever creations they come up with. It's a huge and uncuratable mixture of essential backbones of modern computing, art, utter incompetence, and technical genius, and a lot of stuff in the middle. How that is hard for people like you to understand I do not know. I guess you have a very boring job at a very boring company.