New Meta language released for Windows, Apple Mac, Linux, FreeBSD, NetBSD & OpenBSD
https://language.metaproject.frl/#get
posted by: Kaj de Vos 25-Jan-2022/18:42:40-8:00
Very interesting. Thanks.
It's not at all clear to me how you would run or use this in Windows 7.
At all.
Could it be possible, since it’s written in rebol that you could write a GUI where you run a rebol program and then pick the program to compile using an already installed rebol???
I mean how do you run a "com" program on a command line in windows???
This brings up a point. Full time programmers think that everyone should use a command line because it’s faster, and it is, to full time programmers. How many commands are there to do everything needed on a command line?? A bunch and no one, no one that is not a full time programmer or spends all day doing this will ever remember all these. Nor are they interested in learning because it’s of very little use to them. It’s like have to learn to rebuild auto engines to drive a car. No one does that, or the numbers are extremely small.
I’m old enough to have programmed FORTRAN on original IBM PC's in DOS. And I hated every minute of it. Every time I had to type in along sequence to get to some directory or do some sort of action I had to look it up in a book that I had to carry around. It seems to me that the single greatest computer progress in history happened when you had a GUI where you didn't have to look up commands. Sure it’s fine if you do this all day but for I bet 99.999999 or many more 9's percent of the population they hate it. They and I are just not going to learn all these commands to fool around a little to mess around a little with programming.
Maybe this is what you want to self select to only a small group of people?
I think one of the single greatest things that rebol did was make throwing together some sort of GUI for programs easily. It makes learning the rest of it palatable. Most GUI programming takes an enormous amount of drudgery and study to do it.
Now if you are programming compilers you think this attitude is buffoonery, yet most people do not program compilers and while this may totally cause your brain to jump for joy at the complexity and challenge it does nothing for most people. So making a program just for administrators and people who use command lines every day is cutting off a super vast, enormous amount of people.
I think and told Doc that his idea that abandoning the AGG library and rebols GUI for the idea of using the underlying libraries for each OS was a mistake. He did not like this. I'm fairly sure he thinks I’m a trollish annoying idiot. I didn't say this to piss him off it's just that I've done some looking at programming GUI stuff and it’s a real pain in the ass. I want him to succeed. Look at how long it has taken him to get RED on just Windows going and he is not even close to finishing. The GTK3 stuff for linux and the BSD's are not finished. Only now has someone made a GUI for RED, (Spaces cross-platform GUI) and he says he will prioritize this year.
Think if he had either written a graphics library like Spaces or even better just found a way to use the lowest level of OpenGL that he could use successfully and link to it while using skinning to simulate the different operating systems. I think he would have been way farther along. And RED would always have a GUI sub system built in that worked.
Later he could actually use the OS libraries after he got RED going but the problem is these libraries are very hard to deal with when you are setting up to build your own GUI on top of them and then..they are a moving target. If you used your own library or the lowest level or OpenGL then you have something that is always there and with OpenGl something that will most likely be graphics driver accelerated on most every single graphics card or processor that comes out for a long time.
One other thing there's a guy named Maxim Olivier-Adlhoch that worked on a GUI for rebol called "glass" that sounds very, very much like the reactive GUI that Doc is calling for RED. I don't think it’s finished and while I: not sure I think there's a different, earlier, later??? version, called Glayout. While not complete, it might at least be looked at or use some of the code to do what's needed. He workled on this for over ten years. I can't say if he accomplished all he set out to do but the ideas he used to organize it seem to be very promising.
Max releases Glass!
http://synapse-ehr.com/community/threads/max-releases-glass.169/
Glass link
http://www.pointillistic.com/open-REBOL/moa/files/glass-distro-R1.zip
http://www.pointillistic.com/open-REBOL/moa/steel/glayout/index.html
posted by: Sam the Truck 13-Feb-2022/22:55:45-8:00
> It's not at all clear to me how you would run or use this in Windows 7.
Press keys "Win + R", "c", "m", "d" and "Enter" :)
> ...It seems to me that the single greatest computer progress in history happened when you had a GUI where you didn't have to look up commands...
Now users are looking for icons :)
Writing "winword my_doc.doc" is much easier and faster than clicking "start", "programs", "office", "winverd", wait for it to load, then "file", "open", "my computer", " documents", scroll to the required file...
> They and I are just not going to learn all these commands...
Nobody forces you
> ...make throwing together some sort of GUI for programs easily...
Try HTML Application (https://en.wikipedia.org/wiki/HTML_Application)
> ...cutting off a super vast, enormous amount of people...
Okay. You can cut off. :)
> ...I'm fairly sure he thinks I’m a trollish annoying idiot...
I'm sorry, but he's not alone in this.
> ...(many letters about Red)
Memories of Fortran in DOS are clearly not enough to criticize modern programmers, just as Aristotle's treatises are not enough to criticize the current work of a virologist.
posted by: Sergey_Vl 14-Feb-2022/5:27:05-8:00
Thanks for the feedback. I have been wondering how familiar Windows programmers are with the command line.
A Windows .com program is the old format of what is now usually an .exe program. To run the Meta run.com program, you open a command line / terminal window in the folder where you put run.com or you go to that folder with the CD command:
cd path\to\Meta
Then just enter
run
This will output some brief documentation, where you can see that you can run a Meta program like this:
run example.meta
To have this work, you need to fulfill the installation requirements on the Meta website. Do you get an error message?
I actually started out as a GUI person on Windows. I know what you mean, because it took me a long time to change myself into a command-line person on Unix. I think both command lines and GUI's can be improved.
Meta is currently a command-line program only because that is less work to make. I will make it progressively easier to use over time. The Meta compiler client is actually written in Meta. To give it a GUI, a GUI needs to be developed for Meta first.
I was there when GLayout and Glass were developed. I was always a fan of AGG and I thought Glass was very exciting, but they both stalled eventually. Glass was much more reactive than Red's GUI, it was full dataflow. AGG and Glass seemed superior to native GUI's, but users always complained they stuck out. I think this dichotomy can't be solved and ideally, you need to support both.
I have some ideas for GUI's for Meta. I will present them later, but I will need support from the community to implement what they want most.
posted by: Kaj 14-Feb-2022/8:37:17-8:00
Thanks for your reply. . My apologies for fostering a Dunning-Kruger troll effect. No matter how trollish it might seem, I still think it absurd that you need a book or need to memorize commands to use computer programs. It seems to me, however wrong, that interfaces should have contained within them the data need to use them.
"...Meta is currently a command-line program only because that is less work to make...."
Yeah I get that. Perfectly reasonable.
"...Now users are looking for icons :) ..."
I said that but it's not necessarily what I meant. What I mean is some listing of what things are, commands and basically how to use it. It's been done in a simple manner before.
I happened to remember an old DOS program as an example. "Sidekick"
https://en.wikipedia.org/wiki/Borland_Sidekick
You could list DOS commands and what their function was with this(The link shows all the other crap it did I only used as a sort of file and function explorer). There's some 100 DOS commands. So even some simple archaic OS the normal person can't remember all the commands.
posted by: Sam the Truck 29-Mar-2022/17:13:42-7:00
For all programs user need remember one key (F1) and one command "help" :)
posted by: Sergey_Vl 29-Mar-2022/17:50:09-7:00
I can see both sides of the argument.
There have been many attempts to get rid of programming and programmers, but they haven't been very successful. Programming is inherently hard, but I do agree that it is usually made more complex than it should be. Hence Meta's distinction between essential and accidental complexity.
Meta is a traditional, text-based programming language. By definition, that means your power depends on how many words of the language you can learn. The REBOL design reduces that problem by defining a series of patterns that unify interfaces.
Discoverability can be improved to aid learning. Over time, I will implement similar commands in Meta that REBOL has to list available words.
Further, Meta tells you when it recognises a known REBOL or Red word or short sentence that is written differently in Meta.
posted by: Kaj 3-Apr-2022/11:03:34-7:00
Sam, I made it even easier to use Meta. The language can now run in web browsers, and here is a web console:
https://console.metaproject.frl
posted by: Kaj 16-May-2022/13:52:22-7:00
Thanks!
I'm reading the documents on this page
https://language.metaproject.frl/#get
and the link to
High School Computing: The Inside Story
http://www.trollope.org/scheme.html
is gone. Here's an internet archive copy that works
https://web.archive.org/web/20200206234436/http://www.trollope.org/scheme.html
"...AGG and Glass seemed superior to native GUI's, but users always complained they stuck out. I think this dichotomy can't be solved and ideally, you need to support both..."
I pointed the guy who did Spaces for Red to Glass, and he didn't like it. I told him about it because he asked for a method to do exactly what it was Glass said it did. Provide reactivity. He's still looking for an elegant way to do this. If you come up with something, I’m sure he would be interested. Maybe both of you could brainstorm about it.
"...I have some ideas for GUI's for Meta..."
The programming for this is over my head but I do like to look at stuff that others have done and try to get a general understanding of what they have done. It would seem to me you couldn't go far wrong by looking at what QNX did with their Photon microGUI. They put on a floppy drive
1. Voyager Web Browser (Full HTML 3.2, frames, tables, etc.)
2. Voyager Embedded Web Server
3. The QNX Realtime Operating System
4. TCP/IP (with PPP including CHAP/PAP support)
5. Photon microGUI Windowing System
6. A "remote control" device to simulate a TV set top box
7. An Internet Phone Dialer
8. A Graphical File Browser
9. A Graphical Text Editor
10. A Vector Graphics Animation
11. Over 180 Kbytes of HTML and image
Wow. I had a copy of this at one time. It was very responsive. I think I ran it on a Pentium II or III, something like that.
https://marc.info/?l=freebsd-chat&m=103030933111004
Their GUI was a message passing microGUI that,
"...GUI as a graphical "microkernel" process ...", like their real time OS.
Their idea is very interesting because they have one small program to do one small specific job while leaving all the drawing to other programs.
"...The Photon microkernel runs as a tiny process, implementing only a few fundamental primitives that external, optional processes use to construct the higher-level functionality of a windowing system. Ironically, for the Photon microkernel itself, "windows" do not exist. Nor can the Photon microkernel "draw" anything, or manage a pen, mouse, or keyboard.
To manage a GUI environment, Photon creates a 3-dimensional event space and confines itself only to handling regions and processing the clipping and steering of various events as they flow through the regions in this event space. ..."
This sure worked for them. QNX is used in sorts of very power and memory constrained systems on cars and other devices. Maybe this idea could be copied. Here's an article on it.
http://www.mikecramer.com/qnx/qnx_6.1_docs/neutrino/sys_arch/photon.html
As for graphics for the GUI, it seems to me that QNX has this figured out. They use OpenGL. There's a lot of GUI libraries. The major ones being OpenGL(maybe now Vulcan would be better), Microsoft DirectX, Apples graphics, GTK and KDE mostly. It seems to me that lining up every single one of these to equate to Draw and VID commands or even the major ones seems a hopless task in complexity. Not to mention they are a constantly moving target. What if Vulcan or OpenGL alone were picked and then the widgets were skinned? If there was a drawing program built in to change all the GUI elements on the screen in all areas of the program, then it would seem a far easier task to use it instead of all this complexity. There's just too many libraries. Better to make one a very flexible one that someone, not a GUI guru, could tweak a bit with a built-in Adobe type vector paint, drawing, program and skin it into whatever they wanted. That way no matter what changes they made to windows, requesters, whatever you could draw it's outline, shade it however you want and then save it while leaving all the underlying VID commands exactly the same. You could even literally copy all their boxes, requesters, etc. and make vector or bit mapped copies of each and shoehorn them right into VID.
The QNX Realtime Operating System
http://home.iitj.ac.in/~saurabh.heda/Papers/Survey/Report%20on%20%20QNX%20-2007.pdf
Now I know Doc thinks I’m a troll, Sergey_Vl thinks I'm a troll but it's damn difficult to argue with the logic that in the "long term" that in order for Red, Meta or whatever language having a set library, skinnable GUI of some sort is a big advantage. Try to tell me that at the minimum linking to the three major OS GUI's with hundreds of megabytes of code in each of them is easier than having a set library that will stay around.
I think this is a difficult argument to make. Doc himself says,
"...Rebol2 for any faults we can point out, still works to this day (except in cases where the world changed out from under it, e.g., in protocols). It was self-contained, and relied only on what the OS (Operating System) provided. As long as OSs don't break a core set of functionality that tools rely on, things keep working. R2 had a full GUI system (non-native, which insulated it from changes there), and I can only smile when I run code that is 20 years old, and it works flawlessly....".
And even if you do manage to tie VID commands to the underlying OS libraries, you will never be done because their financial model is to make everything obsolete and constantly change the software to sell new stuff. They HAVE to do this because it's the only way to keep up profits. You can never keep up with the amount of resources they can throw at the graphics libraries. Every few years you are right back in the place where you started with no GUI because they stopped supporting the libraries.
Anyways I babbled enough.
posted by: Sam the Truck 26-May-2022/6:15-7:00
Thanks for the high-quality feedback! I, too, studied all these things a few decades ago, but it's good to be reminded of them now that Meta gives me the power to do something about them. Thanks for the links, I will keep them in mind.
Yeah, QNX is legendary. But Syllable is in a similar league. :-)
Obviously, having started my own language project, I don't agree with Doc's project management. It was always difficult to put my finger on it. We agreed on principles, but not on execution, so it took me a long time to leave Red. Some things in Meta are the same, and some are different.
REBOL tried hard to be its own world, and the real world rejected that. It doesn't do much good to almost work after twenty years. The world changing SSL still means you don't work anymore, and the GUI taste of people having changed means they reject it. It's a good engineering principle to isolate parts, but the world can't be ignored.
Thanks for the heads-up about the broken link! I replaced it. That article must have been there for decades, but the moment I link to it, it vanishes...
Xanadu was going to fix that, but it tried to replace too much of the world...
The world favours incremental change. REBOL tried to change too much at once, and Glass tried to change too much at once. Reactiveness in Red's GUI is easier to use because it applies to the default GUI, but it also doesn't bring a large improvement. This is an eternal trade-off. My semi-solution is to make Meta so flexible and productive that both strategies can be attempted, like C can be used for anything, and the world can decide what it wants. I will provide options, and support from the community will decide the direction.
posted by: Kaj 26-May-2022/9:26:03-7:00
"...Syllable is in a similar league. :-) ..."
Ahhh I didn't know you were responsible for that. You must know far more than I do about it.
Maybe I'm flogging a dead horse but I want to be absolutely sure that I get people to understand the meat of my point with the deficit of repetition.
My point in needing some sort of GUI for RED is that no matter what there would be some sort of GUI. As above, Rebol still works.
I'm in NO WAY opposed of GUI's based on the OS. Not a bit "but" if some sort of library like AGG was used and written in Red or Meta. It would always be there. For acceleration link it to the lowest form of OpenGL which is not going away any time soon I suspect.
Let's be cognizant that there's no reason at all that Rebol or R3 could not have substituted OS graphic libraries for AGG but...no one did it. Why not? Human nature. Smart people don't want to drudge away repeating the same thing over and over so no one is going to "waste" their time doing all this drudge work and I expect the exact same thing will happen to Red "if" he never makes any sort of self contained GUI that only depends on Red or Meta also. Sure you may get it going but 4 years from now the various OS will come out with the "latest, greatest, new fangled" graphics library and...no one will be willing to slog away at porting all this code to fit it. A lot of work. I supect the very long time Red is taking to get to 1.0 is all this GUI OS work that takes forever.
It would seem if you had a skinable graphics system combined with a compositor that you could mix all sorts of graphics for the GUI. Could be bitmap, postscript, jpg, whatever, then whatever GUI they change to could be skinned to fake it to some extent. Now I'm not fooling myself that I'm able to do this and if I was to slog away at it I don't have the resources to feed and keep a roof over myself while doing so. I wrote this after reading some stuff on 3D printing which interest me. Seeing this prompted me to write this. A 3D printed aero-spike rocket engine.
https://3dprintingindustry.com/wp-content/uploads/2022/05/EOS_App_Aerospace_Hyperganic_04-1536x1024.jpg
The point being I do not have to have the capability to make this in order to see it as something beautiful and satisfying. I see Rebol and Red and Meta as beautiful and satisfying and feel that they will fade away unless they have some sort of GUI that can persist into the future. That doesn't depend on the various OSes to provide graphics. I'll shut up about this I know people are tired of hearing it.
posted by: Sam the Truck 6-Jun-2022/23:54:35-7:00
Cool engine indeed.
All the important issues are in your post, but they compete with each other, so it's a balancing act.
The most important point is to feed myself. When I die of old age, I will make sure that my projects are in the hands of the community. But if I fade away before old age, my projects will fade with me. Therefore, I made sure that I could use Meta myself from very early on. If users of my projects make me a living, I can work for them, but if not, I will only implement what I need myself, people will have to be satisfied with these free gifts, and all talk about what else they want would be pointless.
If you don't have the means to fund what you want, you can still campaign for others to do so.
Other languages keep up all sorts of bindings because they have funding to pay people for the drudge work. If a language is not made popular, everything remains a problem forever. If it is made popular, its upkeep is a small price to pay for the world for the productivity gains.
It's scary in general how the whole world increasingly depends on everything else keeping working, and we are currently experiencing the repercussions.
There is not one cause of Red's glacial pace, it's a combination of factors. I designed Meta to solve all of them.
I certainly know what you mean by dependencies, and I have a strong goal to limit them. A decade ago, I wrote bindings for Red to extra GTK+ widgets such as a web browser view and map views. Within mere months, they ceased working because new versions of these widgets broke compatibility with their own simple interfaces.
It seems that OpenGL is not basic enough to guarantee the future. It is being replaced by competing standards. Currently, you have to target Vulkan, Metal and DirectX for good performance.
To guarantee the future, you have to be more humble, and Meta already has GUI capabilities for that. As long as there are Atari emulators, Atari GUI's you write in Meta now will run forever. :-) When there cease being Atari emulators, the world will have much bigger problems.
The minimum dependency for Meta is currently an Atari 2600, without operating system.
That said, my current option is to implement bindings to SDL and OpenGL ES/WebGL. I already did that for Red. Currently, I don't plan to write a custom GUI on top of that, but it's certainly an option.
posted by: Kaj 7-Jun-2022/6:19:47-7:00
Hi Kaj,
Congrats on all these wonderful accomplishments. This is truly a great project to follow.
Quick question:
- The console. Is there any JS interop involved, or is it a CGI implimentation?
- You mentioned a resulting webapp that can be copied. So if I use your latest code for 'Mortal Coil', is the display updated incrementally, with error feedback?/or does it provide a final link? Maybe this is expecting too much.
(Sorry, haven't had time to check it out yet)
I know you are very busy, maybe a broad description of how you got the console working would be nice.
posted by: Daniël 21-Jun-2022/9:11:08-7:00
Also check out:
https://redbean.dev/
It is remarkable what she accomplished, and lots of practical use cases, I think.
posted by: Daniël 21-Jun-2022/9:15:26-7:00
Thanks, Daniël!
The Meta browser target and web console took a few weeks, but I could use parts for the console from my old Try REBOL site, where, around a decade ago, you could run REBOL 3, R2, Red and Boron programs on my (Syllable) Server (and compare them). The Meta web console is the next generation, where you can run programs actually in your own browser.
The Meta browser target generates C and then uses Emscripten:
https://language.metaproject.frl/#web
Currently, I don't let it compile to WebAssembly but to JavaScript. This compiles faster and supports older browsers.
The web console, and the new forum, are Single Page Application web apps that communicate with the server through API's. For an SPA to do that, JavaScript is needed. I'm currently using AJAX. In the future, WebSockets could be used to make it slightly more responsive and efficient, but AJAX is simpler and compatible with older browsers. Several people from the REBOL and Atari scenes use such older browsers. :-)
The working of the SPA clients can be seen in their HTML and JavaScript source code.
Everything is almost as simple as possible. The server processes requests in CGI programs, written in Meta and REBOL 3. Using very simple line-based text data formats means Meta, REBOL and JavaScript can communicate. In the future, a full server could be implemented to make it more efficient, but using existing compilers is a CGI-style activity, anyway, and CGI programs in Meta are much more efficient than in many other languages.
Meta does very little memory allocation, but does no garbage collection yet. Currently, a web server in Meta would probably leak some memory. For CGI programs, this is no problem, because the operating system cleans up.
When you run a Meta program in the web console, you are directed to the generated web page. You can copy, inspect and change this like any other web page. There are a few parts, so you have to look through it for the links and download them. I will probably add an easy download option later.
Some Atari people think their web browser can run Atari programs. :-) Perhaps, but I didn't announce an Atari emulator for web browsers. The browser is just a platform, and you have to program to its abilities. For example, you can use the cross-platform examples I published. There are no browser-native bindings yet.
I wonder if you realise how right on the mark you are with RedBean. The current Meta compiler for PC platforms generates APE executables. If you write a web server in Meta, it would automatically be quite similar to RedBean.
posted by: Kaj 21-Jun-2022/11:17:30-7:00
Kaj, thanks for the detailed answer.
I was trying to run a few examples through the console, but the compiler window only resulted in a endless wait, and the browser (Chrome) timing out. Can you please provide a moderately detailed code sample to see it in action? Any restriction on what can be compiled from Windows 10? I am very curious....
posted by: Daniel 22-Jun-2022/13:40:02-7:00
It seems that you entered an Atari 8-bit program, anyway. That's a valid Meta program, and Meta adapts to the platform, so Meta did its best to generate a web browser program, hence there were no compilation errors.
But again, unless you have a very special web browser, it can't run programs that are meant for an Atari 8-bit. In this case, it just hangs. Nothing to do with Windows 10.
As I said, you can use the cross-platform examples I published, which are linked from the web console.
posted by: Kaj 22-Jun-2022/17:36:45-7:00
@Kaj
Sergey_Vl asked here,
http://www.rebolforum.com/index.cgi?f=printtopic&topicnumber=45&archiveflag=new
Sergey_Vl 20-Jun-2022/6:51:44-7:00
"...Kaj, if Rebol is always your favorite then why did you take up Meta instead of working on Rebol3? ..."
Your answer
"...But I was already working on my improved design, that solves problems of both REBOL and Red..."
Is there any way to describe to a mid-wit like average engineering intelligent type person what it is exactly or in a big picture sort of way you are doing differently to make such a difference? You seem to be using the same sort of structure and syntax as Rebol. If the internal representation, you use, or the way you parse this this syntax is different, could you not make a separate compiler of sorts instead of starting over?
It seems Hostile fork is doing the same thing by rewriting the internals of R3.(though I’m sure what you’re doing is different).
(I hesitate to bring things like this up because people know so much more than I that...it may well be just pointing out the obvious. but, just in case)
Someone did a kinda, sorta thing like you are doing and called it Ni!,(I really like that name for a programming language), then Spry. It was written in NIM which seems interesting. It seems a lot of things are converging on some of the ideas of Rebol and LISP. It's interesting he can get so much out of such a small amount of code. Maybe? This will be useful.
http://goran.krampe.se/2015/09/16/ni-a-strange-little-language/
posted by: Sam the Truck 23-Jun-2022/23:54:26-7:00
I tried to explain it here:
https://language.metaproject.frl/#how
One of the things I always liked most about REBOL is its level of abstraction. A quarter century ago, I was specifically looking for the highest-level language I could find that was still practical, to make the biggest jump forward. REBOL code tends to be formulated in a way that allows many, completely different implementations, even though only one method was available. Meta is such a completely different implementation. I could have kept the code you write identical, but I chose to make small changes to optimise for Meta's purposes and fix some long-standing problems.
I evaluated Ni/Spry at the time. It's in a class of Smalltalk-like language such as Io a decade before it, that I was partial to when I needed an open-source alternative for REBOL.
REBOL. Ren-C and Spry are interpreters. Many things can't be done in interpreters, because it would kill performance even more than they already do. The past two decades were an era for new, interpreted languages, because faster hardware made them feasible and they fixed the long edit-compile-run cycles of compiled languages.
Now, hardware is fast enough to compile programs in around the time it takes a fat interpreter to start up, and we see a new generation of compiled languages to reclaim the efficiency.
Unless you mess it up, such as traditional compilers that became ever slower every year in the era that they had no hope of competing with the ease of development of interpreters, anyway. Or Red's compiler, which was always so slow that it necessitated an extra interpreter.
Meta is a compiled language for this new era, that can do much more than an interpreter, and was designed to compile fast. There was no point on basing it on one of the older works, because they are completely different under the hood. I considered many possible combinations with the existing works, hoping it would ease my work, but it always turned out it would only complicate it. The only thing that helps is writing the first generation of Meta partly in R3.
Joe Marshall, the author of Sherman, the first ever REBOL compiler, planted a lore in the scene that a REBOL compiler is not really feasible, because the combinatorics of the language design lead to code explosions. That sounded logical, but Red proved that a practical compiler can be done. However, it did it by basically only compiling the interpreter loop, avoiding the code explosions. This causes compiled Red code to be as slow as interpreted REBOL code, and interpreted Red code to be even eight times as slow as REBOL, on average.
Meta is a language properly designed for compilation, with a proper, fast compiler. It does mean that the language can't be as small as interpreted languages such as Io and Spry. The phenomenon of code explosions is real, but it can be managed. Meta keeps them in the compiler and largely out of the compiled result, which is exactly what compilers are good at. It's a lot of work, and it does mean that Meta is like Swiss cheese until it is more finished. I have to fill the holes in the order that functionality is needed.
posted by: Kaj 25-Jun-2022/11:03:57-7:00
Thanks. I think I do get the basic idea of what you are doing.
"...The user-facing front-end language is a REBOL dialect. Its type system is a combination of the high-level type system of REBOL and a safe form of the type systems of medium-level languages such as C and Pascal..."
I expect this is a key part of it. A lower level structure while using Rebol syntax as a dialect built from this lower level structure. I know spry is different but I can see how he is sort of using some of the same type ideas but using Nim as the lower structure, lower level.
Maybe this is a stupid question but have you thought about using Nim as the lower level instead of writing all this compiler and other supporting infrastructure. If Nim does what it says, it's most impressive. The License for Nim is,
"License
The compiler and the standard library are licensed under the MIT license.."
So anything you don't like you could change however you wished.
And I perfectly understand that you might just want to do your own thing just...because, that's what you enjoy. This however is different from getting a language going in the shortest amount of time with the most completeness.
"...This is due to REBOL's monolithic interpreted execution model, which makes it a relatively slow language, and due to its high-level type system, which makes it memory-hungry and does not support the data types of external systems..."
The writer of NI and/or spry commented on this being a problem. He didn't like all the different built in data types.
Thanks for the reply while I’m sure I don't understand the details I think I have a little more of a general overall view. Sometimes I have trouble understanding things if I don't have some sort of "large scale" model that shows what’s going on.
posted by: Sam the Truck 26-Jun-2022/23:40:53-7:00
Kaj,
I wish I could take part more. I'm watching and appreciating everything you're doing. I look forward to the day when Meta is mature enough to use as the only language/tool needed to build full stack web apps...
posted by: Nick 27-Jun-2022/16:47:24-7:00
That is perfectly understandable. I, too, am always looking for the big picture, and that is what attracted me to REBOL. Many people in our field are very good at details, but not so good at the big picture. Both are needed to avoid the many pitfalls.
Yes, to achieve performance, a language needs to compile high-level constructs down to low-level ones. REBOL hardly does that and postpones almost all decisions to runtime. I think Carl was under the influence of his colleague Alan Kay, who said the languages of the future should bind as late as possible. That's fine for easing your language implementation work if you expect ever faster hardware, but it's not competitive with faster languages, and it doesn't serve the long tail of small hardware that doesn't go away, but only becomes more ubiquitous.
Meta is completely designed to achieve results as soon as possible by making the best use of existing sub-systems:
https://language.metaproject.frl/#goals
https://language.metaproject.frl/#features
https://language.metaproject.frl/#how
This does not mean all existing sub-systems or just any system. To avoid the problems of contemporary software development, you have to approach your target as close as possible to minimise mismatches.
The current version of Meta is written in REBOL 3, because that is close to my high-level targets. REBOL is designed as a tool for language implementation. It's great for writing its own successor.
The universal language for abstracting low-level machines is C. The abstraction it uses for operating systems is the standard C library. Almost all operating systems use or at least provide these abstractions. Therefore, Meta has a back-end that generates C and uses the C library.
Even though Meta is an extensive language design, it is currently a thin layer between R3 and C. Most of the development time is absorbed by forcing C and the C library to adapt to REBOL principles. Meta could develop much faster without C, but it would run on only one platform, for example the native back-end for Atari 8-bit.
Nim is interesting because it does something similar to Meta, but it does not provide the facilities of either REBOL or C, therefore it is neither suitable for the high-level nor the low-level parts of Meta.
If you think Nim provides some advantage, you could write a back-end for Meta that generates Nim code. The back-end would still be written in R3, or Meta in the future, and you would have to duplicate everything in the C back-end in Nim and Nim's runtime libraries. The result would be much less universal than the C back-end.
R3 and most C toolchains are open source. I can modify them when needed, and I did so with the CC65 toolchain for 6502 targets. A few of my patches went into CC65, and I am still patching a few that weren't accepted by the project.
The problem with REBOL's type system is not that there are too many types, but too few. Meta has many more. REBOL's concept is mainly to distinguish the data types that have unique lexical notations in human language. That is great for matching the cognitive abilities for humans, but machines and compilers need more types for optimisations. Other languages and libraries do have them, so REBOL also has a problem interfacing with those.
I'm no stranger to impatience, but I think Meta's development pace and reach are OK. It's certainly conforming to my stated goals and strategies. When Red was one year old, it could do "print 1". Meta is two years old now, and it runs popular websites and download servers, custom forums, its own web console, implements its own network clients, can do graphics and sound demos, and is available from 8-bit systems to all the major modern platforms and web browsers.
posted by: Kaj 27-Jun-2022/17:30:39-7:00
Thanks, Nick.
posted by: Kaj 27-Jun-2022/17:32:11-7:00
It's rotten that they're trying to steal your name. I remember when they tried to do the same thing with 'iOS' :)
posted by: Nick 2-Jul-2022/9:06:12-7:00
Yeah, it was a nasty surprise. Their press release looked like it was copied from my website. :-S But it's a common dictionary word, and, any publicity is good publicity. :-)
posted by: Kaj 2-Jul-2022/11:01:10-7:00
Thank you very much for the time and careful consideration of your replies.
posted by: Sam the Truck 5-Jul-2022/9:34:18-7:00
"When Red was one year old, it could do "print 1". Meta is two years old now, and it runs popular websites and download servers, custom forums, its own web console, implements its own network clients, can do graphics and sound demos, and is available from 8-bit systems to all the major modern platforms and web browsers."
I've been following Red development from probably early 2013. 0.1 red was apparently released March 2011: https://www.red-lang.org/2018/01/overview-of-red-development-history.html
I just did a lookup and red's GUI capabilities were announced in March 2016. https://www.red-lang.org/2016/03/060-red-gui-system.html. So five years. At that point I remember being excited, thinking at least full REBOL equivalence within a year, so the remaining REBOL culture could finally pull together.
Boy did I get that wrong! It's now nearly SEVEN years later and there still isn't full REBOL capability. The timeline from June of last year for a final 32 bit version, with IO, has already fallen, it appears, hopelessly behind.
I think the whole thing is sad. So much promise come to so little, so late. Too late, I suspect. I noted Sam's comment above: "I think one of the single greatest things that rebol did was make throwing together some sort of GUI for programs easily. It makes learning the rest of it palatable. ...I think and told Doc that his idea that abandoning the AGG library and rebols GUI for the idea of using the underlying libraries for each OS was a mistake."
I'm posting because I'm curious about where red went wrong? I'm also curious about other lessons to be learned and if you believe you've incorporated those lessons into your Meta?
One thing that has long bothered me is the lack of something like a BNF for REBOL languages. Is there some reason why a formal specification of the core language is not possible? Without that, it seems to me, the rats nest of bugs can (and arguably MUST) go on forever. Without that, how can there ever be a meaningful 1.0 version? It seems like another level of Dante's hell, specially made for hackers!
Does Meta have a formal specification? Please forgive me for not reading all about Meta on your site before posting this comment and these questions. I thought red was finally going to bring some common sense back to software complexity. It has been really heartbreaking to see things get stuck in such a fundamental quagmire. Without limitation, there is no completion. Without something like a formal BNF the structure of the language can never be trusted. Is that necessarily a defect in REBOL Lisps? Is that why all other lisps, I am aware of, need those pesky brackets and prefix notation?
Final question: when do you hope to release a stable (which, as I said, seems to me to require a formal specification) 1.0 for Meta? Again, I apologize if you've already answered these questions elsewhere.
posted by: CuriousGeorge 15-Jan-2023/5:17:16-8:00
Hello George.
Yes, Red was launched in 2011 at my REBOL conference.
Red's planning and execution was always weird to me. It never focused on achieving practical functionality quickly, seemingly assuming there is no competition and people can wait forever. Every time some functionality is contemplated, some complex time path is devised where the functionality first requires a lot of other functionality to be implemented that the designer would like to have. This has also made Red's implementation complex and highly inefficient.
Especially frustrating is that promises are consistently made the other way around. We were going to get highly efficient REBOL equivalence quickly. Later, ever more lofty goals and promises were added, for crypto ecosystems and what not. That would all be great, but not much is ever brought to practical completion.
I thought a lot about that and designed and implemented Meta the other way around:
language.metaproject.frl#goals
The problem with REBOL equivalence is that REBOL 2 was so good and comprehensive that it's really hard to match. Even REBOL 3 failed because of that. At the same time, REBOL has a lot of features that are great for advanced programming, but are not needed often in regular programming. Meta focuses first on the traditional features that are needed most, and that most programmers are familiar with, albeit in different syntaxes.
REBOL's priorities were already out of whack from the mainstream from the start, but this grew stronger over the years, and now REBOL is quite outdated. Red's priorities are mysterious and even out of whack with the needs of REBOL programmers. Meta focuses on making the REBOL principles usable for modern mainstream purposes, a mostly untapped potential.
Meta does not have a goal of strict REBOL equivalence, although it does have a goal of eventually coming close. So the features we want are fairly clear, but the order of implementation is very different, focused on quick practical usability and what users need in practice.
1.0 does not mean much to me. It's a relic from the past when there were no good ways to update software. Meta maximises updates with continuous deployment through a web service:
language.metaproject.frl#features
What's important is that there are features that people need and that implemented features work. So when someone wants to fund something they need, or wants to help implement it, I consult the REBOL catalog of features to see how it could be implemented and balance that with Meta's design and goal of interoperating with other sub-systems. Meta has no version numbers. Perhaps they will be useful in the future when Meta becomes enterprise ready. :-)
A Red contributor wrote a specification for it years ago. I think it's in BNF form or something close. It's nice to have, but it doesn't prevent Red from having many bugs. These stem from Red's complex but primitive implementation and a sloppy work style. REBOL was never that buggy. Meta is working towards becoming a safe language and being implemented in itself. It's type checked at compile time. This is much safer than Red's approach of type checking at run time, even leaving out many checks in compiled code, and writing most of Red in the unsafe, primitive, C class Red/System language. A similar BNF specification would be doable for Meta, but the prevention of bugs is elsewhere.
posted by: Kaj 16-Jan-2023/5:26:01-8:00
Everything in Meta and the Meta project is implemented as a Minimum Viable Project first and extended from there:
language.metaproject.frl#when
The goal is to have something that is usable as quickly as possible. Then from there, it can be broadened to more use cases. Reaching a 1.0 state is not needed and not planned to make Meta usable. The goal is that the supported use cases are always usable. If you compare with REBOL or even Meta's own goals, the language will be incomplete for a long time, but the programs it produces are of production quality:
language.metaproject.frl#state
posted by: Kaj 16-Jan-2023/6:05:41-8:00
Oh, the BNF grammar is still only for Red/System.
Meta has a somewhat similar grammar internally. The Meta compiler is built on a compiler dialect that specifies the language. It's not as clean as a documentation dialect such as BNF, because it needs to do the actual implementation. It plays the same role as YACC and Bison in traditional languages, but it's a REBOL 3 dialect, so it's much cleaner and more suitable for Meta. Eventually, it will become a Meta dialect.
This internal implementation could be stripped down and presented as a specification. However, remember that REBOL is a context sensitive language. Further, Meta is more dynamic than REBOL: it also uses the target platform as context, so the same expressions may compile to different data types on different platforms. This means that the implementation carries some of the specification, so stripping it down to the compiler dialect would loose some of the specification. Turning it into documentation would require some thought, and it would have to retain some code, going further than BNF.
It would also be a lot of work to keep up to date with language extensions and new target platforms, so this is something for the future.
posted by: Kaj 17-Jan-2023/3:17:28-8:00
The Red compiler doesn't have such a compiler dialect, and in REBOL and the Red interpreter the notion is completely absent, because the interpreter makes everything up as it goes, only doing type checking per function every time it encounters one and needs to execute it. Red's compiler is just un unrolled interpreter loop, basically doing the same thing and even leaving out checks that the interpreter does. Red's compiler is already as slow as REBOL's interpreter. Doing all the same checks, it might become as slow as the Red interpreter.
Meta's DO dialect is a fully statically checked Ahead-Of-Time compiler. It can catch many errors at compile time, while still retaining REBOL's free code format. Lisp's parentheses are allowed to structure the code more, but not required, like in Logo. The semantics of the code are the same, as long as you start at the same point in the code. REBOL and Red only know for sure after execution, but Meta knows before execution.
posted by: Kaj 17-Jan-2023/4:11:47-8:00
"...Sam's comment above: "I think one of the single greatest things that rebol did was make throwing together some sort of GUI for programs easily. It makes learning the rest of it palatable. ...I think and told Doc that his idea that abandoning the AGG library and rebols GUI for the idea of using the underlying libraries for each OS was a mistake."..."
I believe this. If you read the above, it sounds a little aggressive, if read wrong. I didn't really say it to Doc like this. I tried to be as diplomatic as I could but I think, possibly, he took it some sort of denial of his ability??? Maybe not, I’m just guessing. The whole reason I said this was because all this GUI stuff for all the major platforms is a massive hairball of complexity. It's just a huge amount of stuff. It doesn't matter how good you are, the VOLUME is enough to drag anyone down. I tried, and failed, to get him to just use AGG or whip up some basic GUI, then work on all the rest as the GUI stuff could come later. Maybe I said it wrong. I never meant to be anything but helpful but...
What Kaj is doing is very hopeful and I thank him for doing all this work for the betterment of us all.
I also think still that a simple GUI like Rebol had is very important. One shortcut, if you just can't stand a single GUI type, might be to have style plug-ins for each platform, skin it, that are nothing but window dressing mostly.
I also think making code that corresponds to each platform library is a mistake in the long run. The reason is this stuff is a lot of work. So let's say you do it anyway. Well then not a few years down the road the OS's will change the whole thing up to something else as they have to have new shiny stuff to sell. Then you are back at zero and would have to start all over again rewriting all the GUI that almost killed you in first place. Just a few people can not do all that. They will get burnt out, and the complexity means no one else will do it either, and the whole thing will die from bit rot. It's not that I’m clairvoyant or smarter than much of anyone. It’s just inevitable that this will happen due to the volume of work needed to keep up with all this. Just the work needed to keep the language going is enough to keep anyone busy.
posted by: Sam the Truck 21-Sep-2023/18:52:45-7:00
After I wrote the above I was looking at resources to program the ESP32 microcontroller, which is impressive BTW, and ran across "Light and Versatile Graphics Library". Amazing, this thing runs on a microcontroller. This shows what can be done with a tiny library.
30+ built-in widgets, 100+ style properties, web inspired layout managers, and a typography system supporting many languages. All these features fit in a very small memory footprint. LVGL runs on any modern MCU or MPU.
Architecture: 16, 32 or 64 bit
Clock speed: > 64MHz
RAM: 4kB + 150byte / widget (~48kB for a UI with a few screens)
Flash: ~100kB for LVGL (depends on the enabled features)
Draw buffer: > 1/10 screen size buffer for rendering
Frame buffer: at least 1 frame buffer in a display controller, internal- or external RAM
Compiler: C99 or higher
Build system: LVGL has no external dependencies. Just copy it into your project and compile it with the other files of your project
And it's MIT license.
posted by: Sam the Truck 21-Sep-2023/21:14:32-7:00
LVGL looks amazing - love that they have the demos working on the web site :)
posted by: Nick 21-Sep-2023/22:33:41-7:00
LVGL looks amazing - love that they have the demos working on the web site :)
posted by: Nick 21-Sep-2023/22:33:41-7:00
Good thinking, an LVGL binding is in the works.
posted by: Kaj 22-Sep-2023/4:07:45-7:00
Oooooooh, that's great to hear :)
posted by: Nick 22-Sep-2023/6:53:43-7:00
Certainly will be a good option. Looks a bit to me that it is used to sell their real product SquareLine. But anyway for as long as the fun lasts a good starting option. Any progress to mention yet?
posted by: Arnold 2-Oct-2023/7:13:11-7:00
This year has been disruptive for several reasons. Progress is slower than normal, but still ongoing.
posted by: Kaj 3-Oct-2023/8:10:36-7:00
That annoying user with his petty program errors. I know all about that! ;-)
Hope things will smoothen out a little.
posted by: Arnold 4-Oct-2023/10:18:06-7:00
In the past year, Meta has changed from a plan economy to user-driven, yes. :-) It's an adjustment, but the goal was always to have users, so all good.
posted by: Kaj 4-Oct-2023/16:14:08-7:00
Kaj, have you seen this?
https://justine.lol/cosmopolitan/index.html
posted by: Nick 1-Dec-2023/9:11:42-8:00
Certainly, the PC versions of Meta are based on APE and Cosmopolitan.
posted by: Kaj 1-Dec-2023/9:19:12-8:00
There's a Llama project getting attention, written in it:
https://github.com/Mozilla-Ocho/llamafile
posted by: Nick 1-Dec-2023/9:45:27-8:00
Nice! I knew she was also doing AI, but this is deep integration.
posted by: Kaj 2-Dec-2023/8:08:21-8:00
|