stshell
moor
Our great sponsors
stshell | moor | |
---|---|---|
2 | 7 | |
0 | 149 | |
- | - | |
0.0 | 9.7 | |
over 2 years ago | about 1 month ago | |
Smalltalk | Rust | |
- | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
stshell
-
Evennia a MUD/Mu* Creation System
It's slowly getting traction - Kotlin on Android has a "live update" feature (in development, only available in alpha release), for example. Multiple less mainstream languages also offer the feature. Nim got it in the last major release, for example. V has it as one of the base features. Erlang and Elixir had it since forever. Common Lisp as well. Racket and Clojure are a little more limited than CL, but also support it. Many interpreted languages offer some degree of this, either by default (JavaScript) or as a library/package (Python, Ruby).
In general, programming language features take about 20 to 30 years to go from obscure niche implementation into the mainstream. Look at lambdas - anonymous function literals - they're now everywhere, including Java and C++. Ten years ago, though, only some scripting languages had it. The feature itself is as old as the bones of the Earth (LISP, 1960, 63 years old). The same is true for many other "advanced" features. I think this is tied to generational changes - each generation of programmers has a chance to bring one or two lesser known features into mainstream, and then they're content with that. Other features have to wait for the next generation to discover them.
As for Smalltalk - I made a mistake and based the implementation on GNU Smalltalk, which is unmaintained. I should have gone with Smalltalk/X, Visual Works, or (begrudgingly) Pharo (or Cuis). I started the project as yet another attempt at making a MUD, but then changed focus to making a productive command-line-based programming env for Smalltalk. Then I changed my mind again and tried to make it into a usable shell. Here's the project: https://github.com/piotrklibert/stshell/ The screenshots focus on the REPL/shell side, but in the source you'll see things like "server", "player", and "world". There are a few locations IIRC and you can move your character between them still. It was an interesting project, but without a clear vision of what it should be it lost focus and I left it to rot after a while :(
-
Guide: Hush Shell-Scripting Language
> We need better shells.
Obviously. I don't think this is the most important missing part, though. I would say it differently: we need way, way better REPLs.
IPython is an example of a REPL that's passable as a shell. It can run in a terminal and has a GUI version based on Qt, which allows displaying images inline. You can drop into a "real" shell with a single `!` character (you get pipes, output capture, and (Python) variable interpolation), and it even has some syntactic shortcuts for the parts where Python's own syntax is irritatingly verbose. If you like Python, then IPython can be your day-to-day shell right now. You just need to remember not to start ncurses programs from within qtconsole (works ok in terminal). I used it for a few years when I was forced to work on Windows. Before my time, I heard it was popular to use tclsh as a shell on Windows.
I think that it proves that almost any language can be used as a shell, as long as its REPL is as rich and featureful enough. Since you can use Python as a shell, which as a language is not exactly the epitome of terseness and expressiveness, you could definitely make do with almost any other interpreted language, too. The problem is that very, very few languages have REPLs that are anywhere near IPython. It's so bad sometimes that you're advised to use `rlwrap` just to get basic line editing and history!
I've been working on a new shell based on GNU Smalltalk[1]. I really like the syntax - or lack of thereof - and being able to dump an image at any time seemed like a good idea. The only change I needed was to add the `|>` pseudo-operator, which puts what's on the left into parens. Being able to introspect the running session was my primary motivation: I wanted to make the shell and the whole environment as discoverable as possible. I wrote some code for that and then realized that the default REPL uses readline from C, so it freezes the entire VM when waiting for input (including all background threads). My workaround was to set up a socket server and connect to it via rlwrapped telnet...
Anyway, I think "do we need a new shell" is the wrong question; instead, we should focus on improving REPLs to the point where a separate shell becomes unnecessary.
[1] https://github.com/piotrklibert/stshell
moor
-
Gleam
I think Haskell or OCaml would do a better job on the ADTs for a parse tree. When doing this, I found Rust's enums... anemic... and got very annoyed by the awkwardness of having to Box recursive types. I was reaching for the ability to continue to be able to pattern match on nodes while attaching common attributes (line numbers, etc.) and ended up having to bury everything 1 level deep in a struct which ended up feeling awkward.
That and Rust's iterators are terrible at introducing ownership agony.
In any case, I've ... done it (https://github.com/rdaum/moor/blob/main/crates/compiler/src/...) but can't say I liked it.
I do really like "pest" as a parser generator though.
- Show HN: I rewrote the 1990's LambdaMOO server from scratch
-
I rewrote 1990's LambdaMOO from scratch on a new foundation.. with the intent of a new system for tomorrow...
See: https://github.com/rdaum/moor
- Evennia a MUD/Mu* Creation System
-
LambdaMOO Takes a New Direction (1992)
I've been working on a rewrite of the server into Rust, for kicks: https://github.com/rdaum/moor
Unfortunately still lots of work there to be done, and I have no time.
What are some alternatives?
busybox - The Swiss Army Knife of Embedded Linux - private tree
floor - The typesafe, reactive, and lightweight SQLite abstraction for your Flutter applications
readline - Pure Go reimplimentation of readline
Hive - Lightweight and blazing fast key-value database written in pure Dart.
lash - A modern, robust glue language
tinyfugue - TinyFugue - Rebirth
Wormies-AU-Helpers - Helper scripts to make maintaining packages using AU even easier
mudmixer - MUDMixer is an add-on for MUD clients that enriches the gaming experience with connection mixing functionality and a variety of other features.
u-boot - "Das U-Boot" Source Tree
gleam-otp-design-principals - Gleam OTP Design Principles User's Guide
oil - Oils is our upgrade path from bash to a better language and runtime. It's also for Python and JavaScript users who avoid shell!
mobx.dart - MobX for the Dart language. Hassle-free, reactive state-management for your Dart and Flutter apps.