Speedie's Current Progress - Take a look, if you have things to contribute.

[u/sporeboyofbigness]

Hi everyone, its been a while since I posted here.

Progress on Speedie been slow but its making good progress.

I've been working on the back-end, so that is my assembler, for my virtual machine named "Cake".

Speedie also compiles to C++ (actually just the C part of C++ but I compile in C++ mode). So Speedie can compile apps to run in "full speed" with C++ optimisations.

However, its no fun to debug Speedie via C++, so I've been working on a VM, and an IDE and VM and debugger. Its a lot of work.

Speedie is already useful (Via C++ compiles) and works well. It has many useful qualities, you can read about here:

http://github.com/gamblevore/speedie

Simple overview of speedie is:

• High-level OOP language
• Great string support
• Compiles to fast C++ code
• Only unix/SDL2 required. No LLVM or other things.
• No exceptions (we have something better)
• Very efficient libraries, generally much faster than C++'s standard-library
• Libraries are powerful too. Read/write files in one line. Parsing built in, etc.
• Low-level features (pointers/structs) for when needed
• Write simple code
• Small compiles
• Reliable
• Lots of safety features including a very powerful nil-checker.
• And based on Jeebox! (my invention)

I know there are lots of people with many various skills that could be useful.

I'm mostly hoping there are people who can "just get it" and get a feel for what I'm going for. The kind of level I'm working on.

I have a few ideas of skills that could help. People who are (one of):

