That´s what a Video Editor does( one of ours is called Medo, I believe ) .
1 Like
@sirocyl
What do you think of thd existing environment of Luau as a text-based starting point? It’s derived from Lua but designed for the development environment of the Roblox game engine.
What I have in mind is to use the unoptimised version of the Luau bytecode as our save format as binary and the existing text language as the basis for the scripting engine. Of course the runtime will be an expansion of the more traditional shell runtimes.
One thing I find attractive about Luau is that the loader of the execution engine gets similar performance to the earlier LuaJIT without requiring processor specific Assembly support.
1 Like
I’m not happy with Lua. It has too many idiosyncracies to its type of embeddable, table-oriented programming, and doesn’t mesh well with a job-control paradigm like a shell, in my opinion.
I think starting fresh should not be too difficult, or perhaps even using scratch’s Squeak VM itself as a base, seeing as it is a highly-portable Smalltalk-like object-oriented environment.
Ok. Have you heard of Google’s Blockly? It’s almost identical to Scratch’s interface but generates JavaScript. I’m not so fond of that idea but we have Node.js to use as a basis. I think the Scratch VM might have more potential but I want to have our bases covered.
Yeah, looked into it in the past - theirs is more toy-shaped than Scratch even, and only agglutinates JS together, rather than being a fully appropriate scripting language in and of itself.
Also of note - the scripting language itself, would not be a Smalltalk variant or Squeak code. It would be its own thing, much like the relationship between Scratch and Squeak. Commands and objects in the shell itself can be written in Squeak, but the shell itself is high-level and focused on job invocation and control.
Ok. I’ll look at SqueakVM. Maybe I can see how it looks. I like starts that are growable. If it’s object-oriented enough, we can do something serious with it.
One could say Smalltalk, which Squeak is based on, invented the term “object oriented” 
I’ve been taking a look at Pharo, as well. It seems neat, and has a lot in common visually with the concept here.
It uses the same underlying VM (a common smalltalk VM which is called Cog, now, apparently) and the only difference with Squeak is that it is a dialect atop that VM.
Its IDE departs from the goal of being a “simple, user-friendly visual shell” by being a whole IDE though, which is a bit much (and the IDE uses up 64MB of RAM, which is also a bit much) - but the VM underlying it would be good for this project, and the IDE would be useful for programming it, and programming (e.g., modules) for it.
1 Like
That’s true. I’ve been writing a framework for AmigaE on my MorphOS machine and it doesn’t support more than single inheritance without bending rules. I’d prefer to at least have interface inheritance like Java.
Quoted from the website for Pharo:
Dynamic inheritance
- You can change the definition of existing classes including changing its superclass. To some selected object, you can simply assign a different class and do similar operations. These capabilities are essential for the ability of the system to evolve without the need for restarts.
Smalltalk itself may have sucked in 1998, just as it did in 1968, but we’re past that now. 
Alternatively, we write something new on C++, implemented from new.
2 Likes
Applications can include Replicants that offer functionality like handling multiple files rather than a single instance and then do all the work they were designed to do, but with a queue of files. This queue of files could be a query/folder/selection, dragged from the Desktop.
Embed Replicants in the Tracker/Desktop and then connect them with logic lines representing file queues, and there you have it. Automation. Visual scripting. This is what Be intended, and Cortex was just an example showing what this could be like. Be simply did not have time to complete it.
For this we need coders to write Replicants that handle Queries and Drag 'n Drop, but also the logic lines connecting Replicants together as a queue.
3 Likes
I’d prefer to write only a little from new, in the interests of quick debugging. That’s why I brought up Luau before.
I’ll try Pharo but one problem that I see it has is it uses C as a backend language while Luau is completely rewritten in modern versions of C++. When optimizing, Luau caches or constant folds table lookups until it is as if they weren’t even there. Also, there’s type specifiers that make comparing Luau to Lua like comparing Python 3 to Python 2. Luau is way more advanced than Lua.
@dorje
I like the Tracker query engine. That needs to be incorporated in some way, for certain.
Update Regarding Pharo
I tried Pharo on my Linux box using a launcher found in the Arch/Manjaro package manager. It loaded up fine and I configured the stable release 11.0 except it still wasn’t stable on my 3rd-gen i7 with 32 GiB of RAM. Hope for Pharo is not boding well. Every time I tried to run something it would crash. I didn’t try 32-bit mode because I don’t have many systems with only 32-bit processors on Intel x86.
Welp. That’s probably gonna undo that plan at least. I’m gonna look into the code behind Scratch itself and see if I can’t do something with it. Ultimately it might just be better to work from-first-principles toward this goal, though.
TLDR of @sirocyl’s idea:
3 Likes
Seems like using an programming language not made for shell scripting, such as luau or python, would result in syntax which looks like this:
grep(cat("words.txt"), ".*ing")
echo("-e", "\e[4:2m\e[38;5;97m\e[58;5;88mHello World!\e[0m")
It’s ok, but it looks a bit strange…
2 Likes
The -e in quotes is a little different than reality. It would be represented internally as constants in a bitset. Just the e outside of quotes would suffice.
BTW, thanks for your visualizations.
1 Like
I was very sceptical at first. But now it sounds cool to me.
If I understand it correctly, there are (minimum) three isolated aspects:
1.) A bytecode VM
2.) A shell language
3.) A visual editor
Correct me if I’m wrong about this.
3 Likes
That’s correct! If it’s done right it’ll be able to import other formats eventually also. (Let’s not get too far ahead of ourselves in the meantime.)
1 Like
I have been following this thread from the beginning. So what you all have been discussing lately, to me–the average non-programmer common user, is more like another [but different] O-O IDE and not so much a shell. IMO
Is the goal of this discourse to establish another programmer’s shell or IDE? That is what it seems to me from the last two visuals examples from Zardshard and sirocyl. Those are definite OO IDE “look-alikes”–not so much of a shell…
My strengths are in batch/procedural languages (i.e. Top-Down programming only)–I just need a text editor to do what I do.
For me, OO programming is convoluted and have too many files to keep track of. I have completed many Java and C++ courses and I know how to program in OO–I do not like it. I find event-driven programming and OO very frustrating–not for me.
The extent of my programming that I need in Haiku is a bash scripting or Basic (i.e. YAB)–like most average users need. They need to write a script or some code to do what they need the system to do.
Since Scripture Guide lacks verse-list features, I have a bash script that connects to one of my SQLIte/PostgreSQL databases, obtains database records, organizes the data, and, in this example, opens Koder so I can read my daily Bible verses. [I use Koder because StyledEdit does not have a dark mode for reading and writing.]
See the example:
I considered developing a C++ program to create a GUI version of this script–but I started and then stopped when I completed ‘Learning to Program with Haiku’.
I know that bash will never be replaced in Haiku and, my impression from this discourse, this new OO prgrammers shell will be another utility for the advanced programming Haiku users. Not the common user. It would be interesting to test if it ever get developed and produced.
Keep going guys–some good stuff!
3 Likes
The only OO feature of Luau is the shorthand notation of table:function() to mean table.function(table) and that’s it. The self parameter when using table lookup is the only one.
Python and SmallTalk is OO in full capacity but Lua and by extension Luau, doesn’t support inheritance at all. If I mentioned inheritance before it was referring to the writing of the underpinnings in SmallTalk vs. C++17 for the virtual machine. The actual scripting language will have querying features but that still doesn’t imply object-orientation.
I like building blocks in terms of making code useful in other circumstances besides its original purpose but making code reusable doesn’t mean that OO is the be-all end-all in programming. If the test of time has taught us anything about OOP it’s that inheritance within code is often an anti-pattern of overusing expensive dynamic dispatch. If compilers could devirtualize functions within classes, performance might improve but code optimizers aren’t smart enough to know when inheritance is not needed.
Does that help your perspective, @ArDrakho ?
2 Likes
And further, I don’t think we need to explicitly go full-ham on OOP techniques with this shell, by forcing even simple scripting to be complicated and objectful. I think an imperative, sequential task engine (a “batch language” like @ArDrakho mentioned) suffices for the large end of it, after all, we are calling into programs like rm and cp - we’re not taking that over.
What we do want object-oriented, is access to data. Said data being files on the filesystem, and objects in the API at large.
And what we also want, is a good interface to program in said batch-style language.
We also don’t want weird hacks and cryptic sigils like the IF and FOR command, %~dp0 and :~3,-3 in Windows/DOS BAT, or the hackish [ command in UNIX shells. We want things like that to be as much a part of the shell language as possible, and in a way that’s sensible.
Pipes and stdio redirection can flow visually, too.
2 Likes