[klibertp]

> wow, i guess you got hooked :-)

Maybe a little :D REBOL line of languages has been on my radar for a long time - I've been a PL nerd for 20 years now - but I always found reasons not to engage with them. So it was a bit of a blind spot: I knew some basics, considered it a pretty elegant and powerful design, but the REBOL3 fiasco, the proprietary nature of REBOL2, and the various facts about Red (pivot to it being a "blockchain native" solution was painfull to watch, dependency on REBOL2 for the toolchain/no self-hosting after almost 15 years in development, etc.) made it hard to dive deeper into the language(s). I had some time yesterday, and your comment touched on something I'm already interested in (interactive CLI/universal REPLs), so I took the opportunity to finally learn more about the language.

> i am not actively trying to create a new shell, but i am exploring languages for their potential to design a shell language without having to reinvent the whole syntax from scratch.

As for me, I tried making shells a few times. All those failed, of course, mostly because I wanted to do something a bit different: a text-based computing environment with network transparency, basically a single-player MUD/MOO that would treat the filesystem as a world. I got quite far with Smalltalk - but GNU Smalltalk that I based it on collapsed under me :( I tried Elixir, Io, and Python, and all would require much more work than I was willing to put in. A pity, because I think that would be the best possible environment for LLMs/agents... I'm still thinking about this idea often, and I started working on a new implementation, using Pharo Smalltalk/GToolkit. Parsing is the easier part, actually: it's the liveness of the whole thing (hot reload, adding functionality from within the environment, mapping the environment back to source code, etc.) is the part I had the most problems with, and Smalltalk seems like the most promising platform for implementing it.

[oldes]

The only fiasco with Rebol3, as I see it, is that everybody was asking for the language to be open-sourced, and when it finally happened, almost nobody was willing to take on the responsibility of maintaining it once Carl left, and almost the entire community disappeared - many to the Red camp.

Btw, Rebol is still being developed, without the masses noticing it.

https://rebol.tech/ https://github.com/Oldes/Rebol3/releases

[em-bee]

i suspect the community disappeared and moved to red already before rebol3 opened its license.

but if rebol is still being developed then someone (evidently that's you) eventually did take on the responsibility of maintaining it.

i have no clue here. i even only know about red because i met nenad in china. otherwise this whole ecosystem would not be on my radar)

so tell me, what motivated you to pick up rebol3, how does it differ from red and from rebol2 (the repo mentions making rebol3 as usable as rebol2 which implies that as released it was less usable. why did that happen? they could not open everything?)

one difference i see right away is that red is written in red/rebol whereas the original rebol is written in C. being selfhosting is a major feature for a language in my opinion.

[oldes]

As I understand it, there were some investments involved in the development of Rebol2, so it was not possible to release its code. Instead, Carl started Rebol3 as a rewrite. It was first divided into a closed Core library and an open-sourced Host part. Later, both parts were open-sourced, and Carl left.

Rebol3 was always considered an alpha version. In my fork, I've fixed hundreds of bugs and missing features.

And my motivation? I've been using Rebol since its early days. I used it successfully as a scripting language when producing several games. And since I don't make games anymore, I wanted to give something back to this abandoned language, whenever I have the time.

I was also involved in Red (and still follow its development), but for multiple reasons I decided it was better to work alone on the invisible Rebol.

[em-bee]

that's awesome. how would you compare rebol3 with red? are there any syntactical differences? or just whats in the libraries? or the architecture, capabilities? as far as i can tell the main difference seems to be that rebol3 is written in C while red is written in rebol2/red itself.

[oldes]

Yes. R3 is written in C and Rebol. Red is so far using Rebol2 to be compiled and Red for mezzanine code.

Main difference is that there is a GUI available in Red. That is not available in R3 yet (at least not in my version). There was a GUI in the Saphirion fork, but it is abandoned for years and I didn't wanted to use it. I would like to provide GUI in the future. Probably as a native extension.

The code is almost same.. although there may be differencies in some function refinements or other details.

Even when Red is compiled to the assembly, it is still slower than interpreted R3 code, because of lack of optimizations. As it depends on its own compiler is also the reason, why there still isn't support fot 64bit arch. To write own compiler is a big task indeed.

And then R3 and Red differs in the number of developers. There may be 3 or 4 people (2 active) working on Red while R3 is worked just by me so far.

[em-bee]

your scope of interest seems to have a lot of overlap with mine. though i may be am aiming in a slightly different direction. i am also coming from the MUD world (for my websites i use a platform that has a MUD like architecture underneath :-), and i have a strong interest in a better commandline. i am less focused on exploring languages, that's more of a side quest.

what i really want is a commandline that works more like jupyter notebooks. each command is its own entity, that can be edited and run again. there is an output window/frame separate from the input/command, just like the jupyter. that output can run anything, graphics, an interactive app, like an editor, even a filebrowser. commands can produce structured data that can be interpreted and visualized... (if only i could find funding for this idea :-)

and, yes, i agree, smalltalk has a lot of potential for this. the downside of smalltalk i fear is that it is to bulky for the average user, and this system need to be able to integratable with unix commands written in any language so the interface needs to be agnostic (perhaps json? and another more suitable for binary data, also apps need to be able to run and display output directly to the screen, not depend on pharo to display).

there was a time when i tried using pharo as a desktop. i used a terminal written in smalltalk, and i was looking at finding or building tools a desktop needs (workspace management, a clock, all these small utilities)

if you have something to play around with, i'd be curious to give it a try.