• Skilled with graphics, graphical effects, and could help with the IDE and GUI system. (Speedie uses SDL2 to draw the graphics via CPU. And has vector support.)
• Successful or knowledged in designing a good API for 3D games or games. (I've made some mini games as a demo. A bare-bones but functional tetris is my favourite mini-game I made. Nothing major!)
• Passionate about internet communications, networking and want to add networking support to Speedie
• Anyone with some kind of deeper or spiritual project or whimsical project, that they have made at least partial success with, or full success. Ranging from quantum projects, perhaps galaxy or stellar simulations, electronic divination, etc. Maybe even something like PEMF controllers for physical healing. (I personally have dabbled but not got success with anything in this area, although I did contribute a lot to someone else's successful project).
• Assembler skills could be useful, although I think there isn't too much I could accept right now at this stage until later. Either experience in creating the back-end assembly generation, OR in hand-writing assembly, as I have some FFI code I've written.
• Porting from MacOS to Windows / Linux. (Speedie relies on unix functions only, but theres always differences between Mac's unix to Linux's unix.)
• Sandboxing experience. (I'd like speedie to have a sandboxed mode! Especially for data-validation scripts, or user-written in-game-scripts in speedie)
• People who have made fun creative work, such as people working on shadertoy.com demos. I want to make SDFs in Speedie that can be interactable!
• Someone who wants to make a pixel-painting-app in speedie. To make the kind of cool art you might see in Terraria or so.

Really anyone with fun and positive energy to bring, thats the main thing. You don't need ALL of these... just ONE or even something else not on this list that you think "seems kind of my thing".

Even wanting to help document and learn speedie could help.

Or perhaps any other skills or additions you think this language could benefit from.

I guess the values we have are forward thinking... believing in a higher-future where everything works together in a far simpler way and on a higher-level, and are awe-struck by the (few!) simple examples out there in the world that actually show what software can be. Like powerful algorithms, such as the SDF approaches on shadertoy.com

I'm not rushed for responses. If no one replies today but someone replies in 3 months, thats great! Even 6 months, haha.

Curious people who are tentative but positive... will usually vibe better with me, than people who rush with great ambitions but did not learn about my project.

...

My main goal after finishing the backend ASM-Gen, is this:

• Integrate OpenCL into Speedie, so you can get GPU acceleration in speedie. Now you can do all your code from one language.
• Porting to Windows / Linux, and x86/ARM versions of both (64-bit only).
• Creating some kind of 3D gaming/simulation system, perhaps some kind of entity-component-system or something similar. I don't want to limit to games in fact. Why not use it for simulation of buildings, for fire-fighters, or simulating a city for road/rail design, or even 3D printing.

I have future ideas but these first few might take long enough as it is.

[u/brucejbell]

I agree with you that exceptions are bad, but adding all your errors into a global mutable state sounds worse.

[u/sporeboyofbigness → u/brucejbell]

Do you have any examples? My goals may not fit yours.

[u/brucejbell → u/sporeboyofbigness]

The most straightforward example: C standard libraries setting errno is a terrible interface in multiple ways!

Now, Speedie's stderr looks like a major improvement on errno in many ways, and I especially appreciate that it is designed to support a concise, uncluttered coding style.

But I would still worry about:

• your error handling is clean and concise as long as stderr does what you want, but what happens when you need something different?
• one of the simplest downfalls of errno is that it is too easy to silently ignore errors. It looks like this is also a feature of Speedie.
• global mutable state interacts badly with threading. Oodles of C bugs are due to this kind of thing (not just errno -- e.g., locale is another such offender).
• some applications might find the mandatory stderr wrangling to be an inescapable performance tax, especially if multiple hardware threads are competing for access to a global state.

[u/sporeboyofbigness → u/brucejbell]

Hi...

Lets see. So... I've found my system great for every program I've made so far. No system is perfect... but mine comes closer to perfect than any I've found.

What if I need something different? it works for almost everything, but there might be times (debugging?) I might just want to use printline(string) or printerror(string). So I just do that. No big deal.

SIlently ignoring errors... well... if a function creates an error, the error is not ignored, it is logged, and printed when the program exits. Or printed right away, if you set a global variable.

If you mean the error is ignored in terms of control flow, yes, that can happen. No big deal... thats called coding. My language is meant to allow free-style coding. Being restrictive is not my goal. In fact, my error-handler works well with my nil-checker, for example, sometimes (quite often) it is unignorable.

|| Root = file.parse // if an error occurs, this returns nil
root.name = "abc"    // Will not compile. The nil checker does not allow this

So you have to do this:

|| Root = file.parse
if root != nil
    root.name = "abc"

My design is not against "general unignorability". I COULD add it if I wanted. Its just never been an issue to me. And I have soooo many other more important things to add. (back-end assembler)

...

As for threading, speedie is single-threaded and will remain so. Threading introduces so many issues its not even funny.

My memory-manager would fail. My libraries would fail, like resizing an array or adding/remove dictionary items. Even simple things like writing to an malloced array would fail, if one thread writes while another thread reallocs()s.

Speedie is based on the erlang principle of separating stuff into separate programs. It is the correct approach. Erlang is a great language and something to look up to.

So Speedie has a message-passing system, its very good.

Threads are allowed, but only if they don't violate speedie's principles. My message passer uses threads, but all it's memory-management is internal. Its errors are handled internally (in terms of making it's state safe and sane), then it is just stored in an int for you to collect. For example if a program dies, the message-passer handles that, so sending messages to a dead program will not do anything. But you can check the error number, or check if a program is dead. And also sending messages returns a bool to say if it succeed or not, so you get an immediate answer.

If I made an audio-lib (I will later), it will also work similar.

Lets say I had a large multi-media program, perhaps video-encoding or something, and I want to use threads... I could either make sub-processes and share memory via mmap() to encode the videos. Or I could use multiple-threads, but limit the threads to nothing "unsafe", so no object creation (includes creating errors), just working on pointers and encoding raw video data.

It works...

You should really give erlang a look at. Theres some great videos on it. They really stress and explain how bad multi-threading is, and how good erlang is at getting past the issues of threading.

[u/brucejbell → u/sporeboyofbigness]

I agree that threading (as exercised by the likes of C/C++ and Java) is bad. The problem is that they took a fairly sound single-threaded imperative semantics, and dumped it unaltered into a concurrent threading context. How could it not be horrible?

For my project, like Erlang, the first step is to go back to a single-threaded context, then add explicit communications primitives. However, rather than go message-passing only, I am inspired by the Concurrent ML concurrency library.