Yes, Rash has a variety of limitations. Let me give some more context to these:
>1. no job control
Racket is missing a feature in its rktio library needed to do job control with its process API, which Rash uses. At one point I added one or two other minor features needed for job control, but I ran out of steam and never finished the final one. It's a small feature, even, though now I don't remember much of the context. I hope I wrote enough notes to go back and finish this some day.
>2. multi-line editing is limited
I always intended to write a nice line editor that would do this properly. But, again, I never got around to it. I would still like to, and I will probably take a serious look at your line editor some time.
The design was intended as something to use interactively as well as for scripting. But since I never improved the line editing situation, even I only use it for scripting. After documentation issues, this is the most pressing thing that I would fix.
>3. from what I understand, shell syntax is available only at REPL top level. Once you switch to Lisp syntax with `(`, you can return to shell syntax only with `)`. Thus means you cannot embed shell syntax inside Lisp syntax, i.e. you cannot do `(define j {find -type f | less})`
As mentioned is not correct, you can recursively switch between shell and lisp.
>4. shell commands are Lisp functions, not Lisp objects. Inspecting and redirecting them after they have been created is difficult
This one is a design flaw. I've meant to go back and fix it (eg. just retrofitting a new pipe operator that returns the subprocess pipeline segment as an object rather than its ports or outputs), but, of course, haven't gotten around to it.
>5. Rash is written in Racket, which has larger RAM footprint than schemesh running on vanilla Chez Scheme: at startup, ~160MB vs. ~32MB
Yep.
>6. Racket/Rash support for multi-language at REPL is limited: once you do `#lang racket`, you cannot go back to `#lang rash`
So actually `#lang` is not supported at all in the REPL. It's neither supported in the Racket REPL nor the rash repl. In practice, what `#lang` does is (1) set the reader for a module, and (2) set the base import for the module, IE what symbol definitions are available. With the REPL you have to do this more manually. The repl in Racket is sort of second class in various ways, in part due to the “the top level is hopeless” problems for macros. (Search for that phrase and you can find many issues with repls and macros discussed over the years in the Racket mailing list.) Defining a new `#lang` in Racket includes various pieces about setting up modules specifically, and since the top level repl is not a module, it would need some different support that is currently not there, and would need to be retrofitted for various `#lang`s. But you can start a repl with an arbitrary reader, and use `eval` with arbitrary modules loaded or symbols defined. My intention with a rash line editor would also have been to make some infrastructure for better language-specific repls in racket generally. But, well, obviously I never actually did it. If I do make time for rash repl improvements in the near future, it will just as likely be ways for using it more nicely with emacs rather than actually writing a new line editor... we'll see.
I'm always sad when I think about how I've left Rash to languish. In grad school I was always stressed about publication (which I ultimately did poorly at), which sapped a lot of my desire and energy to actually get into the code and make improvements. Since graduating and going into industry, and with kids, I've rarely felt like I have the time or energy after all of my other responsibilities to spend time on hobby projects. Some day I would like to get back into it, fix its issues, polish it up, document it properly, etc. Alas, maybe some day.
The docs are terrible, and I've always meant to go back and improve them... but it's never quite been a priority and I've never actually summoned the motivation to do it...
But it's always nice to hear when someone uses it and likes it despite that!
I think the parent poster agrees with you, but wrote somewhat ambiguously. I think he meant something like “a movie that was visually very striking, [but] without any plot fundamentals[,] that [therefore] felt like a deep betrayal to the universe.”
For what it's worth, I agree with him. When I saw the movie and even just the promotional materials I thought it was visually striking and had very strong color themes. But wow, it was a train wreck in terms of plot, characters, faithfulness to the series, etc. I could go on for hours.
But to be fair, I also think The Force Awakens was terrible and painted the story into a dumb direction. Instead of “what if the Nazis came back to power in Argentina”, they should have moved the story into a direction more like “the alliance against a common enemy is fractured”, like what actually happened after World War 2, or “there are now many factions of ambitious warlords rising among the widely deployed and still incredibly powerful imperial military”, or some of both. The Mandalorian did the setting much better in that sense.
They should have picked a direction at all, and TFA should have been anything other than a pandering remake of ANH (except this time the Death Star is even bigger.) There was no plan for the trilogy, so it wound up being Rian Johnson sabotaging JJ Abrams, then Abrams desparately trying to salvage things, and Palpatine thrown in at the last second in hopes people would show up.
While I agree that adding fuzzy searching and natural language discoverability are great, there are some other pretty important differences.
I thought a lot about this line:
> you had the best of the terminal paired with the best of graphical interfaces
Maybe there are many parts of a terminal that are “the best” for different people or use cases, but to me the key feature of the terminal is the ability to compose, extend, and abstract. Use a command with certain options a lot? Turn it into an alias or one-liner script. Use a pattern of commands a lot? Turn it into a script. Use a particular command really a lot? Add it as a custom keybinding. And it's pretty easy -- once you've paid the price of learning to use the shell at all, you are ready to start writing basic scripts. Granted, the price of entry to learn the shell is high compared to command palettes. But there is so much there that command palettes are still missing.
I wish I could upvote this 1000 times. Most firewalls are just so much security theater cargo culting. NAT and universal firewalls have done immeasurable, and at this point practically irreversible, damage to network freedom and free software.
Since everybody else is peddling their better shells, I'll drop a plug for mine: https://rash-lang.org
It's a shell embedded in the Racket programming language. If you're familiar with Xonsh, it's similar, but both more powerful and less polished. It allows easy, recursive mixing of shell code (not posix compatible, but with a similar feel) and Racket. Its interactive mode is not polished (I need to write a better line editor), but it works, and it's great for programming.
I haven't worked on it much lately (I need to wrap up other things to finish my PhD), but this weekend I added support for user-programmable substitutions with automatic cleanup. As an example, beyond common substitutions like process substitution (IE <() and >() in bash), I added a demo “closure substitution” form that allows you to send Racket functions to `find -exec`. Importantly, this is something that a user could add, because Rash is super extensible and malleable.
Shell is a great DSL, but there are huge advantages to having an embedded DSL rather than a stand-alone DSL. Rash inherits all the cool features of Racket and can be mixed with other Racket languages (eg. Typed Racket, Honu, etc), has advanced features like first-class delimited continuations and the world's most advanced macro system (which makes Rash possible), and any shell script can import functions from Racket's catalog of third-party packages. Embedded shells like Rash allow a shell script to be copied from interactions like you do with Bash, but then grow past the “rewrite in Python” stage gradually with no rewrite -- just a gradual transition from being more shell code to being more “normal” code.
Though I'm kicking myself for continually not getting around to rewriting all the documentation, which is still very poor.
For several years previously I ran Arch Linux on laptops, Debian on servers, and a mix of the two on various desktops. I'm generally much happier with NixOS. NixOS-style package management is the future, it's clearly better than all its competitors (I put Guix together with Nix as NixOS-style here). NixOS-style system configuration is also much nicer than most OSes, though the quality of configuration design for different components varies a lot, and I think there could be big improvements to the configuration language and APIs in future OSes that try to improve on the model (largely due to NixOS being the first system of its kind). I'm happy that Guix is also exploring this space and making some different decisions, and it's the only other OS that I would seriously consider right now. All in all, I'm very pleased with NixOS.
As to `#lang python` interop with Racket, it's possible, but the farther a language's semantics and object model differ from Racket, the harder and less pleasant it is to build and use in practice.
In other words, you need converters between runtime values between Racket and Python when their semantics differ.
For example, Python strings are instances of Python's string class, with a bunch of methods, and you can mutate the string class at runtime.
They are very different from Racket's strings.
Then you have all the differences in core reduction semantics, how concurrency and parallelism is handled, etc, and there are a lot of differences to smooth over.
There is a project called PyonR (https://github.com/pedropramos/PyonR) that implements Python 2.7 as a Racket #lang, but it hasn't been developed for a while, and I'm not sure how interoperable it actually is.
It certainly isn't to the point where you could pull in your favorite Python package from PyPI to use in Racket, but it does claim that you can use Racket functions in your Python code at least.
The hardest part just using PyPI packages is probably that many of the most important Python packages lean on Python's C FFI, which is a large extra hurdle, though there are many worthwhile packages that are pure Python code.
The most successful Racket #langs are languages that fit a particular domain or style of programming better than basic Racket, but that lean on Racket's core semantics and object types as a building block rather than something to be constantly slightly different from in ultimately unimportant ways.
While working with Racket, these languages may be very different from the core Racket language, such as documentation languages (scribble), logic languages (datalog), shells (rash), database query languages, etc.
If you just wanted to let people write new code for their editor in a language that looks and feels like Python alongside Racket and its #langs, it would be a much easier project to make a language with Pythonic syntax (syntax is shallow), easy constructors for Python-like lists and such (just a few custom datatypes), and a Python-like way of providing generic operators (eg. __magic_method__), etc, but otherwise with semantics closer to Racket's.
Frankly, you would end up with a better language than Python anyway, with powerful features that most Pythonistas haven't dreamt of. (Bias revealed!)
But I do dream of having a `#lang python` implementation good enough to just use Python packages in a pinch when Racket doesn't have an equivalent package.
It's possible, but it's a big enough project and there is little enough manpower in the Racket world that nobody is seriously working on it.
I agree with you. In a perfect world you would be able to drop in Python code and only have to add a #lang Python at the top of it. But realistically I think it would be closer to what you were saying about creating a pythonic language.
So maybe the practical solution is to have a language that looks like Python, Java, Ocaml, etc. I'm not sure how many #langs you would need to make the majority of programmers feel comfortable but I think even implementing a few would be a huge step up in accessibility than what we currently have.
