REBOL Forum

Home Archive Permalink

What I'm using now instead of Rebol

I still use Rebol apps regularly in my daily business life, and it's still my go-to for creating quick utility scripts. But for connecting with modern services and doing everything else I need, I've been using the Python Anvil framework. It's incredibly productive, runs and deploys absolutely everywhere, and is ridiculously easy to learn. With all its modern features, everything just works out of the box, and for the sorts of work I do with it, it ends up being more productive overall than Rebol. I wrote a 150 page tutorial, with 200 screenshots and 22 app examples:

https://pythonanvil.com/

posted by: Nick 16-Jun-2022/11:12:40-7:00

Absolutely everywhere? I appreciate a major new work from you, but I can't seem to find the targets for Atari 8-bit and Syllable. :-)

And you don't seem to have found the Anvil replacement for MakeDoc. :-)

posted by: Kaj 16-Jun-2022/15:09:46-7:00

Thanks for the great learning materials, they were the ones who opened up Rebol for me.
Regarding Python, it is a classic programming language with a large number of libraries, but it is far from the first in brevity :)
Regarding the framework - this year, many users from Russia are faced with the fact that the authors of some frameworks and libraries inserted code into them, which, by determining the Russian IP, corrupts all user data on the local disk, for example, node-ipc (https://security.snyk .io/vuln/SNYK-JS-NODEIPC-2426370) which is a dependency for more than 350 packages... And unfortunately this is not an isolated case, even bookmarks are made in firmware for microcontrollers (https://github.com/arendst/Tasmota /commit/98cbf2587a1a914bbd16996ebb48dd451d3da448) which, if stopped in critical infrastructure (medicine, fire / chemical / industrial safety), will bring a lot of trouble.
But what is no less important is the "gluttony" of frameworks. For example, for a simple calculator (https://calculator888.anvil.app) using the framework, we need a modern browser that requires a modern OS, which requires a modern and powerful PC, as well as more than 5 (!) megabytes of network traffic! 0_o

Although this technology may well be in demand for someone, but I pass :)

P.S. A small wish from the reader - please take screenshots at the minimum screen resolution so that the text on them is no smaller than the printed text of the book, otherwise it is impossible to read the text on them, especially in printed form.

P.P.S. Thanks again for your much needed work!

posted by: Sergey_Vl 17-Jun-2022/0:52:25-7:00

I was going to do the tutorial in Anvil, but screenshots of Anvil, in Anvil, looked a bit like reflecting a mirror in another mirror, so Makedoc 2022!

Sergey, I've also enjoyed doing some work with Lua - probably a bit more appropriate for your tastes. The old Corona game engine was released as open source: https://solar2d.com/ Lua is a compact language, typically with compact interpreter implementations, and it tends to run quickly. If Python didn't have so much support, I'd prefer to live in Lua world...

posted by: Nick 18-Jun-2022/1:20:10-7:00

Python is from the city next to me, and three decades old, so I think it's time they pass the cup. ;-)

REBOL's real-world productivity has deteriorated for many years, since R2 was abandoned. Most things you do inside REBOL are great, but when you need something from outside, the trouble starts. I don't think productivity is a good argument for REBOL anymore, but there is no reason it couldn't be restored.

All those frameworks such as Anvil are built on existing languages, and it could be done for REBOL family languages, too, at least as well.

I, too, evaluated many of those languages over the years. REBOL always came out the winner of the comparison, in any case as far as pure language power was concerned. It's extremely frustrating that this power hasn't been used to maintain real-world usability, so I have taken matters into my own hands.

We can and should fix this, or be forever regretful. Hard comparisons with other systems show that improvements of two to three orders of magnitude can be achieved. And that is without the less measurable issues such as resilience of the world we live in now. It would be bizarre to pass up this opportunity.

posted by: Kaj 18-Jun-2022/9:48:56-7:00

Nik, what version is this Makedoc 2022? Where i can see it? :)
Lua is next in line for me. heard a lot of good things about him. It is used when programming ESP-8266/ESP32 NodeMCU Lua microcontrollers. Solar2D is an interesting engine project, and for Lua there are plenty of crossplatform GUI tools. In general, I will definitely pay close attention to it, especially since the Rebol program containing a line like "lua_lib: load/library %lua54.dll" promises to create an interesting world for life and creativity :)

Kaj, if Rebol is always your favorite then why did you take up Meta instead of working on Rebol3?

For me, Rebol - lamp thing. I don't know if there is a similar expression in English, but I'll try to formulate - Rebol is like a tube amplifier or a record player, against modern amplifiers and CDs / mp3. Modern - without a soul, the sound is always the same and pure, and tube things with a soul, which in the form of harmonics and interference is superimposed on the sound and makes it alive and constantly different / new. In the digital age, the rustling of the player's needle in music, romance and those feelings that I experienced as a child listening to records are very lacking. I even print and rebind books myself, they are more convenient and pleasant than electronic ones, although they are larger and much heavier :)

posted by: Sergey_Vl 20-Jun-2022/6:51:44-7:00

I did work on R3, a decade ago. I wrote bindings as R3 plug-ins to cURL and ZeroMQ, to add missing functionality to R3. First in C, then when Red came, in Red/System and Red.

Then, R3 was abandoned, so I continued with Red. But it didn't fulfill its promises, either, so I had to think about something better to solve those problems.

posted by: Kaj 20-Jun-2022/8:26:43-7:00

"...was abandoned..." By whom? Carl? But it seems to me that this banner was raised and carried first by Atronix, and now by Oldes. I'm just interested in your motivation. Once upon a time, I also tried to make my own programming language based on REXX, because. he was in the system (PC-DOS, OS/2) and processed words depending on the position. A line like "if then>if then=if" was executed correctly, "if" is executed as an operator if it is where the operator should be and as a variable if it is where the variable should be, this allowed simple instructions to be processed with minimal cost in human language. But all the acquaintances left for more classical languages, asm, c / c ++, focal, basic ... For myself, the motivation was only enough for a prototype :( Now I would rather join the development than develop my own, because going into the finished product from scratch takes time and I'm very impatient :)

posted by: Sergey_Vl 21-Jun-2022/7:23:10-7:00

Some people seem to be puzzled by my motivations, so I wrote about them here:

https://language.metaproject.frl/#who

I just need a capable programming language for my work, and nobody has delivered.

REBOL was first abandoned by Carl. Then it and its community were torn apart by competing interests. I had no interest in that struggle, because I had already joined Red. Eventually, most competing interests also abandoned R3. It now feels quiet enough to use it again, and recently, Oldes has continued it in an authentic way. But I was already working on my improved design, that solves problems of both REBOL and Red.

I tried for two decades to use and contribute to an existing language, but it sabotaged my work. There are reasons that so many people left. The common alternative is to settle for some other language, but my designs are based on REBOL abilities, so I can't do that. I used Ruby for the Syllable build system and ORCA for its package manager, but it drags me down.

So after two, three decades I had to make the big decision to roll my own, and now I need to promote it to get the community and funding to keep it going.

posted by: Kaj 21-Jun-2022/9:49:38-7:00

Hi Nick,

Are you using Anvil for any serious jobs (commercially) at the moment?

posted by: Daniel 22-Jun-2022/13:42:41-7:00

@Nick

Thank you for the tutorial.

@Sergey_Vl
"ESP-8266/ESP32" Those things are amazing. It's unbelievable how powerful little microcontrollers are.



posted by: Sam the Truck 24-Jun-2022/0:01:19-7:00

Rebol WASM works fine for me.
I am managing to create a number of rebol apps that run in the browser

posted by: Graham 18-Jul-2022/14:39:16-7:00

Daniel,

Yes, I've got several contracts for large projects and lots of little apps working right now in Anvil.

Graham,

What implementation of Rebol WASM are you using?

posted by: Nick 18-Jul-2022/16:36:25-7:00

Here's an example:

https://geosearch.anvil.app/

That little app is using the Google Map API for geocoding, the typesense API for geolocation searches, and the Anvil API for UI, server, and database functionality. The whole thing is a few dozen lines of code.

https://booksearch.anvil.app/

That one uses the typesense API for fuzzy search.
It's FAST - searching millions of items takes a fraction of a second.

Learning these APIs and implementing this sort of functionality, with front end, back end, database, and multiple third party API integration takes part of an afternoon with Anvil. Deploying to any modern device (Android, iOS, Windows, Mac, Linux, Chromebook, etc.) takes 10 seconds, and users don't have to install *anything* to run the app (with an optional icon on their home screen).

That sort of productivity and power is hard to beat.

It took me one afternoon to port the main guts of my guitar chord diagram maker from Rebol to Anvil, without any previous understanding of their canvas API:

https://chords.anvil.app/

The Anvil IDE is browser based, so I move several times a day between different machines at any location, and pick up exactly where I left off at the previous machines (again, with absolutely no software installation on any machine, and I can be on any Windows netbook or Chromebook I own, on my girlfriend's iPad, on an Android, etc. - it works flawlessly everywhere.

Python isn't as beautiful a language as Rebol, but when it comes to productivity, it's not so much the language that really matters, but all the features of the framework, libraries, connectivity, code examples for every API, etc. which really help with the heavy lifting. Just the database built in to Anvil, and the UI, make most CRUD tasks child's play.

Python lists and dictionaries are great for dealing with the sorts of things I used Rebol blocks for, and I've even written scripts to help port data structures between Rebol and Python. In many ways, things like Python slices work even more beautifully than Rebol's series functions. I find myself doing fewer casting operations in Python (ints, floats, and strings get used for lots of operations), and f-strings make easy work of concatenation. And I can't even begin to fault Python's connectivity and breadth of libraries. The ease with which foreign APIs and complex functionality can be implemented quickly is the sort of practical functionality that makes Python (and Anvil) really productive... and of course a quick Google search will yield working code for just about any task you need to complete. It's hard to overemphasize how important a part all those pieces play in creating solutions for clients.

And it goes beyond that. When the new Raspberry Pi pico W board was released, their was a commercial bootloader to connect an Anvil uplink to it, within days. And with that, I can build little hardware devices with a $6 microcontroller, using readily available APIs that I can connect with freely. That's the value of an enormous community, and why I'm using Anvil/Python.

I love Rebol, and would love to work with it more in the future, but to built apps productively, Anvil is the sweetest spot I've found yet.

posted by: Nick 18-Jul-2022/17:08:41-7:00

Since I'm indulging, I'll point out a few more features off the top of my head, which have made an enormous difference in terms of how little time I need to spend getting things done with Anvil. First, I never mess with any server settings, file uploads, linux commands, etc. - that's all baked into the framework, and you'd be amazed how cutting out toolchain componentry works to eliminate time-consuming work.

Also, sharing code with clients and others who want to work with the code is as easy as sending a 'clone' link via email, Slack, an SMS message, etc., and built-in version control, GIT integration, etc. make it very easy to work on production and development versions.

Having so many composable pieces of software development tooling built into Rebol, back in the late 1990s, and being able to use it across multiple platforms, with only a 1/2 meg executable made it so productive, even well into the 2010's. But without modern web and mobile support, and without the kind of adoption that encourages makers of new tools and APIs to write Rebol example code, and without the sorts of libraries needed to connect with machine learning, AI, modern ecosystems such as Micropython for building hardware solutions, there's just no comparison any more.

Don't get me wrong, I hate most JS frameworks, even the full stack ones. And I hate having to use tools like django+HTML+CSS+JS, but Anvil is something really special. I'm excited to find solutions for clients again - it's really fun and exiting to have so much power at hand, with the joy that comes from being able to use the sort of great design and implementation that I discovered when I first began using Rebol.

posted by: Nick 18-Jul-2022/17:26:41-7:00

In the past, I've set up Rebol development machines for an afternoon, at clients' locations, and written prototype code in person, so that we could iterate through versions of UI implementations and other design choices in person. I found this to be a great way to prototype with the actual users of the software, to help understand their needs and go through choices about implementation.

With Anvil that sort of iterative interaction with clients is so much simpler. I just send them links with different version numbers, they try each one in their browser, and tell me 'I like this part of version 3 and this part of version 5'. No software installs, no physical meetings, just quick feedback, easy version control - all super simple to do.

posted by: Nick 18-Jul-2022/17:39:48-7:00

It's hard to overstate how nice it is to be able to implement some complex functionality using a few lines of API code. Do you know how much work I put into video conference and things like simple SMS capabilities in the past?

https://conference.anvil.app/

Implementing that JS API in Anvil took a few minutes, using code that was in an existing Anvil tutorial.

And any service such as Twilio or Vonage, which provide Python examples, is typically just a few minute long endeavor to implement. Implementing mapping features, phone calls, machine learning models with huggingface, etc. - all SO easy.

Oh, and the user management feature built in to Anvil - jeez, that saves soooooo much work implementing real apps for users. A couple lines of code turns a simple single user prototype into a production multi-user database app.

And the built-in Google API features (and MS Azure, if you're into that) - I can access files in Google drive accounts, directly edit rows and columns of Excel files in those accounts, etc. C'mon, that would be so difficult otherwise...

And if I need to build an uploader to convert someone's existing spreadsheet, just add a fileloader widget to an Anvil UI, use the Python Pandas library to convert the file, load it into the database, and I'm off and running. This stuff is the sort of functionality that makes Python/Anvil ridiculously productive.

Tasks that used to make me cringe, it seems like every one of them is now a fun little project to dig into for a few hours - and then I've got some really powerful reusable pieces of code in the toolbox.

posted by: Nick 18-Jul-2022/17:59:28-7:00

I still think Rebol's ability to create dialects is a method of design simplification, that the industry still needs to learn about. But in the meantime, I need to be productive, and simple integrated tooling, connectivity, and integration with the most popular and powerful ecosystems in modern tech go a much longer way to getting things done, than having the potential build more efficient language tools.

posted by: Nick 18-Jul-2022/18:32:09-7:00

What attracted me to Rebol originally was its appeal as a pragmatic solution to building user apps. My interests, and none of my professional background has ever been about building languages or tools. And that's still the case. Pragmatic solutions to building user applications are what I'm interested in. I'm not concerned that a first run of an Anvil app requires 5Mb of traffic. That's a limited, static issue, which is simply not an issue for my clientele. What matters much more is that they can run my app on their iPhone or whatever other common device they have, without having to go through some time-consuming installation/configuration process that requires some (any) technical knowledge, and that I can build and deploy to all those platforms instantly. That's real, practical time and money-saving capability.

Rebol spoiled me, and now Anvil is continuing to spoil me more than I could have ever imaginged.

posted by: Nick 18-Jul-2022/18:39:32-7:00

Hi Nick. I'm not aware of any other than this one http://hostilefork.com/media/shared/replpad-js/
I'm using it to write prescriptions for patients including antivirals for their Covid, and I use it for billing hospitals for my work

posted by: Graham 18-Jul-2022/22:17:33-7:00

Hi Graham,

I'm glad to here that you're able to get some work done with Rebol in the browser, but that's a far cry from being a productive full stack solution. I'm assuming you're using HTML, CSS, JS for any front end design? I'm curious how data is saved on a server, and what the toolchain and backend development process involves. It looks like there's a workable replacement for JS on the front end (Rebol), and I imagine the backend server language (Rebol), and perhaps the data transfer protocol (Rebol series instead of something like Json), but what about the roles of HTML, CSS, database, and the work involved with interoperating with all the other pieces of the full stack? How difficult would it be to connect with the Google map API, for example, or any service which requires Oauth, or to connect to the API at https://typesense.org/ , without having the benefit of 'import typesense', for the languages they support?

Solutions to those sorts of problems are what's needed in order to be productive. The biggest thing that can't be beaten is 'import ' in Python. Building up an ecosystem as rich as Python's is something that simply can't be done, without decades of deep work, performed by millions of people. That makes the accomplishments of the Anvil framework pale in comparison. It's the availability of libraries, for every purpose, which makes Python incomparable. What if you want to record voice notes and send them to users' phones, what it you want to train an machine learning algorithm to recognize poison ivy, using an embedded system with a camera, which you can attach to your bike, for example? You can do that first thing with a few lines of Twilio or Vonage API code. You can do the second with any RP2040 microcontroller that supports Micropython and TinyML (there are dozens of those microcontrollers available on the market - and they cost a few dollars). Those sorts of things are *easy* with Python, because of the vast breadth of the Python ecosystem. Anvil just bridges the full Python ecosystem with a professional, full stack set of productive tools. Anvil handles every bit of the full stack development process, from front end, to database, all in one cohesive system. Just the user management service in Anvil is a game changer for building multi-user apps. And the Client-Server architecture *integrated with database security features*, built-in, makes building secure apps several orders of magnitude easier than trying to cobble together solutions with HTML, CSS, JS (Rebol), some data transfer protocol (Json or Rebol series), some RDBMS (Postgres, or maybe some files storing Rebol blocks), etc. - it's a whole different game when all the necessary parts are built-in and *integrated*. Anvil has a modern fully functional UI built-in, with a drag and drop builder (and/or you can build layouts entirely, or partially with *Python code) - you never need to touch HTML, CSS, JS, unless you want to style designs more deeply than the builder allows (all the normal expectations for fonts, colors, spacings, various flex-box type layouts, alignments, etc. are all built in, as well as rich repeating panel and grid data displays that can be instantly bound to database columns, with each row containing *any* sort of UI display). Material Design is the default style choice in Anvil, but several others are provided, and you can style however you want, with custom HTML, CSS, and JS (and any such changes are easily re-integrated into the UI builder and the Python object system). None of that needs to be implemented manually.

You *can mow a lawn with a razor blade successfully, but that would take days of hard work, every time the lawn needs to be mowed. Isn't it a more productive choice to use a Husqvarna YTH18542, to get the job done more professionally in a few minutes?

posted by: Nick 19-Jul-2022/9:18:14-7:00

It goes beyond all those features - it's the *work flow* - the built-in IDE with *autocomplete*, that runs on any modern device - being able to just open up any project I'm working on, on any machine, running any common OS, without installing anything... and deploying with the same ease (just send a link). My God autocomplete is so nice - it saves soooo much time, and eliminates sooooo many erros. Built-in versioning - just click a button to save the current version, restore and make any save point your production or development version, with a click (and every piece of that process is automatically integrated with GIT) - those sorts of things, *all integrated*. It kinda sounds too good to be true, but it's not. That's the sort of thing which is fully implemented in Anvil, and it's not buggy or quirky in the least. Every part of Anvil is implemented using best practices, and it *just works* in a way that feels not just slick, but utterly professional.

I love the Rebol language design, and would love to see a light weight full stack framework built using it, for building CRUD apps, some day... But even once something like that were created, and if it were implemented beautifully, and if it became popular and well supported... it would takes decades to build the sort of capability which is available for the taking in the Python ecosystem. Anvil is *already there* 100%.

posted by: Nick 19-Jul-2022/9:33:17-7:00

Nick, that is clear and understandable.

REBOL was designed for more than user applications, specifically to create a successor to AmigaOS. When Carl released iOS, it turned out he meant an Internet operating system more than a traditional operating system.

I know what you mean, because a quarter century before Anvil, I specialised in Lotus Notes, which, for its time, did everything you praise Anvil for, and was the first to offer an integrated environment in a network setting.

Notes was awesome and nothing compared, yet, when I made moderately complex applications for customers, I ran into limitations of the platform that the framework made impossible to solve. This made me remember REBOL, and I suddenly saw that it was designed to offer all of Notes' abilities in a fundamentally modular way. Sometimes some more work is needed to match an app in Notes or Anvil or all those other frameworks, but it is far less limited than such frameworks.

Current limitations in REBOL family languages are accidents of management, not fundamental limitations such as in frameworks.

That's why one problem with frameworks is that there is always a different latest and greatest one. There have been other Python frameworks before that tried to imitate the integration of Lotus Notes. You just told me about Anvil; I hadn't heard about it yet. I don't know how long I will be hearing about it. I don't think it's immortal. It certainly doesn't fulfill my needs.

I am designing Meta not only for applications and groupware, but also to enable implementing traditional operating systems. Stuff Python can't do. Perhaps that doesn't mean anything to you. That's alright, but it means Meta doesn't have to replace Anvil to be successful. Still, replacing systems that seem too big to fail happens all the time, by nimbler systems that eat away at them from the bottom.

posted by: Kaj 19-Jul-2022/14:14:18-7:00

Of course, Anvil isn't made for building OSs, or web browsers, or any sort of system tools. Please don't get me wrong, I am very excited to see where Meta goes, and what can be created with it, but my purpose for using Rebol was always to create applications for end users.

And of course you can do more with a general purpose programming language than with a spreadsheet system. That was the basis for my 800 page web site at business-programming.com - about the benefits of using Rebol to build business apps, especially as opposed to using boxed software, spreadsheets, and any other limited tooling which enabled less than custom solutions.

There is no inherent limitation in using a framework such as Anvil - all it does is bring the entire scope of the general purpose programming language Python into a new environment, so that you can integrate all front end and back end work using that single language - incorporating and integrating everything that language has to offer, in a way that's much more naturally connected: functions on the server can be called by functions in the browser, and the database can be queried in Python, without any intermediate steps or pieces of the entire mess of 'normal' web componentry getting in the way. I'd love to see that same capability evolve with Meta or any Rebol based language - that's what I was supporting when Doc first began to build Red, but that goal was abandoned with his need to earn income.

I think what you're doing with Meta is working towards what's been accomplished with Anvil, for Python. Anvil isn't a limited rigid framework that forces developers to stick with a few basic tools - the opposite - it's a system that enables developers to use the full scope of everything in the Python ecosystem, with far *fewer* restrictions upon any part of the development and deployment process than was previously possible. That's what I'd love to see happen with any sort of Rebol language tooling - You are clearly doing more to make that possible already, and I would love to see more of Rebol working seamlessly, directly in the browser, connecting with Rebol on the server, sending Rebol data structures directly back and forth between front and back end, and storing data in native Rebol structures - without any of the messy platform implementation problems getting in the way - so that one could just write pure Meta code for every part of the web app development process.

Carl's idea with iOS was to create a better Internet, based on simplifying each component of his incarnation of the 'web', making server and client software speak more easily with one another, using more efficient designs for each piece of the distributed system. It would have been far better than how things on the web have evolved, of course. I loved everything about Carl's vision, and Rebol's implementation was brilliant. But that ship has sailed, the web exists in its current state, and that whole mess isn't going to disappear quickly. The idea behind Anvil seems to me to be very much in line with Carl's vision of simplification. They're just building it upon existing ubiquitous tooling (current browser standards, Python language, PostgreSQL database, etc.). There's no reason the idea of Anvil couldn't be implemented using Meta, for example, so that the entire development process for full stack web apps, could be performed using nothing but Meta. That's something I'd love to see. Anvil is just an implementation of all the tools needed to create full stack apps using Python, end to end - with a bunch of helpful tools which really do increase productivity in the development process. I'd love to see such a tooling stack evolve for Meta, which included version control and GIT integration, for example. And if not a GUI builder, a nice GUI dialect which runs in the browser (requiring no other language or tooling) - I always wanted to see VID or RebGUI ported to run in webassembly, with a graphic engine running on canvas or some other universal standard... With Anvil, they've just done all that already, and it's been done so professionally. It's just Python, for every stage of the development process, integrated with lots of extremely useful tooling to increase productivity (an IDE with autocomplete, version control, drag-and-drop UI builder, built-in database, etc.). None of that is limiting in any way comparable to using spreadsheets to solve problems that are far beyond their intended scope of use.

posted by: Nick 19-Jul-2022/15:43:44-7:00

I hope it's clear, the last thing I want to do is suggest that developing something like Meta is anything but valuable. The modern web development environment is an utter mess - it's the incarnation of everything that Carl was hoping to derail before it became such a massive quagmire of badly constructed standards which have been pushed so far beyond their originally intended scope...

It's just always been my perception that there's a sweet spot of features needed to attract a large community of developers, and to gain traction - which offers tremendous benefits, and if there's merit in changing standards, that should be part of the goal of any tool. Python has succeeded because they made it easy to build libraries, and to connect C code, with a language interface that anyone could learn and use. They dominated the data science arena with libraries that were better, and with implementations in a general purpose language that were simple enough for a large swath of developers to grasp - not as beautiful as Rebol, but much more approachable than C, Java, etc.

What's happening with Anvil is happening all over - implementations of front end tools which run in the browser using WASM - connecting to back end systems in ways that had always previously required HTML, CSS, JS, JSON, (React, Vue, etc.).

There's nothing wrong with building better, more accessible tooling to work with a language.
That's all Anvil is, and I'd love to see someone in this community not discount the value of that sentiment.

posted by: Nick. 19-Jul-2022/15:59:12-7:00

Oh, I'm not discounting your sentiment, I'm saying I had very much the same sentiment a quarter century earlier with Lotus Notes.

Pretty much all systems have problems with their implementation technology. REBOL is the ideal implementation technology for systems such as Lotus Notes and Anvil. In my private REBOL and Red systems, I always worked towards making them similar in concept to Notes. I am designing Meta to be even a few orders of magnitude better.

On the other hand, I got to know the limitations of both approaches. It's like Joel Spolsky says it in his Law of Leaky Abstractions. For example, if you build web sites in dialects, you won't have access to all features of HTML/CSS/JavaScript. At some point you will need them or some customer will complain about it. I attempted several such abstracted designs and they tended to hamper functionality and productivity. It's better to start with supporting all functionality if you want to match any competitors.

Another side of supposedly not having any limitations, is that the limit is that everything and the kitchen sink is included. It weighs you down when you need to do something lightweight. This was actually why web browsers eventually won over Lotus Notes.

posted by: Kaj 19-Jul-2022/17:01:08-7:00

Anvil lets you drop down to HTML, CSS, and JS, whenever you want or need to use it - there are no limitations there - but 90% or more of what you'll ever need to do won't need it. And in addition to that, Anvil provides some really nice methods of encapsulation HTML, CSS, and JS in ways that allow bits and pieces to be used (by defining styles as 'roles', for example). That's a productivity magnifier that doesn't impose limitations. I think the inevitable evolution of all this systems is towards more productive high level functionality which still allows for low level control. The low level control in Python is really enabled by making it possible/easier to implement libraries of low level functionality. The low level control in Anvil's front end capabilities is made possible by enabling full access to HTML/CSS/JS.

posted by: Nick 19-Jul-2022/18:33:10-7:00

What really amazed me with Rebol was that high level capability could be built up with layers of composable language, as opposed to larger and larger libraries of rigid functions. That's a technique which hasn't been employed so much in the rest of the industry so much (except by the Lisp guys), and something which I think will be (re)discovered by other communities eventually.

posted by: Nick 19-Jul-2022/18:37:53-7:00

Right, eternity is a long time from now, while current frameworks have lifetimes of around a decade. I have long been tired of switching frameworks. I want one that lasts me at least my lifetime.

My private REBOL and Red systems have features similar to what you mention, inspired primarily by Lotus Notes. I'll review Anvil when I redo them in Meta.

posted by: Kaj 20-Jul-2022/5:15:42-7:00

Thinking about this more, I see a solution that's relatively simple. The biggest limitation with any system that isn't among the most popular languages/tools, is library and code example support, but I guess that problem is potentially fairly easily solved, just by calling code in a third party system. If you've got Meta running in the browser, it really shouldn't be to hard to integrate any code that's callable in JS, so that really solves the connectivity/library support problem. The biggest issue then, is just converting data back and forth between some JS data structure and Rebol. (There really needs to be support for Json in any new system!).

JS seems like a great match for extending library and code example support to any system which runs in a browser, but even being able call a Python interpreter on a server to run some code which requires functions in an imported library eliminates the argument for not using a given language - it just requires some code to massage returned data values into Rebol structures.

For example, I did this to convert a Rebol blocks to Python dictionary:

R E B O L []
root5-shapes: [
     "." "major triad, no symbol (just a root note)" [1 3 5 11 55]
     "m" "minor triad, min, mi, m, -" [1 b3 5 11 55]
     "aug" "augmented triad, aug, #5, +5" [1 3 b6 11 b66]
     "dim" "diminished triad, dim, b5, -5" [1 b3 b5 11]
     "5" "power chord, 5" [1 55]
     "sus4" "sus4, sus" [1 4 5 11 55]
     "sus2" "sus2, 2" [1 9 5 11 55]
     "6" "major 6, maj6, ma6, 6" [1 3 55 13 11]
     "m6" "minor 6, min6, mi6, m6" [1 b3 55 13 11]
     "69" "major 6/9, 6/9, add6/9" [1 33 6 9 5]
     "maj7" "major 7, maj7, ma7, M7, (triangle) 7" [1 3 5 7 55]
     "7" "dominant 7, 7" [1 3 5 b7 55]
     "m7" "minor 7, min7, mi7, m7, -7" [1 b3 5 b7 55]
     "m7(b5)" "half diminished, min7(b5), (circle w/ line), m7(-5), -7(b5)"
         [1 b3 b5 b7 b55]
     "dim7" "diminished 7, dim7, (circle) 7" [1 b33 b5 6 111]
     "7sus4" "dominant 7 sus4, 7sus4" [1 4 5 b7 55]
     "7sus2" "dominant 7 sus2, 7sus2" [1 9 5 b7 55]
     "7(b5)" "dominant 7 flat 5, 7(b5), 7(-5)" [1 33 b5 b7 111]
     "7(+5)" "augmented 7, 7(#5), 7(+5)" [1 33 b6 b7 111]
     "7(b9)" "dominant 7 flat 9, 7(b9), 7(-9)" [1 33 5 b7 b9]
     "7(+9)" "dominant 7 sharp 9, 7(#9), 7(+9)" [1 33 b7 b3]
     "7(b5b9)" "dominant 7 b5 b9, 7(b5b9), 7(-5-9)" [1 33 b5 b7 b9]
     "7(b5+9)" "dominant 7 b5 #9, 7(b5#9), 7(-5+9)" [1 33 b5 b7 b3]
     "7(+5b9)" "augmented 7 flat 9, aug7(b9), 7(#5b9)" [1 33 b6 b7 b9]
     "7(+5+9)" "augmented 7 sharp 9, aug7(#9), 7(#5#9)" [1 33 b7 b3 b6]
     "add9" "major add9, add9, add2" [1 3 5 99 55]
     "madd9" "minor add9, min add9, m add9, m add2" [1 b3 5 99 55]
     "maj9" "major 7, maj9, ma9, M9, (triangle) 9" [1 33 5 7 9]
     "maj9(+11)" "major 9 sharp 11, maj9(#11), M9(+11)" [1 33 b5 7 9]
     "9" "dominant 9, 9" [1 33 5 b7 9]
     "9sus" "dominant 9 sus4, 9sus4, 9sus" [1 44 5 b7 9]
     "9(+11)" "dominant 9 sharp 11, 9(#11), 9(+11)" [1 33 b5 b7 9]
     "m9" "minor 9, min9, mi9, m9, -9" [1 b33 5 b7 9]
     "11" "dominant 11, 11" [1 b7 9 44 444]
     "maj13" "major 13, maj13, ma13, M13, (triangle) 13" [1 3 55 7 13]
     "13" "dominant 13, 13" [1 3 55 b7 13]
     "m13" "minor 13, min13, mi13, m13, -13" [1 b3 55 b7 13]
]
python: copy {}
foreach [a b c] root5-shapes [
    lst: copy {}
    foreach i c [append lst rejoin [{'} form i {'} ", "]]
    append python rejoin [mold b { : [[} lst {], } mold a {],}]
    append python newline
    ; append python newline
]
editor python

The returned Python dictionary values:

"major triad, no symbol (just a root note)" : [['1', '3', '5', '11', '55', ], "."],
"minor triad, min, mi, m, -" : [['1', 'b3', '5', '11', '55', ], "m"],
"augmented triad, aug, #5, +5" : [['1', '3', 'b6', '11', 'b66', ], "aug"],
"diminished triad, dim, b5, -5" : [['1', 'b3', 'b5', '11', ], "dim"],
"power chord, 5" : [['1', '55', ], "5"],
"sus4, sus" : [['1', '4', '5', '11', '55', ], "sus4"],
"sus2, 2" : [['1', '9', '5', '11', '55', ], "sus2"],
"major 6, maj6, ma6, 6" : [['1', '3', '55', '13', '11', ], "6"],
"minor 6, min6, mi6, m6" : [['1', 'b3', '55', '13', '11', ], "m6"],
"major 6/9, 6/9, add6/9" : [['1', '33', '6', '9', '5', ], "69"],
"major 7, maj7, ma7, M7, (triangle) 7" : [['1', '3', '5', '7', '55', ], "maj7"],
"dominant 7, 7" : [['1', '3', '5', 'b7', '55', ], "7"],
"minor 7, min7, mi7, m7, -7" : [['1', 'b3', '5', 'b7', '55', ], "m7"],
{half diminished, min7(b5), (circle w/ line), m7(-5), -7(b5)} : [['1', 'b3', 'b5', 'b7', 'b55', ], "m7(b5)"],
"diminished 7, dim7, (circle) 7" : [['1', 'b33', 'b5', '6', '111', ], "dim7"],
"dominant 7 sus4, 7sus4" : [['1', '4', '5', 'b7', '55', ], "7sus4"],
"dominant 7 sus2, 7sus2" : [['1', '9', '5', 'b7', '55', ], "7sus2"],
"dominant 7 flat 5, 7(b5), 7(-5)" : [['1', '33', 'b5', 'b7', '111', ], "7(b5)"],
"augmented 7, 7(#5), 7(+5)" : [['1', '33', 'b6', 'b7', '111', ], "7(+5)"],
"dominant 7 flat 9, 7(b9), 7(-9)" : [['1', '33', '5', 'b7', 'b9', ], "7(b9)"],
"dominant 7 sharp 9, 7(#9), 7(+9)" : [['1', '33', 'b7', 'b3', ], "7(+9)"],
"dominant 7 b5 b9, 7(b5b9), 7(-5-9)" : [['1', '33', 'b5', 'b7', 'b9', ], "7(b5b9)"],
"dominant 7 b5 #9, 7(b5#9), 7(-5+9)" : [['1', '33', 'b5', 'b7', 'b3', ], "7(b5+9)"],
"augmented 7 flat 9, aug7(b9), 7(#5b9)" : [['1', '33', 'b6', 'b7', 'b9', ], "7(+5b9)"],
"augmented 7 sharp 9, aug7(#9), 7(#5#9)" : [['1', '33', 'b7', 'b3', 'b6', ], "7(+5+9)"],
"major add9, add9, add2" : [['1', '3', '5', '99', '55', ], "add9"],
"minor add9, min add9, m add9, m add2" : [['1', 'b3', '5', '99', '55', ], "madd9"],
"major 7, maj9, ma9, M9, (triangle) 9" : [['1', '33', '5', '7', '9', ], "maj9"],
"major 9 sharp 11, maj9(#11), M9(+11)" : [['1', '33', 'b5', '7', '9', ], "maj9(+11)"],
"dominant 9, 9" : [['1', '33', '5', 'b7', '9', ], "9"],
"dominant 9 sus4, 9sus4, 9sus" : [['1', '44', '5', 'b7', '9', ], "9sus"],
"dominant 9 sharp 11, 9(#11), 9(+11)" : [['1', '33', 'b5', 'b7', '9', ], "9(+11)"],
"minor 9, min9, mi9, m9, -9" : [['1', 'b33', '5', 'b7', '9', ], "m9"],
"dominant 11, 11" : [['1', 'b7', '9', '44', '444', ], "11"],
"major 13, maj13, ma13, M13, (triangle) 13" : [['1', '3', '55', '7', '13', ], "maj13"],
"dominant 13, 13" : [['1', '3', '55', 'b7', '13', ], "13"],
"minor 13, min13, mi13, m13, -13" : [['1', 'b3', '55', 'b7', '13', ], "m13"],

The actual Rebol code is just a few lines, and setting up this sort of routine to bridge Rebol with Typesense arguments and results (or consider using a library like Tensorflow, for example), is not much work at all in the whole scheme of building a full app.


posted by: Nick 20-Jul-2022/9:54:53-7:00

Yes, there are many possibilities. Most of my publications for REBOL and Red were bindings to C and C++ libraries. In Syllable and other operating systems, language bindings are an important but difficult topic. They are usually problematic and inefficient.

REBOL is designed as a silo, and Red bindings are laborious and inefficient because they have to go through Red/System, but Meta is designed for easier and efficient binding to other languages, so it can make use of other systems. See its goals:
language.metaproject.frl#goals

As I elaborated to Sam in another thread here, Meta does not need to reinvent the world, because it makes use of other languages:
language.metaproject.frl#features

The first language of choice is not Python, but C. C is much more ubiquitous and efficient, and there are probably still more C libraries than Python libraries. Like Sam wants a Meta back-end that generates Nim, if you really think Python is the way to go, you could write a Meta back-end that generates Python.

Other forms of bindings are possible, too. The more work you put in them, the more elegant they can be in Meta. It's possible to make generic, automatic binding generators, but the most elegant is to abstract them into Meta types. Meta's type system is much richer than that of REBOL, to make both the language and bindings more elegant:
language.metaproject.frl#how

posted by: Kaj 20-Jul-2022/11:36:50-7:00

One of my publications for Red was a JSON codec, that converts data between Red and JSON as transparently as possible.

That's for remote communication. For local data conversion, much more efficient ways are available, depending on the language.

Currently, the first plan for calling JavaScript functions actually goes through C, because the current way Meta runs in browsers is through Emscripten:
language.metaproject.frl#web

posted by: Kaj 20-Jul-2022/11:53:34-7:00

I believe their are more libraries in terms of total count, for C, but most new 'high-level' tools and APIs release official bindings and code examples for JS, Python, Java, C#, Ruby... And Python leads, without reservation in all the 'data science' category of libraries (machine learning, data visualization, data wrangling, AI...) - and implementing those tools, is where so much of the business (money making) opportunities are. Just being able to import an officially supported library, drop in some JS or Python code, to implement some deeply capable solution (like Typesense, for example), enables capabilities which are far beyond what any single developer could ever hope to implement for a single project. Would you want to have to design a solution that implements Typesense's capabilities, just to finish a project? It took me a few hours last Wednesday to implement some serious search capabilities, including fuzzy search that deals with misspellings and natural language input, and geolocation based on distances between latitude/longitude locations, and connect that to the Google geocoding API, to produce wickedly powerful results for a client. One sitting in one night, without any previous experience with that system. That's not simple CRUD stuff - and the capabilities of tools like tensorflow - jeez man - those aren't the sorts of things that any single person is going to design to finish a project. All those modern libraries, which are specific to Python, for example, represent lifetimes of work encapsulated in tools and APIs which cannot be accessed other ways, except in the ecosystems in which they evolved. Look at Tensorflow's documentation: 'A word of caution: the APIs in languages other than Python are not yet covered by the API stability promises'.

posted by: Nick 20-Jul-2022/13:48:03-7:00

I think Json is an obvious fundamental requirement - such a huge percentage of modern web APIs return data in Json. Maybe XML should still be supported...(?)

posted by: Nick 20-Jul-2022/13:49:52-7:00

Again, I need to say that I'm incredibly impressed with what you're doing with Meta, and I wish I could be more involved (I'd be happy to help with testing, documentation, etc!). I'd love to have a usable Rebol-like system available to build full stack web apps - nothing would make me happier. Tens years ago, I did my best to develop interest in supporting mobile and web platforms for Rebol, and started financing work that would lead in that direction. I've been happy to have Rebol for Android as a result, for my own needs, but nothing has been viable for doing commercial development work with Rebol with new clients.

Anvil is likely a more than a workable solution for any work that I may get involved in for the next decade (it's much more than workable, it's a special joy). But I'd be so much happier to see Meta become a viable choice for certain classes of apps. I deeply respect everything you've done in the Rebol community, and love to see your shared interest in Carl's values/goals and passion for the whole ethos which surrounded Rebol in general. I'm just hoping to provide some perspective on what's working for me, and hoping that there's still some way forward for a Rebol-like alternative.

posted by: Nick 20-Jul-2022/14:12:48-7:00

Thanks Nick, appreciated!

I have an unpublished HTML/XML markup codec for R3 and Red. I'm actually using the encoder to create all my new web sites. It's not highly abstracted like my previous REBOL and Red Content Management Systems, but it gives me full control over HTML/CSS/JavaScript, which I need for my recent web apps. It's a REBOL data dialect that at least helps with the most awkward aspects of web technology. It can be built on later by higher-level dialects.

If we define Meta as an Anvil clone, it will fail as you say. It's a natural instinct to want to match anything a competitor has, but it's a loosing strategy because it's chasing tail lights as you say. Several of my strategies for Meta are the other way around.

Instead of retracing the trodden path, I designed Meta to go where others are unable to go. There, there will be no competition. It will give Meta places to survive and attempt other ventures.

I have long shared your frustration of most REBOL-related projects eventually being abandoned. To fix this, I designed Meta to be extremely generic and extremely productive. There should be no dead-end streets: everything should happen on Meta's main road. There should be no explosions of complexity in either the language or the project infrastructure: it should all remain managable by myself for times when I get no support and have to get by on my own projects:
language.metaproject.frl#when

Of course, support will be appreciated, so I am interested in opportunities where money can be made. The strategy is to change the planning to accommodate such projects.

That said, in general, many library projects offer C bindings, some Interface Definition Language, or network API's, usually over plain HTTP, or some messaging system. When a Python binding is also available, it's usually not a good idea to go through Python, because it adds the complexity explosion of Python.

When the library is written in Python, or some other language, obviously a binding to that language is inescapable. The form depends on the language. Many dynamic languages support a generic, dynamic bridge to their functions and data. Python probably does, but I would have to look into it. If viable, just one generic Python bridge would serve all Python libraries. It would be more elegant to match Meta's language abilities, but it wouldn't be mandatory.

Another strategy of mine is to support constructing Service Oriented Architectures through messaging systems. In the past, I enabled R3, R2, Red and Red/System to interoperate by implementing ZeroMQ bindings for all of them. I used them to implement a commercial product. This avoids messy direct bindings between languages in the same process, while at the same time making your systems much more modular, flexible and scalable.

posted by: Kaj 20-Jul-2022/17:13:25-7:00

@Nick, since wasm runs in the browser ( as well in the cloud ) I have access to anything written in JS. There's enough functionality for most things, and as the JS engine improves, rebol wasm improves.

To see how Rebol is interacting with JS, try http://hostilefork.com/media/shared/replpad-js/ and type `do @chess` without the quotes. Type `chiu-vs-jensen` for a demo game of mine from long ago!

@Kaj - yeah, long time since we spoke. Last time was when we tried to find you when try Rebol stopped working in the StackOverflow chat!

posted by: Graham 21-Jul-2022/9:57:19-7:00

I'm not that hard to find. I'm a public person with an email address and a number of profiles, including on LinkedIn, and I'm on AltME.

I'm not on StackOverflow, but I vaguely remember you using TryREBOL from a bot. There was no guaranteed API, but I sent you some specifications when I changed it. I think that's why I started putting "/internal/" in API links. :-)

posted by: Kaj 21-Jul-2022/13:53:14-7:00

@Kaj, I think we did try contacting you. then we figured you had joined Andreas and Carl in disappearing into a cave somewhere.

posted by: Graham 21-Jul-2022/15:07:07-7:00

As I said, you contacted me, and I sent you specifications for the changed API.

It should be obvious that trying to contact me in places where I am not doesn't work very well.

posted by: Kaj 21-Jul-2022/15:22:17-7:00

Graham, cool chess example! (hehe, for that sort of stuff, I use Godot :')

posted by: Nick 21-Jul-2022/17:00:46-7:00

Interesting, Godot is a lot like what I'm looking at for Meta's multimedia future.

I could use it as inspiration, or write Godot bindings for Meta.

posted by: Kaj 22-Jul-2022/11:33:52-7:00

Cross post from the save wave topic, since Anvil was mentioned:

To be clear, Anvil is NOT strictly SAAS - I stay away from those sorts of products completely. There is an open source version of Anvil server, and I run an automated backup routine of all my apps and data hosted by Anvil.works, so that I can pop everything up to a self-hosted server if Anvil's hosted product ever gets hit by an asteroid. And to be doubly clear, I do the same thing with any Rebol web app hosted on any third party servers. Running web apps in *any* environment typically relies on third party servers. I wouldn't use Anvil if there wasn't a drop-in open source self hostable replacement to rely on.

The same is true of Typesense, BTW. I choose that over Algolia, specifically because Algolia is SAAS only.

posted by: Nick 22-Jul-2022/13:12:56-7:00

Hosted solutions of those products offer great convenience, which are fantastically practical, but no tool I choose to use would ever make the list if it relied entirely on an SAAS product or some other closed source requirement, which would break my apps completely if the vendor ever went out of business or required me to make changes to my code base, based on their choice to deprecate or not support previous production APIs.

posted by: Nick 22-Jul-2022/13:17:59-7:00

I spend time making sure I can implement any tooling on my own servers (on a machine at my physical location and/or in a cloud service), before I ever start to use it in production(!!). I did the same thing for Streamlit (which is another great Python tool for certain types of front end work). If I can't get projects up and running on a self-hosted, open source platform that I can completelely control in house, without a connection to the Internet, with version control, etc., I won't use it.

posted by: Nick 22-Jul-2022/13:23:27-7:00

I'm amazed that people make such broad and critical comments as:

'Anvil is a Saas. Personally I wouldn't want to hand my entire business to a company like Anvil which can and will shut you down or change policies at any time and for any reason.'

without doing any research.

'Anvil offers an SAAS solution for convenience, but you're not required to use it.'

is instead correct.

posted by: Nick 22-Jul-2022/13:50:21-7:00

Maybe this will make a little bit of sense. Take a look at this:

https://rebolapi.anvil.app/

That took me a couple minutes. That Anvil app connects to https://re-bol.com/piglatin.cgi , where I just plopped in some old Rebol code to generate pig latin:

#!./rebol -cs
R E B O L [title: "CGI piglatin"]
print {content-type: text/html^/}
sbmttd: decode-cgi read-cgi
output: copy {}
foreach t parse sbmttd/2 "" [
    x: parse t "aeiou"
    append output rejoin [
     either m: find/match t x/1[m][t]x/1 either m["ay"]["hay"]" "
    ].
]
prin output

(that code was NOT previously a CGI script, and of course it could be deployed in other ways than CGI - this is just a quick demo).

I put together a quick little UI in Anvil, which I connected to a server function that sends an HTTP request to the script above, parses the response, and displays the results in the UI.

There's no proprietary technology in any of that process, in terms of what Anvil is doing. The tools in Anvil just help me do that quickly - and it turns out that the full set of tools in Anvil makes up an absolutely beautiful toolkit to do 90% of everything that's needed to build most of the app functionality I need regularly.

So I can still interface with Rebol code with Anvil, for some complex data processing that perhaps I don't want to have to re-implement in Python.

I'm just choosing to use Anvil because it's a nice professional toolbox that gives me access to just about every capability I could ever imagine needing, to build apps for the next decade+.

Now take a look at this freakin thing:

https://anvil.works/pico

I've got some pico W's coming in the mail today, so that I can build a quick little foot operated wireless push button hardware page turner, which I'll use to turn pages while I sing and play guitar. That project should take me one sitting to build with Anvil - without their support of pico W, with uplink support, that project would be much much much harder.

Perhaps those couple little examples shed a tiny bit of additional insight? It would be so nice to hear 'that's pretty cool', or at least 'that piques my curiosity', instead of off the cuff uninformed criticism (referring to the comment that Anvil is just SAAS).

I'm loving the idea of being able to use and connect with Meta tooling, as it becomes more mature!

posted by: Nick 22-Jul-2022/15:16:11-7:00

There just aren't yet any tools that provide the broad scope of capabilities I can achieve with Anvil so productively, built with Rebol, or any other language (and I've been looking hard for 40+ years, and tried many hundreds of tools over the decades).

I started really just looking at Anvil for modern multiplatform UI, after finding Streamlit, Remi, PySimpleGUI (with Remi, PyQT, and others as a backend), and Anvil did the UI work sooooo much more professionally, and it turned out, the other backend features were deeply powerful (UI was just a small fraction of its functionality).

I'll probably still use Streamlit for UI at times - it's fast and easy to install in house, and is even more more concise and elegant than any UI that ever existed for Rebol - plus it provides nice access to camera on every device, for example, without having to use any third party API.

I love collecting tools, and using the right tool for the job. I love doing the research about their capabilities, putting them in practice and learning about their drawbacks and limitations. I used VB for DOS in the very beginning (even though I cut my teeth on C and Lisp in school) - and there are still some VB for DOS apps running in Indianapolis businesses, which I wrote 27ish years ago. I did a ton of work with AutoIT in the early 2000s. I went through a Lua loving period for a while last year. I spent some time using Livecode. I used Haxe when Flash first began to die out. And of course Web tools have been around for a few decades, and I use whatever I need there...

Everyone who comes here thinks of me as a Rebol guy, and Rebol has been fantastically useful to me, but I'm into whatever works to make things happen, productively, in the real world.

posted by: Nick 22-Jul-2022/15:38:21-7:00

I just got my Pico W's. Just for fun, using one of the Anvil examples as a starting point, I'll make a Rebol server script generate the Morse code from user input sent over WIFI from an iPad or Chromebook front end, to flash lights on the Pico... Would anyone else like to try doing that in an evening without Anvil?

Of course that's a little silly and just for fun, but I see those sorts of practical productivity gains in every project I approach with Anvil. It's just a great set of basic tools to use in my tool box.

posted by: Nick 22-Jul-2022/15:56:03-7:00

I have every intention to enable Meta to do that, in an evening in an executable of a few kilobytes, without going through a remote server running PostgreSQL and everything.

posted by: Kaj 22-Jul-2022/16:19:21-7:00

I have always been very interested in your publications and your tool choices besides REBOL, because I know you have a keen feeling for them. I also like your enthusiasm and pragmatism very much.

I believe you immediately when you praise Anvil, and of course, it's cool what it can do. Why I am reluctant to say that, is because this is your REBOL forum. It's one of the last places where we keep REBOL alive, and I don't want that to be watered down.

We have both been evaluating tools for around fourty years. Where we differ, is that, while I enjoyed collecting them on my Atari 8-bit, I grew tired of it after I was forced to work on PC's. I found PC's to be uninspiring, so I needed to look for inspiring software to somewhat compensate.

The first was Lotus Notes. I can clearly see where Anvil still lacks compared to Notes more than thirty years later. I have seen it all before. I want fundamental progress, not the deterioration all around us in our field, due to ignorance and stubborness.

With REBOL, Carl invented a unique and timeless design. It was after Notes, so I can't fault Notes for not being implemented in REBOL, but most systems after it should have been. As Carl did with iOS and AltME.

I don't want to spend my brain power on learning all the petty details of several trendy new systems every year. I have always spent it on thinking how to improve and modernise REBOL. It's a big step to actually do it, but it needs to be done, and it needs the support of a community.

posted by: Kaj 22-Jul-2022/16:42:45-7:00

Kaj,

You are championing a great cause, and because you have stayed focused on engineering, building tools from the ground up in C, you'll be able to create tooling in ways that I can't. There's no question in my mind that you will find fantastic support, once Meta is mature enough out of the box to be put to use for mainstream work. I'll be on the front lines hoping to help out as much as I can.

Honestly, it's a tremendous satisfaction to see you focused on building Meta. I tried so hard for so many years to try and rally community, pay for work to be done, etc. My position and needs have changed, but I have no less interest, or belief that what you're stepping up to do is valuable - more than valuable - a real hope for the industry. I still think it could be very successful commercially if it solves the right problems.

posted by: Nick 22-Jul-2022/21:31:39-7:00

Kaj,"...Sam wants a Meta back-end that generates Nim..."

You misunderstood me. My, possibly insane, idea was that instead of writing all the C code for Meta or using R3 you could use Nim. Which compiles to C, C++ or JavaScript. Maybe this is stupid but two different Rebol like languages have been written in Nim. There must be a reason why.

Nim's "...Nim has a powerful macro system which allows direct manipulation of the AST, offering nearly unlimited opportunities....".

Nim also has lots of built in goodies like garbage collection that can be tuned to different levels.

The basic idea is to get something running faster. I wrote this idea a while ago. I think my understanding now is that you want to control things top to bottom so this is probably not for you.

I wonder though if Nim could be used to toss something off quickly. It might be great at building a prototype and testing what works and what doesn't then go back and code the rest from scratch.

posted by: Sam the Truck 22-Jul-2022/23:19:56-7:00

Sam, sorry, I mended your words a bit to fit the situation.

I think prototypes are a waste of time and show weakness of the prototype language. I designed Meta to be able to develop prototypes smoothly into the final products.

I'm also doing that with Meta itself. It's currently a prototype that is already very powerful because it uses REBOL and C. A final performance boost will come when I port from REBOL to Meta itself.

posted by: Kaj 23-Jul-2022/3:44:35-7:00

Nick, thanks for your words of support. I always saw your support for advancing REBOL, and it was part of the frustration that the makers of projects let your support end up in dead ends.

I tried for too long to support projects of others. I should have taken the wheel years earlier, but I wasn't sure if I could.

A lot of time is lost, but I did spend a lot of thought on how to catch up, and that's why several aspects of Meta are different and extreme.

One aspect is that I'm developing Meta to support use cases one by one, not in one big 1.0 dump that takes a decade to develop. I hope REBOL people will get used to that and not wait until Meta is compatible with REBOL, which will never happen.

posted by: Kaj 23-Jul-2022/4:09:40-7:00

Kaj,

I don't care that Meta is compatible with Rebol, just that it's productive and capable. UI is an important priority for creating user apps, and modern UI for most users seems to be most productively implemented in the browser - and browser based UI provides a bit of future-proofness, because new platforms will likely provide a browser, and everyone is comfortable using a browser, no matter what OS they're on. Not needing to install apps is also a great boon for most users. Also, updating apps just has to happen on the back end, without having to rely on the user going through a download/install/security configuration process to keep them up to date with most recent versions of apps. Please forgive me if I've missed it, but where is browser-based UI, without HTML, CSS, JS, React, Vue, Svelt, etc., in your roadmap? How far along are you in getting dug into that?

For me, getting communication going between client and server, using the same language and data structures on front and back end, along with data persistence on the server, using the same data structures, is the heart of making the system usable.

Whether that language is compatible with Rebol isn't important - just that it's compatible with itself on front and back end. I think that's the basis of productivity - as long as the language isn't a mess (JS).

posted by: Nick 23-Jul-2022/8:55:27-7:00

That's a great attitude, and matches well with my goals.

I don't put things in the road map if I can't make concrete promises about them, so most things will depend on funding. But broadly, the first Meta year was getting it working, using Atari as baseline; the second year was setting up more project infrastructure, supporting the most popular platforms and introducing more audiences. Coming year will be a push for more platforms and more audiences, to see who is most interested. I do have a plan to show basic UI bindings as proofs of concept, but I don't know yet in what order I will do those things.

In general, Meta is very much about integrating with existing systems: often the opposite of REBOL. I don't aim for full Meta systems until well in the future, because it's a lot more work, and there is lack of acceptance of such concepts. Instead, it's about combining the strengths of different systems, and replacing parts of them with Meta as it grows stronger.

First, Meta will be more like a glue language, like Lua. As it becomes stronger, it will be able to be more standalone, like REBOL.

posted by: Kaj 23-Jul-2022/10:19:20-7:00

For me, making end user apps, UI is a huge part of what glues things together. Just text field, button, image, drop-down (or another multi-select), and some sort of data grid/repeating row widget, along with basic column and flow page layouts, cover most business app needs.

If you're trying to attract an audience, having UI in place with those basic features, would resonate.

posted by: Nick 23-Jul-2022/11:16-7:00

What got me into Lua recently was seeing that Corona been open sourced (Solar2D), and then Lua Studio - each with UI that worked just as well on desktop and mobile (and Solar2D supports web).

posted by: Nick 23-Jul-2022/11:19:02-7:00

Web is the only UI that needs to be supported, as long as it connects to a back end system for data persistence, integration with other systems, etc.

posted by: Nick 23-Jul-2022/11:54:43-7:00

Just a thin wrapper around HTML, CSS, JS, so that language and data structures are the same on front and back end, is all that's needed. I bet you'd find lots of community support getting a system like that built up. Everybody and their brother would be added UI functionality.

posted by: Nick 23-Jul-2022/11:58:11-7:00

Maybe a wrapper for canvas drawing along the way. With a basic system in place, you could accept bounties for work that others want done :)

posted by: Nick 23-Jul-2022/12:00:09-7:00

Maybe a wrapper for canvas drawing along the way. With a basic system in place, you could accept bounties for work that others want done :)

posted by: Nick 23-Jul-2022/12:00:10-7:00

I don't need anything more than that to start building useful apps - and having a lightweight option (lighter than Streamlit, with a full install of Python and some RDBMS on a server, for example), is very appealing. I'm sure there's a market for that.

posted by: Nick 23-Jul-2022/13:34:54-7:00

Here is my evening project. It's a very lean pig that can win pig races for you:


Meta [
    Title: "Pig Latin example for CGI"
    Author: ["Nick Antonaccio" "Kaj de Vos"]
    Rights: "Copyright (c) 2020-2022 Kaj de Vos"
    License: {
        PD/CC0
        http://creativecommons.org/publicdomain/zero/1.0/
    }
    Purpose: {
        Convert words to Pig Latin through CGI.
    }
    Notes: {
        https://en.wikipedia.org/wiki/Pig_Latin

        Ported by Kaj de Vos from the original in REBOL 2 by Nick Antonaccio:
        http://rebolforum.com/index.cgi?f=printtopic&permalink=Nick16-Jun-2022/11:12:40-7:00&archiveflag=new
    }
]

write/line {Content-type: text/plain
}
text: find/tail select/case system/environment "QUERY_STRING" "="

while (
    if space: find word: text " " [word: copy cut text space]

    unless is-empty word [
        write either is-same word vowel:
            any [find word "a" find word "e" find word "i" find word "o" find word "u"]
        [    ; Word starts with vowel
            write word
            "hay"
        ][
            write either vowel [
                write vowel
                copy cut word vowel
            ][
                word
            ]
            "ay"
        ]
    ]
    space
)[
    write " "
    text: next space
]

posted by: Kaj 23-Jul-2022/16:21-7:00

It should be a drop-in replacement for your REBOL version, unless you use post requests. Let me know if Anvil needs a different interface.

posted by: Kaj 23-Jul-2022/16:22:44-7:00

It should give you some idea of the state of Meta. It's lower-level than your REBOL version, but I think it's fairly straightforward, and it uses only a tiny fraction of the time and memory that REBOL needs.

Over time, more data types and higher-level convenience methods will be added, so it can become more compact and closer to REBOL.

posted by: Kaj 23-Jul-2022/16:30:44-7:00

I'm only interested if you can host it on an 8 bit Atari :')

posted by: Nick 23-Jul-2022/17:23:40-7:00

I thought you insisted on Anvil. :-)

I have been working on network support for Atari 8-bit. I almost got the compiler client to work, but the testers went silent. A web server would be possible. CGI wouldn't be the most efficient, but the above example wouldn't be hard to adapt to run on it.

posted by: Kaj 23-Jul-2022/17:33:06-7:00

I have the same ideas as you about UI. Just standard widgets would cover many use cases. I did those for my GTK+ binding for Red.

Which toolkit is very personal. Web is universal, but many people want to do native apps in a specific toolkit. Especially mobile devices have features that web doesn't support.

I can't do all those bindings at the same time. I need some web support for the project infrastructure, for the rest I will let it depend on funding.

posted by: Kaj 23-Jul-2022/17:46:28-7:00

I compiled the code above using run.com on Windows. It runs on the command line. I get a 500 internal server error when calling it from a pig.cgi in Uniform Server:

#!./pig.com

BTW, this morning I did get the Pico W blinking morse code returned by the Rebol CGI below (using Anvil to send strings entered by the user to the Rebol script, and then send the returned morse code to the Pico W via Anvil uplink):

https://re-bol.com/morse.cgi?x=SOS

Now I can use my phone (or any other remote device) to flash Morse code messages on a Pico W which is simply connected to a power supply at my girlfriend's house (the Pico is connected wirelessly to her WIFI). She doesn't know Morse code, but it's romantic to send her sweet messages. Maybe I'll add a Twilio text message to translate for her...

It's special for me because Rebol does the Morse code encoding.

posted by: Nick 23-Jul-2022/18:01:27-7:00

:-)

Thanks for testing!

Did you add a query string? Like
?x=piglet

The program isn't robust against missing input. It may print an error message, or crash; I didn't check.

posted by: Kaj 23-Jul-2022/18:49:43-7:00

I tried:

http://localhost/pig.cgi?x=this%20is%20cool

posted by: Nick 23-Jul-2022/19:34:18-7:00

Any chance you could try a different web server, of different operating system?

posted by: Kaj 23-Jul-2022/19:51:07-7:00

It works on Linux:
do.metaproject.frl/examples/PigLatin?x=pig

But I made a mistake in the vowel parsing. I'm working on a fixed version.

posted by: Kaj 24-Jul-2022/7:33:06-7:00

It does look like the current Meta version is robust against missing input. It just returns a blank response. (Unlike the REBOL version, which errors.)

This came about naturally, because of all the built-in REBOL-style checks for NONE values. (Other languages that have it call them option types.) Meta is not crash proof yet, but it usually already feels like a safe language.

posted by: Kaj 24-Jul-2022/13:24:28-7:00

Our first collaboration :)

https://metapig.anvil.app

although, I'm currently getting "atinpig%20lay" as a response for:

http://do.metaproject.frl/examples/PigLatin?x=pig%20latin

posted by: Nick 24-Jul-2022/14:13:12-7:00

Very cool, thanks for that!

Please change "Convert with REBOL" to "Convert with Meta". :-)

Yes, I found several bugs in my parsing. Working on them. Also, URL encoded %20 is not converted to space yet.

posted by: Kaj 24-Jul-2022/14:48:56-7:00

Oops, missed that 'Rebol'. It's changed - and the string returned from Meta is decoded :)

posted by: Nick 24-Jul-2022/15:52:33-7:00

Thanks, but I have to implement that URL decoding, otherwise I can't separate words.

posted by: Kaj 24-Jul-2022/16:09:13-7:00

Fixed the vowel parsing.

posted by: Kaj 24-Jul-2022/18:48:47-7:00

5 Minute CRUD run-throuh with Anvil:

https://www.youtube.com/watch?v=IF9uCnIkTc8

posted by: Nick 25-Jul-2022/15:54:19-7:00

Oops, better version of the video content above:

https://www.youtube.com/watch?v=cEtpJVh8UzI

posted by: Nick 25-Jul-2022/22:05:14-7:00

Cool.

Implemented URL decoding of %20:
do.metaproject.frl/examples/PigLatin?x=This%20is%20rad

posted by: Kaj 26-Jul-2022/5:28:24-7:00

Here is the new version:

  
  Meta [  
      Title:   "Pig Latin example for CGI"  
      Author:  ["Nick Antonaccio" "Kaj de Vos"]  
      Rights:  "Copyright (c) 2020-2022 Kaj de Vos"  
      License: {  
          PD/CC0  
          http://creativecommons.org/publicdomain/zero/1.0/  
      }  
      Purpose: {  
          Convert (space separated, English) words to Pig Latin through CGI.  
      }  
      Notes: {  
          https://en.wikipedia.org/wiki/Pig_Latin  
    
          Ported by Kaj de Vos from the original in REBOL 2 by Nick Antonaccio:  
          https://rebolforum.com/index.cgi?f=printtopic&permalink=Nick16-Jun-2022/11:12:40-7:00&archiveflag=new  
      }  
  ]  
    
  write/line {Content-type: text/plain  
  }  
  text: find/tail select/case system/environment "QUERY_STRING"  "="  
    
  while all [text  not is-tail text] [  
      text: if space: find word: text  "%20" [  
          word: copy cut text space  
          skip space 3  
      ]  
      unless is-empty word [  
          vowel: none  
          character: word  
    
          until any [  
              is-tail character  
              if find "aeiou"  copy cut character 1 [vowel: character]  
          ][  
              advance character  
          ]  
          write  either is-same word vowel [  ; Word starts with vowel  
              write word  
              "yay"  ; way, hay  
          ][  
              write  either vowel [  
                  write vowel  
                  copy cut word vowel  
              ][  
                  word  
              ]  
              "ay"  
          ]  
      ]  
      write " "  
  ]

posted by: Kaj 26-Jul-2022/5:37:43-7:00

It's a good example of several things that still need to be improved in Meta. It's probably similar to REBOl 1 before it got string PARSE. Your REBOl version shows the improvement that PARSE brings.

posted by: Kaj 26-Jul-2022/5:47:15-7:00

I tried the CGI in its portable version on Linux. It runs, but doesn't process the input. It could be that the portable Meta programs don't support environment variables.

I compiled a version specific for Windows:
language.metaproject.frl/programs/test/PigLatin-CGI.exe

Could you please try that on Uniform Server?

posted by: Kaj 26-Jul-2022/8:11:19-7:00

500 Internal Server Error:

I'm running an old old version of Uniform Server, here's the log:

[Tue Jul 26 22:05:12 2022] [error] [client 127.0.0.1] Z:/public_html/metapig.cgi is not executable; ensure interpreted scripts have "#!" first line
[Tue Jul 26 22:05:12 2022] [error] [client 127.0.0.1] (9)Bad file descriptor: don't know how to spawn child process: Z:/public_html/metapig.cgi

Probably calling your executable incorrectly:

#!/usr/bin/PigLatin-CGI.exe

No permissions need to be set in windows. This is how I call Rebol in that same folder - the following script works:

#!/usr/bin/rebol.exe -cs
R E B O L []
print "content-type: text/html^/"
print ["Test"]
...


When I run PigLatin-CGI.exe at the command line, it works properly:

Content-type: text/plain

How should I pass the arguments to PigLatin-CGI.exe in the line first line of my metapig.cgi script?:

#!/usr/bin/PigLatin-CGI.exe

posted by: Nick 26-Jul-2022/22:15:19-7:00

PigLatin-CGI.exe is not a script interpreter, it's an executable of the compiled program. It executes very differently from a REBOL script.

It should be straightforward to run as CGI: it's the simplest case. But every web server sets it up differently, so I don't know how Uniform Server does it.

There are no arguments to pass. The argument is in the query environment variable, which is part of the CGI interface standard.

posted by: Kaj 27-Jul-2022/6:40:38-7:00

From your description, normally,
Z:/public_html/metapig.cgi
would have to be
PigLatin-CGI.exe
not a script.

posted by: Kaj 27-Jul-2022/6:52:12-7:00

By default, Apache on Windows just downloads the .exe file. It's been a while since I've messd with configuring Apache...

posted by: Nick 27-Jul-2022/11:08:38-7:00

It just needed to be put in the cgi-bin folder. It works as expected:

http://localhost/cgi-bin/PigLatin-CGI.exe?a=this%20is%20cool

returns:

isthay isyay oolcay

posted by: Nick 27-Jul-2022/11:17:43-7:00

Cool, thanks!

Could you also try a .com version that you compiled yourself?

posted by: Kaj 27-Jul-2022/11:25:27-7:00

BTW, the program that I compiled previously using run.com (I named the file pig.com) does also run properly in Windows Apache, accessed via CGI:

http://localhost/cgi-bin/pig.com?a=this%20is%20cool

returns:

is%20is%20coolthay

(that was the old code, but the executable runs fine)

posted by: Nick 27-Jul-2022/11:28:01-7:00

Great!

posted by: Kaj 27-Jul-2022/11:35:24-7:00

Thanks very much for testing! It's good to have gone through the CGI use case, because it's one of the first things that Meta is suitable for (as evidenced by all my project web sites).

Concluding, you made me find a problem with Meta's current released portable format. It's based on the Actually Portable Executable format, that modifies itself on first run to adapt to the platform. It turns out that my Caddy web server on Linux can't run this format. I would expect the same problem with other web servers on other Unix systems.

Since the .com format is actually a native Windows format, it's apparently not a problem on Windows.

So Meta can currently be used for CGI on Windows, but probably only I can use it for CGI on Unix. I need to release the Meta compiler for more specific target platforms to solve that.

posted by: Kaj 27-Jul-2022/12:17:35-7:00

Piece by piece, it'll get done ;)

posted by: Nick 27-Jul-2022/21:13:16-7:00

Nik, can anvil.app give data from the table to another program? For example - need to process from people.anvil.app in Rebol, how can I get them?
>> a: read http://www.pochinoksergey.ru/sslv3/proxy.php people.anvil.app
connecting to: www.pochinoksergey.ru
== ...
but there is only 100 kilobytes of anvil.app code, without data from the table.

posted by: Sergey_Vl 27-Jul-2022/23:33:24-7:00

I cover consuming and creating web APIs in my tutorial:

https://pythonanvil.com/#section-19
https://pythonanvil.com/#section-20

posted by: Nick 1-Aug-2022/12:24:01-7:00

For example, I added this function to people.anvil.app:

@anvil.server.http_endpoint("/somedata/:column")
def get_columns(column):
    return [str(u[column]) for u in app_tables.people.search()]

That gives me any column from the 'people' table, like this:

https://people.anvil.app/_/api/somedata/name
https://people.anvil.app/_/api/somedata/address

This function gives returns the whole 'people' table:

@anvil.server.http_endpoint("/getdata")
def get_db():
    return [str(dict(u)) for u in app_tables.people.search()]


https://people.anvil.app/_/api/getdata

posted by: Nick 1-Aug-2022/17:56:55-7:00

It really looks very simple! Thanks for the example.

P.S. Sorry for the stupid question, I haven't started translating your anvil tutorial yet, but I'll definitely do it!

posted by: Sergey_Vl 2-Aug-2022/7:46:54-7:00

Not a stupid question. Lemme know if you have questions :)

posted by: Nick 8-Aug-2022/11:36:46-7:00

Graham,

I just noticed that someone in the Anvil community wrapped the chessboard.js library:

https://jschess.anvil.app/

As a learning exercise, I'd like to implement the saving and replaying of games, as you did.

posted by: Nick 8-Aug-2022/14:50:41-7:00

I published a tutorial for Streamlit:

http://streamlitpython.com/

posted by: Nick 3-Nov-2022/9:53:45-7:00

I published a tutorial for Streamlit:

http://streamlitpython.com/

posted by: Nick 3-Nov-2022/9:53:46-7:00

I'll a sk the obvious: have you dumped Anvil? :-)

posted by: Kaj 3-Nov-2022/14:29:37-7:00

Of course not. Streamlit's just a nice tool for quick in-house apps. It was made to support all the Python visualization and ML libraries natively out of the box, but useful for simple CRUD tasks too.

posted by: Nick 4-Nov-2022/15:58:50-7:00

Anvil is still stupendously productive and all-encompassing in the broad capabilities it provides. I've made quite a few clients happy with it this year, creating solutions for a huge variety of development tasks - I don't think there's anything else quite like it :)

posted by: Nick 4-Nov-2022/16:10:58-7:00

I think it's far more productive than any of the 'low-code' tools that are gaining market share (even in the small domains of work they occupy), but dramatically more capable, as a 'pro-code' tool with the full Python ecosystem backing it (and of course with a super convenient built-in database, UI builder, API endpoints, lots of integrations, etc.)

posted by: Nick 4-Nov-2022/16:15:44-7:00

To give you an idea, since July:

I built a payroll and billing system for an accounting firm (with time tracking, PDF generation, lots of varied reporting and admin panels, automated email and text alerts for clients).

I built an app to help a vision therapy business collect and calculate patient evaluations (and also a small supply ordering app for them).

I built a prototype machine management app for a large IT firm, with an API that's designed to scale reliably to at least 300,000 requests per second.

I helped extensively in building a large commercial marketplace web site app for a niche retail industry in Canada (launching early 2023).

In integrated a Typesense database with Google maps API, used to find locations based on 'fuzzy' search.

I built an authentication system based on IP addresses, to integrate into an existing shift clock app.

I built a personal photo sharing app for a private individual, with an all-original custom carousel widget designed from scratch, folder authorization, and other precise feature requirements.

Little projects: I built a QR code reader, a Twillio SMS text integration, an API that delivers XML results from database queries, a pub-sub communication system, a Tabulator (complex JS grid) implementation that works equally well on mobile and desktop, a background video web page layout template, a custom tree grid component built from scratch, a Markdown editor, an FTP utility, a Daily.co video conference integration, a Quill wysiwyg HTML editor integration, a UI to control wireless Pico W microcontrollers, and lots of various little CRUD components for clients.

I built an in-house tool for organizing recitals and generating jazz chord diagrams for students in highschool jazz band (used at my Rockfactory business), an automated invoicing system which I use for all my clients, and also my personal web site at com-pute.com

I'm currently working on integrating a bar code scanning feature into an ordering system used at a hospital.

I built the front end to a machine learning project by a data scientist who wanted to publish his model online (using Streamlit).

posted by: Nick 4-Nov-2022/18:29:30-7:00

That's all been in my part time. I still operate and teach at Rockfactory 3 1/2 days a week, and spent a lot of this year running and teaching at my paramotor school (I'm the East Coast dealer for the largest paramotor manufacturer in the US). Anvil is productive.

posted by: Nick 4-Nov-2022/18:35:01-7:00

It's not just productive - I *enjoy* working with it more than any other tool I've used - it's simple, quick, and genuinely painless to accomplish the majority of common development tasks that I like to take part in. It's been a life changer for me, I'm happy to take on projects again :)

posted by: Nick 4-Nov-2022/19:47:14-7:00

That's certainly impressive. What I always wonder about with such projects, is how they are supported. Do you update them over time? If not, do they not suffer bit rot over time? If yes, do you not feel it's a burden to have to support multiple application platforms?

For me, I have always wanted to support projects long-term, but the maintenance always became a problem over time, to the point of turning into nightmares. One of my strongest goals is to prevent that.

posted by: Kaj 5-Nov-2022/4:04:47-7:00

The lifecycle of every application is different, but almost all of them change and evolve to varying degrees. One of the things I loved about Rebol was that it was so small and instantly installable, that I could go to any client's location, set up a development machine in a minute, work with them interactively in person, live coding to prototype and create actual working code with a fantastically agile workflow. I could make changes to code files by email, by sharing remote desktops, etc.

Anvil is even more effective in that regard. First of all, to get worm done, I can be anywhere, on any device (even iPads work great, for example), and because every piece of a project is hosted - even the IDE - I can get work done everywhere
    I move constantly between machines and just pick up right where I left off, with the exact same environment, without any setup or installation. I can be at my girlfriend's, working while she's on the phone, or waiting for an appointment at the doctor's office, etc. I've never experienced convenient and quick/productive workflows in my spare time, like that. And delivering changes is as easy as telling a client to refresh their browser, wherever they are, on their phone, desktop, etc. And Anvil has a full versioning system (backed by GIT), which allows you to constantly save a current version, revert to it at any point, and set any version as production, so you can work on and run development versions without interrupting the production version, roll back changes to production version at any moment, copy paste between verions, etc. And at any moment, the user just resfreshes their remote browser for a full update. Delivering constant little changes to software is now instant, fun and satisfying - and I just log any hours into my little Anvil based invoice system, wherever I am, so a get paid for every minute of work :)

If I ever need help with building projects, I could hire a designer, even someone without any coding background or much experience laying out interfaces, and train them in a day to complete simple time consuming layout tasks. I thought I wouldn't like using a GUI builder. and spent a lot of the getting better at building interfaces with code in Anvil, but the overwhelming majority of layout tasks just take a few minutes with drag and drop, and making significant changes is always easy.

posted by: Nick 5-Nov-2022/10:16:25-7:00

I understand, I have part of that workflow down already with the Meta web console.

But what I mean is what happens when Anvil, Streamlit and the other environments you have used to build apps release updates. Some of them are bound to break your (old) apps.

And when they stop being supported and stop releasing updates, your apps may break when the world changes. Such as R2 not supporting SSL.

posted by: Kaj 5-Nov-2022/12:48:32-7:00

You can self-host any Anvil app using the free Anvil server, if you want to freeze it in its exact state (or if Anvil hosting ever goes out of business). I download a copy of the server software occasionally so that I have snapshots of it at various stages.

When it comes to technology moving on, and needing to connect with new paradigms, that's just part of any software development process. The thing with Anvil is that it's all pure Python, with a Python-JavaScript bridge. The server particularly provides access to the full Python ecosystem.

The 2 most common types of SDKs and documentation examples that are provided with every new technology are typically Python and JavaScript. And the combined user base of Python and JavaScript together FAR outsizes any other group of developers on the planet. So it's hard to imagine a tool more prepared to move forward into for the foreseeable future. And when we're past the foreseeable future, I expect there will be something better than Anvil and everything else we're imagining at the moment...

posted by: Nick 5-Nov-2022/15:54:51-7:00

One of the things to keep in mind is that something like the core Anvil API is made to stay consistent, despite changes to the underlying layers of architecture. I've been able to use Anvil on more machines, in more versions of browsers than any other modern framework I've found. I've been really happy to see Anvil apps run on even the inexpensive mobile devices I have that are a decade old, and on low powered single core 32 bit netbooks running Windows 7 from 2009, with Palemoon browser (Chrome doesn't even run nicely any more on those old machines). And the thing is, I can buy a pile of new Android phones for $29 each at Walmart, and run an Anvil app on them immediately, without having to install anything. If some client isn't happy with those flexible possibilities, I'm not interested in working with them.

posted by: Nick 5-Nov-2022/16:04:37-7:00

I'm happy to pass off the hard work of maintaining APIs and coordinating all the other pieces of infrastructure to a company whose only job it is to do that. They seem to have done a great job for the past few years, and based on the best practices I've seen them implement, I trust them to do a better job than almost any other project I'm aware of. Again, if you need the guarantees of full control, just self host.

posted by: Nick 5-Nov-2022/16:08:12-7:00

I'm playing with a ton of Python, but also some JS frameworks. I really like Quasar (a VUE component framework) + Google Firebase/Firestore + FastAPI. I'll most likely end up using that combination in the future for projects which require heavy scaling, and actual Android and iPhone front end apps (app store type apps). NiceGUI is another Python framework, actually built on an old version of Quasar.

I'm even playing with some no-code tools like Appgyver and Appsmith for quick solutions to particular limited problem domains. There lots of fun free toys available to waste my time :)

posted by: Nick 5-Nov-2022/16:52:13-7:00

BTW, for Streamlit (or any Python libray), you can pip install any version, and pip even lets you create separate environments on a system, all with different versions of any library(s) you want, so that you don't have any library version conflicts on a machine - environments are basically folders containing a full install of Python and all the libraries you want to use, with the particular versions of every library you need for the project. Most Python developers create a new environment for all but the simplest projects.

A requirements.txt file can be used by pip to install a complete list of all the libraries needed (in the correct versions) for project. When deploying apps on remote servers, you can bundle the entire system setup, including python version, libraries, network settings, etc., using Docker containers, so that the exact environment needed is reproduced on the remote system - that avoids any bit rot or broken apps, and makes it really quick and easy to install on cloud computing platforms. Python makes every part of that process very easy to control and manage (pip is built in to the standard Python distribution on every OS).

The Python ecosystem is pretty great :)

posted by: Nick 6-Nov-2022/21:53:56-8:00

https://thomas-berweger.medium.com/ermittlung-der-%C3%A4hnlichsten-fussballspieler-mit-dem-knn-algorithmus-in-python-e9b04fc4a70e

I wrote the Streamlit code used to publish the model in that article (running at https://fifa-similar-players.streamlit.app/ )

posted by: Nick 7-Nov-2022/10:18:12-8:00

I dealt extensively with dependencies in the Syllable operating system. While it can be a good idea to include dependencies with your app to isolate them from the system, it causes another problem in that they are not updated anymore, so you don't get fixes, including for security and changing circumstances in the outside world. They may even stop working with newer versions of the host system.

These two sides that both cause their own problems must be carefully balanced. Going to the extreme on either side is not a solution. The only way to really reduce the problem is to reduce complexity.

posted by: Kaj 7-Nov-2022/10:58:28-8:00

In any Python environment, updates can be made to any library in that environment at any time. With Rebol we had a particular problem with our tools not being kept up with the rest of the world, because the pool of developers was so small. That's not at all the case with Python. There are millions of developers and users all ironing out problems and helping keep all the pieces up to date and working properly in different environments. That rich and lively ecosystem, along with the fundamental pieces, PEP, and ethos are Python's way of beating complexity - and in my experience, it's working fantastically.

I do think Rebol is a better fundamental design, and the ethos of reducing complexity was approached in the best way I've come across, but without support and an extremely large and productive ecosystem, Python solutions currently provide the best simple, productive solutions, without the sorts or troubles you're expressing concern about, which I have been able to find. Together with the mess of JS - used only where absolutely needed (extremely rarely in the tools I'm using), there's the possibility to accomplish the broadest range of tasks with the least work.

You're working on building better tools, I'm working with the best tools I can currently use. I sincerely hope you're succesful!

posted by: Nick 7-Nov-2022/11:29:04-8:00

I understand what you're saying, and we'll have to leave it at that for now, because Meta is a lot of work. On the other hand, I have no reason to believe that Python is immune to dependency problems. JavaScript has the same enormous support, and it can't be that it's a mess in a limited, controlled environment, while Python is problemless on general platforms.

My experience is with systems and libraries in general languages, but mainly C and C++. They also have the same enormous support. Yet, REBOL is much more problem-free, except for a small number of well known problems, that nevertheless ruin the experience because support went to zero. Fixing REBOL's problems is doable, while fixing huge ecosystems is practically impossible.

posted by: Kaj 7-Nov-2022/16:47:27-8:00

The way things are moving these days, with web APIs forming the backbone of so much processing work, database storage, Etc., it's not anywhere near as hard as it used to be to keep dependency issues from causing problems. Even on a single machine, you can have a bunch of separate little app pieces all running entirely in their own environments, each of which could potentialy have tremendous problems working together, if they were in the same environment, but now they all work in their own little worlds and communicate with each other and the rest of the world via REST API. And it becomes even less of a situation when you deploy any of those little pieces of app and API onto separate dockerized containers running, for example on some cloud host. They're all entirely separate environments, with OS, language versions, database systems, and all the library dependencies running in their own little universes. Any piece that doesn't play well with any other piece can just be separated entirely into an entirely different containerized little universe.

posted by: Nick 7-Nov-2022/19:13:45-8:00

Low level system development, and game development, are very different markets, and use very different processes - game development is mostly tied to using
Unity, Unreal, Godot, and all the other game engines. I think the world has lost the sense of ever having a single tool set to do lots of different categories of work.

posted by: Nick 7-Nov-2022/19:27:05-8:00

No one is going to use Anvil to build a console game, or to develop a new os, or browser. And no one is going to use C to build a web app.

posted by: Nick 7-Nov-2022/19:32:52-8:00

Ah, yes and no. Indeed, Anvil and such are limited to business and web apps. Meta covers the whole range of programming domains, so there is really no comparison. And if those web apps can only work by exploding their complexity into many large containers, while Meta covers its whole range with a small, unified system, that's a very good sign to me. They're not very different to me, that's a myth.

www.infoworld.com/article/3639050/complexity-is-killing-software-developers.html
qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/

Yet, I am using C to build web apps. I write them in Meta, Meta compiles them to C, and the enormous support ecosystems of web and C compile them to JavaScript for me.

I have been a proponent of service-based design for a long time. It shouldn't be done to avoid solving the problem of dependencies, but it is a solution to making subsystems in different languages communicate, and to migrating old systems to new ones piece by piece. Like how we made Meta and Anvil communicate here above.

posted by: Kaj 8-Nov-2022/5:46:48-8:00

I was lobbying to get Rebol ported to mobile platforms and the browser more than a decade and a half ago. No one seemed to care. I watched the core language get ported to WASM, but with absolutely no thought about attaching it to a UI, or being able to connect to a server to save and data in a centralized location, so those projects never saw much daylight. With even a simple GUI in the browser and a way to connect to a server platform to persist and use data, plus just a bit of basic hardware control, all using the same language, the possibility exists for practical use. I'd love to see a small Meta tool kit like that take root - because then more and more users would begin to grow the system, and there is the possibility for life.

I built hangman and my guitar diagram maker with Anvil, as part of the first explorations with it, but that's not even in the same ballpark as creating massive multiplayer virtual reality games, which are relatively painless to create with modern game engines. Like everything else, if there is enough support, tools can potentially grow in every direction. This guy is creating awesome business apps with Godot:

https://github.com/alfredbaudisch/Godello

And here's an interesting article about why that's a great thing:

https://medium.com/swlh/what-makes-godot-engine-great-for-advance-gui-applications-b1cfb941df3b

That's happening with Unity too. All because there are many users, and the fundamental building blocks are there to be used in useful ways.

I think once any language is running in the browser, with a useable UI, and some connection to a server running the same language and data structures, with access to a file system/database and hardware, then the building blocks are available for a community to start doing useful work with a toolkit. That seems to be a worthwhile goal... I'll be right there trumpeting the value of such a system, with Rebol-like language and ethos!

posted by: Nick 8-Nov-2022/22:53:28-8:00

I'm having a strong reaction to this topic, because it's important to me. I fell in love with Rebol 20 years ago because it made complicated tasks easy to accomplish. That was the case not just because Rebol had a great language design, but even more importantly because it included a massive variety of built-in capabilities which were engineered specifically to address a broad scope of problem domains, and it provided a beautifully integrated language interface to deal with common task in each of those domains, all in a tiny package that ran exactly the same on more OSs, better than any other software development available at the time. First of all, that cross-platform landscape was very different back then, with lots of new OS contenders that appeared to be gaining market share. There were certainly some awesome language concepts that worked beautifully in ways that were never really fully explored - dialects were probably more important.

In my experience, it was the really deeply thought-out set of well-engineered and all-encompassing built in tools, along with the way the language unified all those tools, which helped to make Rebol so productive. It wasn't just the language - and I think so many developers in the Rebol community missed that. They seemed only interested in the pure language - but without all the tooling that came with Rebol, it would have been just another academic curiousity. It was it's ability to handle graphics, sound, networking, all the built-in network protocols, file management, etc. all with the same series functions, that made it so useful. Just the idea of having series functions manipulate all the data is a great design idea, but without all the actually well implemented, well integrated realizations of all the deeply engineered useful pieces of technology that came in that tiny package, Rebol would have been useless for any practical purpose. Without the ability to run it on any platforms, the language ideas would have just been ideas. Rebol was a success just as much in how it actually provided so much tooling in a fantastically small package.

I don't think is was as important that Rebol was small, and that certainly doesn't matter as much now. What mattered was that it was capable at handling so many different problem domains.

You seem to have a drive to accomplish the same goal. I hope that the idea of simplicity doesn't get prioritzed in that end, to the point that the more important goal of capability doesn't get lost. A simple tool that can't accomplish and goal is useless. A powerful tool that tool difficult to use productively is also useless (the case with many other tools, especially in the past).

In recent years, the quality and productivity of development tools has improved dramatically. My realizations with Anvil and Python, in regards to those improvements, have been particularly powerful. Anvil's built-in tooling a broad range of capability dramatically outweighs anything Rebol was ever capable of - in PRACTICAL TERMS. The facility with which you can accomplish SO MUCH of the typical software development problems - in this MORE COMPLICATED modern environment, demonstrates just how much deep engineering has gone into succesfully providing consistently useful tools that enable working software to be created more productively.

Standing far enough away from any language, framework, tool, etc., without actually using it, it's easy to make simplified assumptions and generalizations, but without actually using those tools, it's not possible to gain a feel for all the benefits that come from the many many designs decisions that pay productivity dividends to the developer.

The truth is, Anvil's creators have pulled off a phenomenal practical accomplishment. They've worked on easing the pain points that every developer encounters when working with an overwhelming majority of common problems. Over and over, in thousands of moments, I've just continuously said to myself, holy shit that was easy. Much easier than any experience I ever had with Rebol - and the fact is, I'm aware that each of those realizations is accompanied by an understanding that each of those truly well designed solutions I've discovered runs really deep, so that a much broader set of problems in each category I encounter can be handled with just as much simple work.

Yes, the environment that Anvil works in is very complex, and that sucks, but that environment is not going away any time soon. The point is not just to have a simple tool, the point is to have a tool that is simplifies handling the broadest set of problems in a complicated environment that must be tamed. That takes not just and ethos, but lots and lots and lots of actual engineered and well integrated solutions to lots and lots and lots of specific problems that aren't going away. Anvil has done an absolutely fantastic job of harnessing the Python language and ecosystem to beat those problems, providing real worked out, industrial quality solutions and tooling to areas of the ecosystem where there were non in Python, and integrating them into a tool that encompasses more of the modern development landscape than any other I've even seen, and I've spend more than 3 decades learning, exploring, and using every imaginable tool, no matter where it sat in or outside the mainstream spectrum.

Being able to integrate and leverage existing tools, languages, and ecosystems is so important in the modern landscape. That's what Rebol did so well. It connected so much of the existing core componentry of the ecosystem, in ways that were beautifully and productively composable. Anvil does the same with the modern landscape of technical building blocks. I still think that a Rebol based language has the potential to tame that sort of integration even better, but only if that's the goal.

I'd like to write more, but it's 3am...

posted by: Nick 9-Nov-2022/2:58:31-8:00

I'm sorry, that was very messily written and totally unedited, but I hope at least the general idea comes across - prioritizing capability and integrating existing complicated building blocks in ways which dramatically cut down how complicated those building blocks are to use and and produce working solutions with, I think sould be the only end goal. That's what tools like Unity, Godot, and do. And so much of what makes any tool useful is the degree to which the most important goals are made easier to achieve. The greater the number of useful goals that can be achieved and integrated, with the greatest productivity, the more valuable and useful that tool with be.

The ethos of Rebol was brilliant. The number of engineered solution that were shipped in that tiny package was mind blowing. The integration of all those solutions, and the composability of the pieces was better thought out, and laying a foundation for the lessons learned by what Carl created do provide a basis for more powerful, more simply designed solutions in the future, and I absolutely support trying to achieve that goal.

posted by: Nick 9-Nov-2022/3:13:06-8:00

I just need to be able to get work done, and I've been around the block a few hundred times. Anvil is pretty damn amazing at satisfying the needs of a productivity craving madman who builds working software solutions for clients in hours/days rather than weeks/months. I'd love to see a better designed system, and I'd love to see a system that beats complexity, from its core design principles on up, and I think what Carl proved is that Rebol can actually do that, but only if it starts where Rebol left of in terms of integrating lots and lots of well engineered, natively integrated tools that can connect with, tame, and make all the existing tools in the mainstream computing environment more productively composable.

posted by: Nick 9-Nov-2022/3:18:50-8:00

'No Code' and 'Low Code' buzz is tremendous right now because there's an outrageous demand for the solutions they provide. I can talk to almost any small gathering of people and find business clients who have real needs that could be satisfied by solutions created by those sorts of tools. Most of those tools are simply front end builders with perhaps a database system and a way to connect to rest APIs to process, store, and manipulate data in useful ways - basically CRUD building systems. The market for APIs that perform valuable data processing capabilities not just for the no-code, low-code community, but for every other language tool that connects to them is growing like crazy. Microsoft is building its Power platform with the intent of fully integrating 'no-code, low-code, and pro-code'. Backend solutions like Firebase, Xano, Deta, and a thousands of others are finding hungry markets. I personally think Firebase and Firestore are going to grow dramatically, because that platform satisfies the real needs of projects that need to scale.

No-code and low-code tools are all really limited, but they enable real productivity for a narrow portion of the software development market, and that helps to produce growth, plus the existence of new useful APIs and backend systems which can be easily integrated everywhere else in the market makes other development tools of every kind, no matter the language or platform, all more productive. That growth and standardization represents a true simplification of the entire system, in ways that are palpable and actually effective for a bigger portion of the market.

Meta can take part in that growth immediately. Take the tact of all those successful no/low code tools that are getting many millions of dollars in funding, and build a tiny tool set that can accomplish all the same goals and more, and you've got a potential goldmine. Make it easy to connect to REST APIs, provide a simple to use UI builder, provide access to file system, database, email, PDF printing, etc., and make it tiny and self-hostable, and you'd fill a niche in an absolutely huge growing market which is also attracting lots of investment capital. Producing that sort of tool set (one that could compete with the no-code tools in simplicity) is also a potentially achievable goal, and one that could attract an enormous user base. I'd be genuinely excited to see Meta go in that direction.

posted by: Nick 9-Nov-2022/3:52:08-8:00

:-) All agreed. We went through the same REBOL valley of tears.

I don't see anything in Meta's goals that contradicts yours:
language.metaproject.frl#goals
On the other hand, it's still early days. I can't advertise that I aim to replace Anvil and everything, because we're still focusing on the base language, and people already can't believe what has been accomplished so far.

REBOL is a navel-gazing silo, albeit a tiny one, except for network protocols. It was meant as an Amiga OS successor and was designed that way. REBOL has very little interest in integrating with other operating systems locally. It's a jealous language: it keeps its inventions to itself, literally afraid that MS would steal them. But as Mark Twain said, if you have something really innovative and good, you shouldn't fear it gets stolen, because you will have to push it through people's throats. That's exactly how it feels promoting Meta now. :-)

Everybody was expecting Amiga OS 2.0, even more superior consumer multimedia, but what we got was iOS: a sort of operating system for the Internet, for business apps. That was very interesting to me, because I was into Lotus Notes, simultaneously doing things that no other technology could do at that time, and running into its limitations. I saw that REBOL fixed those limitations by carefully designing systems like operating systems, including a pervasive language. It's fine to build business apps or multimedia or whatever on top, but to make that work, a carefully designed system needs to come first.

So that's the phase Meta is in, but we also need to fix REBOL's problems, that manifested later. Meta is taking down the ivory tower. It is designed to integrate really well with local systems, libraries and operating systems, and improves them by extending its innovations to them. In Meta, series work not only as its internal data types, but also as abstractions over the data types of those external subsystems. Instead of resisting other systems, Meta embraces them, and uses their power for its own purposes. Using libraries from Meta will be better than using them from other languages.

REBOL only does that for network protocols. That was great while it lasted, but resisting local integration eventually made REBOL fall behind.

Also, REBOL is implemented as an interpreter. Anything wrong in it is always there. Meta is designed for compilation. It is very incomplete now, but compiled programs are of production quality, unless you need garbage collection in long-running programs. Meta being incomplete is of no concern to me as long as it has the features to compile my programs. To make it of no concern to others, I can implement the features they need.

Obviously, I can't implement all the features you speak of of all other systems out there. I won't live long enough, and it would mostly be chasing tail lights. Therefore, Meta's strategy is to use other systems' strengths for our own purposes. This can be using them over the network, or using them locally with tight integration. Just what other parts of the modern ecosystem do, only better.

Older systems get replaced by better ones by being eaten up from the bottom when they have become too fat and slow.

Interfacing all those systems is still too much work. I have to be very selective about them. My own needs are an obvious criterium. To do substantial work for others' needs, I will need funding to keep going. This needs to be fixed, as well, because it was another reason for REBOL's demise, hence why I am running the project differently.

Eventually, opening up Meta's architecture should allow everyone to contribute their own needs, and create an ecosystem similar to Anvil and such. Here we run into the limitations of using other projects: because Meta makes extensive use of existing subsystems, it's hard to open source in a managed, meaningful way. This will take time.

posted by: Kaj 9-Nov-2022/9:37:12-8:00

Sorry, Mark Twain could have said that, but it was Howard Aiken.

posted by: Kaj 10-Nov-2022/15:53:51-8:00

I'm really curious how you're planning on positioning Meta for a particular market. It strikes me that you could have a unique product in the 'low code' arena. It's so much smaller and more agile, and something maybe you could market as a 'low code system for *developers' - something uniquely lightweight that provides solutions to the same sort of problems that low code tools do, but with even greater productivity, and made for developers who don't want anything to do with drag and drop builders. I have this sense that at the moment, just tacking on the words 'low code' could find you a market. And what the majority of successful low code tools do is very simple. Most are just front end UI builders that connect to Rest apis to provide services and data storage. Tools like Appsmith are getting tens of millions of dollars in funding. I have to imagine you could get a good team together to really build up Meta if you could find that sort of funding.

I think the idea of a low code tool could potentially be sold to something like a significant portion of the IT community, where professionals might feel silly using the same drag and drop builders that totally untrained 'citizen developers' use - and they're a group of people who have some minimal coding skills already, and are likely to hear requests for lots of little in-house apps to be built. Positioning Meta as the 'low code tool for IT professionals' could be a way to find investors to help you build it.

posted by: Nick 12-Nov-2022/7:28:38-8:00

And of course, I'm not suggesting that that's all Meta should be - just a way to position it in the minds of investors, to get funding, and to find some initial market share. I think the key thing that strikes me is that building a minimal tool that can compete with something like Appsmith, could be a manageably-sized project to complete within a relatively short amount of time, especially if you could find the funding to hire a team. That would give you a starting point to build it up into a real language product that has so much more capability than anything else on the market, in that space.

posted by: Nick 12-Nov-2022/7:38:11-8:00

I have certainly been thinking about low-code tools for a long time. Successors to Lotus Notes, more or less.

There are some hurdles. If you show too much code, people won't understand the REBOL way. It can't be thrown into the market, REBOL knowledge must be learned slowly over time by gradually more people.

A tool with little code is more work to make useful, and the code fragments would probably need future dynamic features of Meta that are also more work to support.

I'm reluctant to take on investors. This pretty much destroyed the step from REBOL 2 to REBOL 3, and many other startup projects. With Syllable, we tried but didn't even get that far. We're in a similar situation now, where the world economy is tanking, so it's not a good idea now, and there are new ways to get funding.

That's why I'm keeping options open now. Meta can be developed to be suitable for almost anything, so I'll see what opportunities come along. As with the rest of the project, it should be done in small steps. Big steps carry way too much risk of failure.

posted by: Kaj 12-Nov-2022/12:00:52-8:00

I'm currently absolutely dazzled by Flutter together with Firebase/Firestore. Anvil is more productive, but I think it's hard to produce applications with cross platform front ends that are more performant, modern, and broadly capable than with Flutter (there's even a slick 2D game engine built on it (Flame)). Firestore/Firebase provides backend database and tooling that can scale instantly to any load, with features like live data syncing, and standard Google Cloud pricing. This stack is wickedly powerful in every way, and truly hard to beat in terms of professional application results, and it's very widely used. The low-code no-code SAAS called Flutterflow currently seems to be riding a wave of popularity in that environment too (it exports clean Flutter code).

Anvil is currently my go-to for getting work done, but I'm going to devote lots of time in the coming months to Flutter/Firebase.

posted by: Nick 13-Nov-2022/5:33:31-8:00

I've been looking into Flutter bindings for a cross-platform GUI, sort of as a successor to REBOL/View. It's dubious, because they integrated Dart for all the things that I could do better with Meta, so you would have to drag Dart along and have redundancy in your solution. It's an option, though.

posted by: Kaj 13-Nov-2022/5:56:05-8:00

A Meta dialect that generates Dart/Flutter code? I'd be *very excited* by that - and the potential market would be huge (literally a 'low-code developer's solution' for Flutter). And Flutter developers have already chosen to learn a new language to get best-of-breed results ;)

posted by: Nick 13-Nov-2022/7:17:28-8:00

It would probably be direct bindings to Flutter and perhaps indeed some generation of Dart. That's annoying, because an extra code generator would be needed.

Meta would be competing with Dart. Hard to predict how that would be received.

As a little market research, what would you like most: a dedicated web binding or Flutter bindings?

posted by: Kaj 13-Nov-2022/10:21:03-8:00

Well, you get web target with Flutter, and I think their whole design is probably better and easier to work with than the whole HTML/CSS/JS mess, but everyone is already use to dealing with code generators and frameworks in the web arena. I don't know if you can improve on Flutter tools, but you can definitely improve upon the options available for web - and the it's probably a better target for a lightweight system initially.

posted by: Nick 14-Nov-2022/13:11:31-8:00

Flutter is definitely to big a requirement for your users to install. One consideration you may want to take a look at is supporting old browsers, and maybe older systems, for the server side. I haven't looked lately at which, if any, old browsers still have some market share, but support for them is hard to come by in newer frameworks and development tools.

I can still use JSlinb to target even the very first iPhone browser, version 1 of Firefox, some ridiculously old version of Internet Explorer, etc., along with any recent browser. I haven't had to do that in a long time, but it's nice to know I have a tool kit to support UI on just about any legacy system. Hardware is very very cheap now, but there are reasons that institutions stick with legacy systems, and it's at least food for thought that you could perhaps find an initial market by supporting legacy systems - there may not be as much competition in that arena...

posted by: Nick 14-Nov-2022/13:59:38-8:00

Lightweight is what I'm worried about with Flutter. Browsers are not lightweight, and Flutter is not lightweight, particularly because you can't seem to use it without Dart. Shoehorning Flutter into browsers doubles the problem there.

No doubt the industry is used to these constructs and their costs, but that is what Meta seeks to rectify.

Even Google recognises this, because there is a separate project Material Design Components for the Web, which provides the MD look and feel, but lighter weight.

It's not just a burden for the industry, but also for me. An extra code generator for Dart would be a lot of extra work. One of the problems with all these "easy" components is that if you use too many of them, you take on a dependency burden that becomes impossible to maintain. Choices need to be made.

posted by: Kaj 14-Nov-2022/14:00:39-8:00

In the early Syllable and Red times, I minimised requirements on browsers, for example on my Try REBOL site, to be able to run in Syllable's browser without having to update it all the time. Browsers weren't capable of much, anyway.

To run Meta in the browser itself, I had to let go of that principle. To make it any use, one wants to be able to use all features browsers have. And it took a long time, but they're more capable now. To make my new web apps, the Meta web console and the chat forum, any good, I had to use newer browser features that Syllable's old WebKit browser doesn't have. Also, the current Meta web backend uses Emscripten, so I depend on what they support. On the other hand, I make the web console generate JavaScript, not WebAssembly yet. I'm not sure where the cut-off for my browser support currently is. Probably around a decade ago.

posted by: Kaj 14-Nov-2022/14:15:45-8:00

Minimum requirement for the server side will be Atari 8-bit with FujiNet.

posted by: Kaj 14-Nov-2022/14:18:54-8:00

The problem is that, to be useful for anyone, for any practical purpose, you need to support existing user platforms, while the whole point of what you're trying to accomplish is forge a path away from reliance on those platforms.

What makes sense to me, and where Meta can be useful, to acquire mindshare and community, is to provide the simplest possible wrapper for the most commonly used UI and data transfer platform, the web and HTTP - using the lightest possible tools and requirements to provide a uniquely productive and agile full stack solution that can satisfy the most common requirements needed to build business apps. My 2 cents is that that should consist of a simple UI that runs in the majority of browsers, a mechanism that can connect to the same language and data structures/database on a server, a mechanism for connecting with HTTP APIs (sending/receiving json, because that's the way structured data is transferred in most online environments now, like it or not), and a way to connect with C and other libraries on the server. That's a full stack, and when a Meta language interface exists to each of those layers of the stack, Meta can be used for a million and one useful purposes, and it can connect with the rest of the modern tech world in standard ways. Build that, and your community will grow, an Meta can begin to change the minds of its users about more fundamental values in computing.

posted by: Nick 14-Nov-2022/15:01:50-8:00

Clearly, those basic requirements should have nothing to do with Flutter, and probably should leave behind old browsers. Those other paths are things that are close to my thinking right now, but if you want to have a real impact, and really build a communinty, then focus on building the simplest possible full stack solution for a web UI builder, with support for consumption of HTTP API endpoint (with json data parser) in the browser, publication of HTTP API ('REST') endpoints on the server, and a way to connect with database and some body of useful libraries on the server.

posted by: Nick 14-Nov-2022/15:06:43-8:00

I think you'll find support if you can accomplish building that stack in the lightest way possible.

Again, what makes sense to me, and where the whole world will find value in tools you create, is if the system can create browser based UIs, consume REST APIs, Create REST API endpoints on the server, connect with a database (and file system) on the server, and connect with any useful body of libraries on the server (in any language initailly) so that the server REST API can produce some output of value, such as PDF files, edited images, AI results, etc.

I don't think the UI has to be that complex initially - most of it just HTML forms, and you can use any connection available to any database system to start out. Build a json parser, and be able to move values back and forth from the database. Even with just that much of a stack, the system is extraordinarily useful.

posted by: Nick 14-Nov-2022/15:14:41-8:00

Make a wrapper for something like ag-grid or tabulator and you've got a powerhouse of a business software development toolkit. And with that, you'd attract community that would build out the system and support all the other directions Meta has value to offer.

posted by: Nick 14-Nov-2022/15:17-8:00

Without that basic stack, I don't see how you'd be targeting anything except maybe the embedded market?

posted by: Nick 14-Nov-2022/15:18:50-8:00

What Meta has to offer is light weight, and that's appealing to many working developers, I'm %200 sure. But what's necessary as a minimum is REST API connectivity (that's how thing work now), and connectivity with a database. Even the server side language and library connectivity is not as important, as long as users can connect with web APIs (REST, HTTP endpoints, or whatever else you want to call them). The world is running on REST APIs. Without that, I think any new stack is doomed.

Why not even use Rebol to build that part of the stack? No one cares any more what language a web API is built with - that's actually the whole point - web APIs and json provide the common function interface and data structure of all modern web apps. Using any existing method to persist data with Rebol - it could be a very simple database system written in Rebol, or it could even rely on the old MySQL driver. As long as you can persist and exchange data using HTTP endpoint functions, that's all anyone cares about.

Then all you're really doing is trying to build a UI with a nice wrapper on HTML and maybe something like ag-grid.

posted by: Nick 14-Nov-2022/15:31:29-8:00

Following that train of thought, why not build as much as possible on existing Rebol solutions on the server side. Doing that, so much of your work is already done, and you can come up with a very clear plan regarding what to implement on the server in Meta, piece by piece.

posted by: Nick 14-Nov-2022/15:37:28-8:00

Start with just the simplest of UI widget toolkits, just a wrapper for HTML forms, connect to existing APIs, and go from there - demonstrate the ability to make a form layout in the browser, send and receive some data to/from a web API, and process some returned values with your existing Meta web toolkit, and you've got something that will turn heads.

posted by: Nick 14-Nov-2022/15:43:51-8:00

I think everyone is really starting to get used to stacks such as Firebase/firestore + . And even less than that - just any web UI + APIs. There are some many database as API and services as API, that's what everyone is composing with now. That's a full stack, and enough for the growing army of low-code no-code users to be able to create actually useful applications now. Begin with that wrapping that functionality in a Meta toolkit that simplifies just those parts, and you'll find a market. Start adding the ability to build web APIs on the back end with Meta, and you'll really attract attention. Everything that you want to do beyond that will only set Meta apart even more from other solutions.

posted by: Nick 14-Nov-2022/15:53:13-8:00

Oops, that was supposed to say: Firebase/firestore + some web UI

posted by: Nick 14-Nov-2022/15:54:47-8:00

I'm writing because I'm sure we have a different opinion about what's important in 'software development'. I have to imagine you're thinking much more about low level system development. I'm thinking about all the CRUD work that solves daily data management problems for businesses. Productivity enhancing data management tools that improve some piece of operations in scheduling, communications, point of sale, customer engagement, inventory, accounting, billing, payroll, quality assurance, project management, property management, etc. You know those sorts of solutions don't require complex computing tools, mostly just CRUD operations. I'm having a blast doing it in Anvil because there's no part of building any piece of those sort of software solutions that can't be easily accomplished with Python, JS, a good UI, and a database. Having things like Google and Stripe integration, authentication and user management, PDF generation, camera integration, and anything that can be accomplished with any Python library, all built-in, makes every request I get a total breeze. But those extra things can all be easily accomplished with third party web APIs too - including the database storage part. You can send SMS, do videoconferencing, etc., just by plugging in a few lines of JS and/or setting up a web API. From my point of view, that's where most work in software development that I see still is - and the need for that sort of work is growing even stronger, from my vantage point. There are so many other interesting things happening - in the Python world it's all centered around machine learning, AI, and all the other 'data science' tooling, and it's great to have those tools available to integrate easily, but that's more the domain of 'data scientists'. 'Developers' are still paying for their houses and their children's college experiences by building plain old in-house CRUD data management apps. When I write about this things, I'm speaking from that point of view, with that sort of work surrounding me.

posted by: Nick 14-Nov-2022/18:49:11-8:00

Ah, so we agree that Flutter and other heavy-but-popular stuff are just nice-to-have-if-we-get-to-them. The fundamental strategy is to make the lightest interfaces to the most fundamental-and-unavoidable platforms. To build on C and web browsers is already a big compromise for the sake of popularity compared to REBOL/View.

The whole Meta project is already built that way. The console and the chat forum are web apps that communicate with Meta services on servers. Where Meta is not capable enough yet, the browser side is done in simple HTML and JavaScript, and the server side is done in REBOL. Meta is being developed to eat that up over time to do full Meta systems.

posted by: Kaj 14-Nov-2022/19:06:37-8:00

Add a little 'dialect' for web page UI generation (something like VID that just generates simple HTML forms at first). Add some basic layout features to make interfaces responsive - basically using a simple flexgrid-like layout to move from horizontal to vertical alignment on smaller screens, and moving sidebar menu drawers into 'hamburger' menu icons.

Integrate that with another little dialect to persist data on the back end (something like a Python 'database ORM' that could be eventually migrated to different database systems).

Add a mechanism for connecting to HTTP endpoint functions, transferring data structures with json (and converting back and forth to Meta language structures (series)) - or even skip that part and just enable developers to work with json everywhere, because most users these days are familiar with json, and all web APIs work with it by default.

That's a full stack that I'd want to start working with. I think others would want to too, if the stack was light weight, with a beautifully *simple* set of UI and database dialects. Package the whole thing in a docker container, and you'd have developers everywhere giving it a try.

Eventually add a mechanism for publishing functions via HTTP endpoints, to really make it fit into the architecture that other developers are used to using.

posted by: Nick 14-Nov-2022/21:44:45-8:00

If you expose any of the features available in Rebol/View, you'd have a really appealing feature set built into the system. Things like draw dialect, image manipulation, audio generation, are all appealing, if they just have a web front end, and a web API.

Also, just wrapping modern browser APIs, such as video recording is so easy to do, and adds dramatically to the appeal of the system. Add camera, audio recording, third party libraries for 3D, etc. and just wrap the API in a simpler dialect, and the whole system becomes much more useful, and appears much more powerful.

Have you seen https://nicegui.io/ ? They built that whole system by wrapping everything in justpy, which wrapped everything in and old version of Quasar UI on the front end (which is build on Vue, etc...), and also included an old version of ag-grid, plus an interface to three.js to display 3D scenes, as well as Highcharts and Matplotlib. Pretty awesome little system.

And Streamlit got bought out for $800 million this year, mostly becaus they wrapped a bunch of Python visualization libraries, and integrated the front and backend so that data scientists could create front end layouts with backend Python code in simple little scripts, wrapping HTML/CSS/JS in the simplest possible API, and hiding how data is transferred back and forth between server and front end (nicegui works in much the same way).

posted by: Nick 14-Nov-2022/22:03:57-8:00

But Streamlit is purpose-built to deliver machine learning, visualizations (dashboards), and other Python data science-y projects to the web. It's not focused on CRUD development, and even with a simple pip install setup, it still much heavier and slow moving in terms of how responsive it could be for normal CRUD development.

Anvil is massive. The hosted version is great, but for building strictly in-house CRUD apps, it's a huge thing to install (and only the server is open source, so you don't get the UI designer, IDE, and other the things that make the hosted version so productive to develop with).

Flutter is installed locally, but it requires Windows 10, and it's several gigabytes. And that's just a front-end tool. It needs Firebase, or some API driven back end, etc.

I'm extremely happy with my current tools, but I'd LOVE to have a light weight, quickly installable, super productive dialect driven tool setup that had no huge external dependencies (basically a web front end to Rebol, with a database, json, and APIs). Getting away from Rebol is of course essential to make the front end part more capable, but that can be accomplished a first by wrapping HTML/CSS/JS in Meta dialects.

posted by: Nick 14-Nov-2022/22:18:14-8:00

What would have solved everything for me would been porting VID, along with the Rebol language to the browser, and creating a standardized method to send Rebol data structures back and forth with a server. The language part was ported with WASM, but the most important part, the GUI, was never approached. Having Rebol/view, VID, draw dialect, sound, etc. ported to WASM would have been absolutely killer - can you imagine? There was a time I would have spent 10s of thousands of dollars to get that done, but no one cared or even seemed to understand why that would have been valuable.

I'm fully past that, but I'd still love to see the simple Meta CRUD system I've described. I think that would be useful to so many developers, becuase little in-house CRUD apps are still a huge market.

posted by: Nick 14-Nov-2022/22:25:07-8:00

All the Meta web sites and web apps, and the new Syllable front page, are written in a dialect. It's a thin dialect that allows all features of HTML/CSS/JavaScript, while still helping with their creation. A REBOL/View like dialect can be built on top later. Remember, the strategy is to first access all platform features, and then build easier dialects on top.

This dialect is currently in REBOL 3. One of the goals I'm developing towards is to port it to Meta. In fact, it's a complete XML/HTML codec.

When you have Meta on both client and server, there is no need for JSON; it would be inefficient. However, I long ago published the first JSON codec for Red, so another goal is to port that to Meta for communicating with other systems.

Similarly, as we know, simple database apps in REBOL don't need databases. But I also published an SQLite binding for Red. I have ideas for making a better one in Meta. Again, later, an abstracted dialect could be made for multiple database systems.

Your vision is mine. The REBOL design has a great capacity for abstraction to make things easier. I was always frustrated that it wasn't used to make existing systems easier, mostly only for its own internal purposes. I tried to open up Red to the outside world, but experienced friction.

Meta is designed and built as an integration engine, the spider in the web. It looks like REBOL, but is built out of existing parts. The language is just a dialect that binds it all together.

Using existing parts is the fastest way to construct this vision. Still, it's a huge amount of work, and lower-level parts need to be integrated before we get to higher-level parts. Even if we see where we are going, it is still some way to go.

posted by: Kaj 15-Nov-2022/6:24:11-8:00

I like your input to hear what business programmers are using these days. Not everything is suitable for Meta, though. Some things are examples, but competitors. Some things can be integrated, but can be expected to be too much work too support. Some things can be integrated, but are much heavier than other options. It's not good to do heavy parts first, because Meta would send its users into an inefficient direction. It's best to offer the most efficient options first.

Meta is currently built on C, and eventually we'll have a situation like with C. Many projects can have Meta bindings, but they wouldn't necessarily be part of the Meta project. What's coming from the official project will be a selection more like REBOL, an integration of efficient choices.

posted by: Kaj 15-Nov-2022/6:41:55-8:00

By the way, I made the Meta sites and web apps fully responsive, making use of flexbox layouts. We work on Meta on all types of devices during the day.

This is also the reason that browser support only goes back one decade, not two. These responsive features weren't available then. (Back then, responsive meant responding fast to user actions, in Amiga OS, BeOS and Syllable. This term has been hijacked by the web community. Browsers are not responsive at all, even as I just type this in a standard text box on a phone. I call it adaptive instead.)

These adaptive features are not formalised in the low-level web dialect, it's just CSS. They could be formalised in a higher-level View dialect.

posted by: Kaj 15-Nov-2022/8:16:11-8:00

NiceGUI is almost the first framework I see that writes its own website in itself, so it's the first one that is not out on the first strike. :-)

These frameworks justify themselves in terms of the other frameworks not being adequate for their purposes, confirming my apprehensions about them. We know there has been technology to do better for a quarter century, but it hasn't been applied.

A decade before NiceGUI, I did a live coding demo in GTK+ for Red:
github.com/kealist/RS-fossil-mirror/blob/master/GTK/examples/GTK-live-coding.red

posted by: Kaj 15-Nov-2022/9:27:53-8:00

Check out how they're using nicegui to control robots: https://rosys.io/examples/steering/

Right now, Streamlit is more powerful and more productive (consistently gets more done in ever fewer lines of code) than NiceGUI, and its capabilities, community-built components, etc. are growing by leaps and bounds, but Streamlit isn' made for building web 'sites' - it's really aimed at the ML community (data scientists), and especially for visualizing data results with charts and graphs, so not at all surprizing their web site isn't built with Streamlit.

I did use Anvil to built the site where I'm advertising my (primarily) Anvil development services:

http://www.com-pute.com

BTW, it would have been far more productive, more pleasant, and there would have been more options available, if I had built the Anvil tutorial in Anvil, instead of with Makedoc. But I was new with Anvil at the time, and it felt strange to use the default Anvil layout styling to display screenshots of the default Anvil layout styling... Then, when I wrote the Streamlit tutorial, I just cut down on the source file of the Anvil tutorial, so it was quicker just to use Makedoc again. For most documentation now, I use Markdown in Anvil (and any other Anvil widgets/tools needed to make nice page layouts, live features, etc.)

posted by: Nick 15-Nov-2022/10:31:26-8:00

Rosys looks more like a Logo Turtle to me. :-)

posted by: Kaj 15-Nov-2022/13:39:54-8:00

I think Nicegui is a partial corollary to what you're trying to do. They literally wrapped the entire Justpy.io project, which itself integrated Starlette and Uvicorn on the backend for the server, and Quasar, ag-grid, and other powerful third party frameworks on the front end (plus integrated highcharts, Matplotlib, markdown and other libraries), to create a truly full stack system that's entirely codable in Python (all but a database - just drop in SQL alchemy or any pure SQL library available in the Python landscape). The makers of Nicegui said Justpy was 'too low-level HTML' for their daily usage, so they wrapped that entire system in a higher level Python 'dialect'.

posted by: Nick 15-Nov-2022/16:48:29-8:00

There is a LOT going on under the hood in NiceGUI - Justpy is pretty deep, with a lot of integration on it's own - still offering only a *miniscule fraction* of what Anvil does to ease developer pain, and to improve productivity, but Nicegui is definitely a neat project that uses what I think of as something reminiscent of the Rebol feeling of dialect creation to provide a simplified language interface to the features provided by another very comprehensive project.

posted by: Nick 15-Nov-2022/16:58:17-8:00

Quasar is a real gem, and strikingly complete as a UI framework. They push using their CLI, and the on building mobile, web and desktop apps (w/ Cordoba or Capacitor, and Electron), but you can just import the library (~15k) and use all the 100+ AAA quality widgets. Justpy is stuck on version 1 of Quasar. I haven't done any work with Quasar yet - focusing on Flutter - but it's really worth looking at...

posted by: Nick 15-Nov-2022/21:19:04-8:00

Thanks. It looks a lot heavier than MDC Web, though.

posted by: Kaj 16-Nov-2022/3:52:17-8:00

I haven't looked into MDC Web. I saw these big notices:

Web support is planned
The Material Web team is making significant changes to the codebase in preparation for adding Material Design 3 support. Follow the material-web repository on Github for updates.

IMPORTANT: Material Web is a work in progress and subject to major changes until 1.0 release.

posted by: Nick 16-Nov-2022/10:38:45-8:00

Yep, just the right time to support the new version. :-)

Many projects that Meta uses have only become feasible in the past few years. They mature while Meta develops. It's why I couldn't really have done Meta this way a decade ago.

posted by: Kaj 16-Nov-2022/11:21:26-8:00

Stay ahead of the curve!

posted by: Nick 17-Nov-2022/16:22:56-8:00

I mentioned jslinb above, and it brought back a feeling of reminiscence, so I cracked it out again yesterday and set up a front end for a set of Anvil HTTP endpoint functions. I made 2 versions - 1 using the aging built-in 'linb.ajax' API, and another version using fetch. The really cool thing about jslinb (as long as you only use the built in API functions) is that you get a totally free, open source visual UI builder which you can install just about anywhere:

https://guitarz.org/jslinb/Samples/index.html
https://guitarz.org/jslinb/VisualJS/UIBuilder.html

and apps that run on virtually every mainstream browser ever made (very very old versions of IE, Firefox version 1, the browser that came with the first iPhone, the first versions of Android, QtWeb, etc.). I feel like a total nerd spending Friday evening connecting this crusty thing to an Anvil backend ... but who knows, maybe some day some client will be in desperate need of a birthday reminder system that runs in IE 6 :P

linb.ajax version:

http://musiclessonz.com/jslinbcrudgrid/indexajax.html

fetch version:

http://musiclessonz.com/jslinbcrudgrid/

Next Friday maybe I'll make an NS Basic version ;)

posted by: Nick 19-Nov-2022/19:12:01-8:00

Honestly, it sends a chill down my spine to think about how difficult even little demos like this were to create in the past. Now, creating such more capable apps, with with multi-user access, authentication, reliable and consistently accessible interfaces across common mobile and desktop platforms, etc., takes 5 minutes, and connectivity with so many more fundamentally useful capabilities just sitting there for the taking. It's neat to play with old tools for the mental gymnastics, but jeez, this work has gotten to be so easy :)

...cue old man saying, 'I remember the old days when we had to walk 3 miles in the snow, uphill both directions'... :P

posted by: Nick 19-Nov-2022/19:52:39-8:00

I woke up snowed in this morning. :-D

I'm a different kind of old man, because since 1994 I could easily do all those things, with Lotus Notes. Since that time I have been appalled how long it takes for the world to first reject and then poorly reimplement superior technology. It's why I usually ignore all "new" products.

The only newer development platform that warranted attention was REBOL, because it was the only one that solved fundamental problems that I encountered in Notes.

REBOL is fundamental technology, Notes had more of a framework built in. So here I am, still looking to reconcile those things, improving the fundamental tech and aiming to build new frameworks on top.

posted by: Kaj 20-Nov-2022/6:35:31-8:00

Plato inspired the invention of Lotus Notes, Notes inspired the invention of web browsers, and it escalated from there, because nobody wanted someone else to own the technology.

REBOL tried to do another silo product, but it was too late for that.

Like REBOL, Meta will have the most benefits when it is used for all parts of a system, for example on both native client and server. But it will also be encouraged to use it for isolated parts, integrating with existing systems and filling the cracks they leave open.

A big part of why all those old systems fell by the wayside, Notes, REBOL/View, the old web frameworks you show, and even Red/View, is that those GUI's are based on fixed coordinates, usually on large screens. Smart phones and tablets made that inadequate. The way I make my new web apps could run on the oldest browsers, except that there is not much point anymore in not making them responsive, which puts browser support at around the last decade.

posted by: Kaj 20-Nov-2022/7:15:11-8:00

The need to be responsive makes the concept of drag-and-drop UI builders problematic. They exist because HTML/CSS/JS is hard, but I think a proper Meta dialect would still be a useful middle ground.

posted by: Kaj 20-Nov-2022/7:28-8:00

Responsive layout with a GUI builder is another pain point that just evaporated with Anvil ;) I've been happy with how layouts look on mobile by default, and the layout process is so much faster than with fixed coordinates.

posted by: Nick 20-Nov-2022/7:51:48-8:00

That's interesting.

posted by: Kaj 20-Nov-2022/13:05:01-8:00

Even without responsive layout, jslinb has some really nice ways to use screen real estate:

http://musiclessonz.com/jslinbcrudgrid/linblayout8.html

Check out all the accordion sliders on tab 1 of PAGE 2. That's a lot of real estate that takes up very little space on mobile, and still works functionally on bigger screens. Pop-up dialogs, like in the third tab also privide a great way of maximizing the effectiveness of every pixel. I love that jslinb can run on virtually every device that could ever run a mainstream browser, and that I can connect to all my modern backends :) I'm posting this using an old version of QtWeb - a great little browser that runs as a single uncompressed file of about 7.5 megs, with support for every OS from Windows Vista/2000 forward, MacOS 10.3, Linux, Unix, etc.)

posted by: Nick 21-Nov-2022/15:23:28-8:00

Definitely ancient looking, but it's got grid grids, and everything needed for all sorts of common CRUD work. I'm starting a project to show all my favorite front ends connecting interchangably to all my favorite back ends - so they're all dealing with the same database tables, API layers, etc.

posted by: Nick 21-Nov-2022/15:26:11-8:00

If you'd like to experiment with hooking up and testing Meta with any of those pieces at any point, just let me know. That could be a fun way to focus on building and testing some useful core functionality. Setting up a Rebol server in a Docker container on AWS, Google cloud, or Digital Ocean would be a good way to get it started. I've got plenty of working code to get that up and running...

posted by: Nick 21-Nov-2022/15:30:08-8:00

And of course, there are already CGI examples up and running that could be used right away...

posted by: Nick 21-Nov-2022/15:31:29-8:00

Yes, the Meta Pig Latin CGI service is still running:
https://do.metaproject.frl/examples/PigLatin?x=This%20is%20rad

To work as a client, I need to make network bindings. The scaffolding is already there.

posted by: Kaj 21-Nov-2022/21:13:52-8:00

To be clear, the only reason that I'm messing with JS linb, is because it's got the best cross browser support, across the entire history of every web browser that I've ever seen, so it's just a little insurance policy to ensure that I can hack together a managably useful front end for existing CRUD systems, in the case I ever run into edge situations in which a client needs access on some very old hardware system with a no longer supported browser It's also one of those free tools in which the workflow* is productive, and it can be hosted and accessed from basically any common device - and given the limitations of the ancient environments it can work in, it's pretty darn powerful and reasonably professional looking. Simple tool chains that let me accomplish lots of productive work, on any device, no matter where I am, have value to me. JS linb's little visual layout system, and all the widgets it has, form a really nice package that I can run anywhere, without having to install any software - it shares that useful characteristic with Anvil - the entirely self-contained IDE, where all the visual layout and all the coding happens in a browser - I can install the entire package on any web server, or even on a phone that's completely disconnected from the internet, and it outputs a nice clean zip file which contains all the resources needed to deliver and host the project, plus I can save an entire project to a single text file, which can easily be sent by email, uploaded, transferred instantly between machines, etc. And since I can connect it to any web API, running in any language on any server, using any database back end, etc, there's still plenty of potential use for it (my only interest and it is really to support old platforms, but it's one more little tool that who knows, may get used in other ways). Just tonight, one of my friends told me that the whole business he's employed by still realies on a core part of the system that needs Windows 95, and they can't seem to escape that requirement (for some political and or technical reasons), and that's a really huge business- I was actually thoroughly awestruck to hear that's the case there, but it certainly made me realize it's not a bad idea to be able to still support very old systems.

posted by: Nick 21-Nov-2022/22:21:27-8:00

Meta should run on Windows 95 once I release 32-bit programs, like the Windows-native Pig Latin CGI I compiled for you. (And I want to support ReactOS.)

Meta must eat away at existing systems from the bottom, so we shouldn't wait until there's a complete development environment, we must look for small parts of existing systems to replace where Meta can already add value. The two strengths it already has are platform support and efficiency, including speed.

posted by: Kaj 22-Nov-2022/4:21:48-8:00

So, why not extend what you've done with Metapig to accept requests to create, read, update, and delete values in rows of a data store of some sort? Then we could connect any front end to that and do typically CRUD work it. Most front ends will send those structure as json - I even have the rebol code needed to decipher the examples in the tutorial at http://re-bol.com/jslinb/ . Why not start with some of those examples? They accept parameters sent the same way the metapig app did. If we could get create, read, update, and delete functions happening, then there's already the most critical part of a working system based on Meta, that others could begin to use.

Can you save data structures to a file, or can you use a C library to work with Sqlite on the server? Really just storing series structures in a flat flat file is enough to get it working...

posted by: Nick 22-Nov-2022/14:48:25-8:00

I have 20 different ways to accept requests on the back end, so this isn't critical for any work, but I'd love to see Meta grow. What I see as the value that Meta adds is that it's light weight. It could potentially be installed in places where modern python and Fastapi, for example, would be more difficult to install. I can do that right now with Rebol core and CGI scripts on any cheap shared host, but Rebol is closed source, and at some point it won't be supported, and that entire historical option will disappear. I'm sure there's a market for that sort of back end, even if it's just able to handle simple CRUD interactions with a flat file to start out.

To begin, use any JS front end library to create user interfaces that send some data. I'm happy to help build some front end examples that connect with whatever pieces you'd like to test. Maybe just recreate some of the functionality of the Rebol code in the examples at http://re-bol.com/jslinb/ , since there are already Rebol code examples there that might provide an easier starting point, and which work with some paired existing front end code.

I can see people being interested in such a system that requires only a single tiny binary without heavy dependencies, and which connects with a front end that can run in any browser anywhere.

posted by: Nick 22-Nov-2022/15:03:42-8:00

Present it as a demo with a bunch of great little layouts all doing using little CRUD operations and tell them that the entire system can run on an 8 bit Atari, and whatever other ridiculously bare minimum OS requirements you can port it to. Make it run on as many platforms as possible, including phones, and you'll turn heads.

The development world going the other way, supporting firestore, netlify, snowflake, AWS, Google Cloud, Azure (and even things like Anvil), etc. in big ways, and I'm sure there's a huge crowd of experienced guys who are horrified with that progression, and would love to support a smaller system that doesn't require such big infrastructure.

If you can make start towards making the "lightest weight web API framework" that all the new JAMstack developers can connect to, you've got a market.

posted by: Nick 22-Nov-2022/15:12:12-8:00

Is there a C library you can use to encode and decode json data structures that you can then save to any existing database, or any storage mechanism? You don't need to accept json, just a string of URL encoded parameters, but being able to just decode a json body would make the system able to connect with just about any front end (funny, the built in ajax functions in jslinb or the opposite).

posted by: Nick 22-Nov-2022/15:36:03-8:00

There must be a number of JSON codec libraries in C, but I wouldn't bother with them. I would port my JSON codec in Red to Meta. The only thing is that not all needed data types are implemented yet.

SQLite is a C library, so I would port my Red bindings to Meta. In that case, Meta would directly use SQLite data types.

A CGI CRUD interface certainly wouldn't be hard. The question is what interface is needed. I have several CGI interfaces for the project. In general, an app is best served with a custom interface design between client and server. I never use a generic CRUD interface to a database. Meta CGI interfaces are easy enough. I would look what an app client needs. For the chat forum, I use text files in blockchain-like structures.

It is better to do a generic JSON codec and SQLite binding and some general CGI examples. There are thousands of examples I could do. I can't afford to work randomly on them.

I looked into the Windows 95 target. It doesn't seem to be covered by my current plans, but it can be done. Again, hundreds of possible target platforms. I can't afford to do them randomly.

posted by: Kaj 22-Nov-2022/17:48:32-8:00

https://musiclessonz.com/jslinbcrudgrid/ uses the modern fetch browser API to send a json payload to one of 4 HTTP endpoints ('web API functions') . At the server, each particular HTTP endpoint function performs an individual create, read, update, or delete operation with the json data, in the database. Most current web front ends will connect using those mechanisms

http://musiclessonz.com/jslinbcrudgrid/indexajax.html uses methods from the linb.ajax library, which are just wrappers for the old XMLHttpRequest ('xhr') browser API. Those pieces of data are transferred to the server as URL encoded parameters (http://site.com?name=john&time=1200am).

You could interface with the second example above by just extending what you did with the metapig CGI interface. The idea at first is just to create 3 functions
at three different CGI endpoints that can create, update, and delete values from some row based data structure that you choose, using the incoming data values send to each of those scripts:

http://site.com/create.cgi?name=john&time=1200am

http://site.com/update.cgi?id=12
(or maybe http://site.com/update.cgi?name=john&time=1200am&newname=johnny&time=100pm)

http://site.com/delete.cgi?id=12
(or maybe http://site.com/delete.cgi?name=john&time=1200am)

and 1 endpoint that reads:

http://site.com/read.cgi?id=12
(or maybe http://site.com/read.cgi?id=all)


Dropping the '.cgi' and the '?' would look more like people expect now:

http://site.com/read/12

But you can certainly just start with accepting data sent via the older xhr API and accepted at CGI script URLs with '?id=value' pairs, just like with metapig.

If you want to decide how to store values in any structured way that you're comfortable with, at least to to start out, that method doesn't matter so much, as long as you can create, read, update, and delete values in each row/record. then just create 4 endpoint functions (scripts) to do each of the 4 CRUD functions.

If you'd like to try doing that for the http://musiclessonz.com/jslinbcrudgrid/indexajax.html example, you'd be well on the road to having useful backend system, and already one that developers could use the open source jslinb IDE to quickly make front ends for your system. That would be a pretty darn useful way to get people's attention. If you'd like to do that, I could write some examples and documentations to show others how to use it.

posted by: Nick 22-Nov-2022/18:29:43-8:00

jslinb is very old, but it's free, open source, and using it should be immediately familiar to anyone who's used any IDE that descended from the Microsoft VB style visual development environments (or any of the thousands of variations of those sorts of environments).

It'll also connect easily with the simplest possible CGI interface that you've already got working.

Your biggest decision is what sort of data storage mechanism you want to start out with, but you can change that out transparently later on. For the proof of concept, and getting a 'REST' API set up, the front end doesn't care how that's accomplished.

posted by: Nick 22-Nov-2022/18:35:25-8:00

Hopefully, that's a concrete suggestion that would provide an actually useful set of tooling, which shouldn't be a monumental set of tasks to achieve, and which I can help test, and write examples + documentation, if it's an interesting goal for you. I can imagine other potential users finding that bit of infrastructure actually useful.

There's no pressure from me, I'd probably be years away from wanting to try using it in production, but it's definitely the sort of tooling that I could imagine being able to eventually put to productive use.

posted by: Nick 22-Nov-2022/18:40:44-8:00

The smallest examples in your tutorial can be done now, but for the larger ones Meta needs more array support and file operations first.

A JSON codec and file serialisation or an SQLite binding are substantial work. I can't prioritise that now over other work.

posted by: Kaj 22-Nov-2022/18:41:37-8:00

I could do something excruciatingly simple, if you say this would be useful.

posted by: Kaj 22-Nov-2022/18:54-8:00

The idea would be to first just to create a dedicated endpoint API for a single little app - maybe a contact management app, or even a just todo list, shopping list, etc. - and then make the API more generic and add features for searching, sorting, creating new database and schema, etc. Sqlite would work well for this since it's file based, and has every possible feature already built in, just needs to be wrapped.

Give results back to the front end in json format, be able to accept incoming json body structures, and you've got a really usable generic system.

posted by: Nick 22-Nov-2022/18:56:14-8:00

I thought so, you want me to write a database system. :-)

That's not what I need to do now. I always had ideas in this direction, but it will be REALLY simple.

posted by: Kaj 22-Nov-2022/19:03:43-8:00

I'm just trying to suggest some direction that I can potentially offer some help with (examples, docs, testing, front end to your back end, etc.) - and just in ways that make sense in my world. I'm not asking you do anything, just wondering where we might find some common ground.

I suggested using sqlite. That seemed to me like a potentially good fit for your background in C. There needs to be some sort of storage mechanism for any sort of CRUD system, of course, but like I said, how that gets implemented doesn't matter to the front end - or to me :)

No pressure, I'm just hoping you can find more community to support your efforts, and offering my two cents about what might attract a community. ...ok, maybe I've offered my 792 cents, but I'm just hoping that you can get to the point where people are asking to help you build this cool new thing...

posted by: Nick 22-Nov-2022/20:50:44-8:00

What I'm focusing on is the idea of a REST API - that's where I think you'll find common ground with a larger community, and the beginnings of a system that might attract users. If you want to focus on system development, games, etc., then clearly, that's not a direction to go - but you're already building web apps with Meta, so building an HTTP endpoint API system seems like an obvious move - one that will be familiar and useful to a massive crowd of potential users, and a building block that may be easier to complete than other potential goals. 793 cents :)

posted by: Nick 22-Nov-2022/20:56:53-8:00

I'm warming up to the idea, but I always have to sleep on such a thing. It's a sign that we have indeed reached common ground for a concrete step, so thank you for that! :-)

I don't want to do a big project that I won't use myself and that others will regard as a toy.

I have a hard time believing that many people would want to build client/server apps on a generic database API, but thinking back how we got into this mess, that is exactly what happened. Decades ago, file systems weren't good enough for databases, so database systems evolved. First COBOL-style database files, that I had to program. They had trouble supporting concurrent access, so a lot of complexity had to be added, that often remained unreliable, especially over network file systems. Then database servers were added on top to regulate the access. Then they could be extended to network and Internet access. People were so happy to have something that worked some of the time, that everybody started programming to the network API's of these database servers. System admins, network admins and database admins were hired to keep it going.

The next step was adding application servers in front of the database servers, and hiring application admins, because shoehorning an app into a standard database API led to more problems. But when you can't afford that step, I suppose standard database API's are still used. So they became fat by adding functionality of application servers, but not custom for your app.

Meanwhile, computers and networks became thousands of times more powerful, but small apps using relatively small databases all use these humongous systems. They say most Oracle customers pay them big money to effectively load their data into cache memory.

By now, almost nobody can imagine anymore that we could do without all this expensive complexity. Yet that is what I have to do. Meta will have to follow the above path to modern architectures, but simplifying everything along the way, starting with a Minimum Viable Product.

Actually, I already have this, because I mulled this over for decades. For example, the user database in my new chat forum is built this way, similar to what you specify, but not bothering with a standard database API.

I will port that from REBOL to Meta and generalise it. Meta needs some extra functionaly for it, and I need to support Arnold, too, so it will take a while, but it's a nice, concrete direction to work in, that I need anyway.

The resulting code will be so simple, that people can use it either unchanged as a database system, or they can modify and extend it into custom application API's for their apps.

posted by: Kaj 23-Nov-2022/6:19:10-8:00

Central to the idea of modern web APIs is json. Python, JS, and all the languages and tools that take part in the modern web stack all use it natively. And that's why Mongo, Firestore, and other nosql database systems are popular - it allows users to model their whole database system using the same data structure that is used for all data transfer transactions. Mongo and Firestore are basically big searchable repositories of json documents. That works really well with the way everyone brought up on web APIs thinks.

If your hope is to be immediately relevant to a potential broad base of new users, being able to work with json data structures should be a core goal. Food for thought as you think about putting together pieces...

posted by: Nick 23-Nov-2022/8:57:22-8:00

JSON is needlessly complex. I certainly won't use it in the internal implementation, but I will support it as an option for an interface format.

posted by: Kaj 23-Nov-2022/11:57:32-8:00

Wearing clothes is needlessly complex. ... but you kinda have to do it if you want to hang out with other people.

posted by: Nick 23-Nov-2022/13:23:45-8:00

No one cares about the machinery of the backend, only about the API (and most web APIs now transfer data in json format natively).

posted by: Nick 23-Nov-2022/13:26:03-8:00

I read 'interface format' initially as 'UI interface format'. Did you mean that in the sense of data interchange/transfer format?

posted by: Nice 23-Nov-2022/13:31:18-8:00

I'd pick JSON over XML any time.

posted by: Arnold 23-Nov-2022/16:48:38-8:00

100 million other developers said the same thing, so here we are. Douglas Crockford said:

"JSON had a lot of influences on its design. It didn't just come out of my head. It's based on a lot of things that I had observed over the years ... Another influence was Rebol. Rebol's a more modern language ... in that it's all built upon a representation of data which is then executable as programs... it's a much richer thing syntactically. Rebol is a brilliant language, and it's a shame it's not more popular, because it deserves to be."

posted by: Nick 23-Nov-2022/18:26:40-8:00

There's always something even worse.

Depends on who you hang out with, Nick. ;-)

Yes, I meant transfer format. I wonder what you mean by native. A database that stores all data in JSON format would be very inefficient.

posted by: Kaj 23-Nov-2022/18:29:16-8:00

https://www.mongodb.com/json-and-bson#:~:text=the%20BSON%20specification.-,Does%20MongoDB%20use%20BSON%20or%20JSON%3F,just%20as%20easily%20in%20JSON.

posted by: Nick 23-Nov-2022/20:28:21-8:00

I meant 'natively' in the sense that jason is currently like a sort of 'native tongue' of common data structures. Everyone expects to be able to work with json by default, for built in tools to take care of parsing, manipulating and transfering json data structures without little effort. Internally, in MongoDB, those structures are saved and transferred as bson (that's what the link above is all about).

posted by: Nick 23-Nov-2022/20:41:51-8:00

Right, they can call it BSON for marketing, but it has little to do with JSON. It's just their internal format. I'm using similar designs in my storage and transfer.

It's just a myth built around JSON. It doesn't solve everything.

posted by: Kaj 24-Nov-2022/4:17:52-8:00

For example, you don't "manipulate" JSON data structures. You parse them to some internal format, then manipulate them, then encode them into JSON again when the user wants them back.

If you can leave out the parsing or the encoding, or you can replace them with something simpler or more efficient than JSON, you have an improvement.

posted by: Kaj 24-Nov-2022/4:25:38-8:00

By parsing the data into an internal data format, manipulating, and re-encoding, you've manipulated the keys and values in a JSON data structure - that was my point - developers using json don't care how that occurs internally, they just expect to be able to use that data structure, send it somewhere, get a json data structure from an API service or a file, or returned from a database search, etc., and refer to values with keys to manipulate those values, etc. No one wants to get anywhere near the guts of how that happens internally, they just want to be able to access, manipulate, and transfer that data, using that familiar and universally supported structure (universally among the hundreds of millions of developers who are familiar with it in the environments they work).

posted by: Nick 24-Nov-2022/8:18:55-8:00

Ah, but I do care how it works internally, because you want me to program it. :-)

And the way it's implemented can make several orders of magnitude difference, which shines through to the users in the external properties of the product.

If they want to talk JSON, fine, but it will cost some performnce, and a JSON codec is relatively large for, say, an Internet of Things sensor, so your sensors will need more expensive hardware and more energy.

posted by: Kaj 24-Nov-2022/8:38:32-8:00

We could semantically and technically about what's actually happening when you 'manipulate' a string, but bringing developers back to the level at which they need to think about what's happening internally with bits and bits being processed by a CPU is not the way to improve productivity and move on to higher and higher levels of composability. That's the job of the language and the tooling. At this point, even the idea of a database system (and the use of SQL, for example), and everything that occurs in all the layers of the network model, as well as every part of the the rendering systems upon which user interfaces are built - all those things are abstracted away for developers. We use ORMs to create, read, update, and delete data in databases, without having to think about the differences between the versions of SQL used in each database, or how to serialize and de-serialized values properly. We use layers of UI tooling that hide all differences between subsystems on different OSes, so that one consistent tool can be used to build beautiful and complex front ends that look and act exactly how they're expected to on every OS, with grids that paginate automatically, and animations that run with a single function, for example, or 3D interfaces that are built at a level which is intuitively simple for even small children to create visually. We use machine learning libraries to 'teach' a system to recognize poison ivy images that appear in a video stream, running on a microcontroller that costs $6. We use web APIs which send and receive json values using a familiar HTTP endpoint syntax, and which hide everything about how that process in the machine's memory, the OSI model, etc.

Rebol had the right idea about how to simplify so much about all those sorts of processes, but the actual language, program structures, UI interface builder, and high level capabilities of development systems available now have far and away superceded anything that Rebol ever approaced achieving. Yes, internally they're more complex, but no one cares abou that. The care that they can build their 3D game, or their web site with a beautiful interactive layout, or their AI device that they can put on their bike to recognize poison ivy, with ease.

Anvil and other modern tools enable me to accomplish all those sorts of high level things very easily, and they just work. That's the way Rebol was in it's day 20 years ago, but it's absolutely nothing like what I can do now. It's 50x easier to actually work with Anvil and create useful software (and I spent thousands of hours working with Rebol).

But yes, the internals of all these systems are incredibly complex - the developer's user experience is fantastic, but the underlying machinery is outrageously complex, and most developers these days rely on third party services to enable facility in the development process, hosting, etc. Big systems are containerized and hosted on AWS, entire backends run on Firebase, entire systems like Anvil, including IDE, DB, etc. run in a browsers. Functionally, that is super convenient, but despite cloud providers like Google, Amazon, and other cloud providers likely being more reliable than any service I could create, I do NOT like HAVING to rely on any third party system to make my systems work. Even Python's pip install, which is absolutely awesome, or any libary management system which relies on CDNs to deliver pieces of a software system - despite being more reliable than anything I can create - still rubs me wrong, and I'm interested in how Rebol was able to do so much with such a great foundation that eliminated that need for so much complex infrastructure.

But what drew me to Rebol - my experience, in terms of facility and productivity as a developer - has been tremendously superseded by newer development systems, so I'm going to use those systems to get work done. But I'm still interested in seeing a system developed which cuts down on the complexity of all the internal machinery - all the third party hosted layers and dependencies.

Making a system that does that, and can at least fit in with what modern developers expect and need to get work done, starts with having a UI layer that runs across all mobile and desktop OSs with the least amount of installation trouble for users (web does that), having an HTTP endpoint API, using json data structures, and having a database (or some equivalently functional data persistence layer) on the server.

Any system that starts with that, can at least by useful and able to be integrated with the modern development environment.

I didn't make those rules, but they're a way to fit in and be relevant.

posted by: Nick 24-Nov-2022/9:04:35-8:00

At least, having a web UI, HTTP APi, server database system, and json support, seems like the most realistically achievable way to be useful, integrateable, and relevant in the current landscape.

posted by: Nick 24-Nov-2022/9:07:03-8:00

I'm not at all saying that I want to expose developers to bits and bytes of the implementation. I keep saying that I will support them talking JSON, as an option.

But to make this project viable, I need to think about the implementation. And it will have nothing to do with JSON internally.

posted by: Kaj 24-Nov-2022/10:06:56-8:00

Remember, Meta is about reducing waste, by reducing accidental complexity:
language.metaproject.frl#muda

There's no point in doing things just like others do, because you might as well use those existing products. And I wouldn't be able to duplicate them, anyway, because you would be eternally chasing tail lights. We've done that in the second half of REBOL's existence, and we don't want to do that anymore. We want to move ahead.

There's plenty of accidental complexity in the systems and layers you describe, so that is specifically what we want to do differently. We should not mistake complexity for sophistication.

posted by: Kaj 24-Nov-2022/10:24-8:00

Rebol died for me when it stopped being able to connect with other systems, and make use of technology that was evolving around it. Being able to use json and connect to functionality via web API, like the rest of the world does in so many other systems seems like a bare minimum for compatibility, and for developers to leverage the benefits of other existing systems.

posted by: NIck 24-Nov-2022/11:08-8:00

Of course, json wouldn't be used internally, we're clearly working with the same understanding that it's a format for data representation and exchange, at the user level.

posted by: Nick 24-Nov-2022/11:11:44-8:00

I need to be really clear, I'm not *asking you to make this system. I'm offering what perspective I can, from my point of view. I'm interested in what you hope to accomplish, I think your goal in creating a successor to Rebol is valuable. I'm happy to offer what support I can in the form of testing, building user apps, docs, etc.

But for my own needs, I am fully tooled up and not needing an alternative for my work. Anvil is just one of the tools I'm mired in. I can deploy apps made with it using the open source server, and I have multiple alternatives for every piece of any part of a product I build with Anvil. It's basically ideal at this point for most of the work I do. Streamlit, existing databases, and generic Python have already been productive for dealing with data scientists' requirements. jslinb is what I need to support UI on legacy devices, with a back end build with any platform. Godot is perfect for potentially game, graphics, VR, and other related needs. Flutter will likely become my preferred tool for building customer facing front ends that are distributed as mobile (+ web/desktop) apps (and I'll roll with quasar and whatever other similar frameworks become useful). Python, JS, Node, etc., will probably always be in the mix.

For my needs, I'm mired in those sorts of tools now, happily. Actually, those sorts of tools give me great satisfaction and joy at this point. And they give me the opportunity to do lots of the work that I love to do with other human beings, especially in their business environments.

My interest in Meta comes from my experience with Rebol. I've gotten past my expectations to ever be able to use Rebol in my productive life again, but its values and methodologies, and the whole perspective Carl enabled and instantiated/incarnated with Rebol is something that I held very close to my beliefs, and which actually was productive to me. I think building a system that eliminates complexity at its heart will be fundamentally useful in this world. I'd like to take part in supporting those values, and to help share that perspective, and the benefits that come from it, with others. I'd also like to see you become successful. I'm interested in what you're doing with Meta, because I have a lot of insight into how and why it can be valuable. But I need to make sure you're not working with an understanding that I'm waiting for you to build a tool for me to get work done. At least not at the moment. I'm just excited to see you approaching what I had desperately hoped the community would realize was important. I've had to move on to other tools to be productive, but I'd like to see you succeed. Please don't mistake my suggestions and 793 cents about what I think are necessary building blocks for developers in my position, as requests to begin a project.

posted by: Nick 24-Nov-2022/11:39:27-8:00

I think we are in agreement. It's just that we started the same path two decades ago, but halfway we took different turns. We hoped for too long that REBOL would do what it should be capable of, that was clear to us. You held on for a long time, but eventually started collecting alternatives. I started looking for ways to extend REBOL myself, joining several open-source projects, but eventually having to decide to start my own.

You used many alternative systems. I only reviewed them to see what was essential about them that REBOL should be able to do. JSON went on my list, so I wrote the first Red codec for it. But I don't care for all those systems that use JSON, that I analysed as non-essential, accidental complexity.

We're now looking at the same thing from different directions. It's why I was reluctant about the formulation of the project until I had thought it through. I have made a plan to make it fit in Meta's development. But that means that I'm serious about it. I will do it in a way that will make it hard for you to resist using it, otherwise there is no point.

posted by: Kaj 24-Nov-2022/13:31:11-8:00

I'm excited to see how you get started and what you come up with!

posted by: Nick 25-Nov-2022/8:58:15-8:00

Nick,

Check out https://flet.dev

It allows you to build Flutter apps in Python.

Seems like there is no need to load the Flutter framework.

posted by: Dani�l 3-Dec-2022/3:41:03-8:00

You need to installl a Flet client, which includes Flutter - somewhat comparable to REBOL/View - and a Flet server, and your own Flet app on the server.

posted by: Kaj 3-Dec-2022/6:56:06-8:00

I have looked at Flet. The thing that stuck me ws that it's a tiny and quick install compared to the Fluttter SDK. I wonder what they've done to make it so small. Have you built any production apps with Flet?

posted by: Nick 3-Dec-2022/10:37:25-8:00

A very cool thing I learned from flet is that fly.io 'provides a free remote Docker builder, so you don't need Docker installed on your machine'. I'm really eager to try that, maybe with nicegui, because needing to install docker really kills the lightweightness of many solutions.

posted by: Nick 3-Dec-2022/11:07:09-8:00

No. Not yet.

After a bit of investigation, it looks like Kaj was correct. 'appveyor.yml' lists Flutter SDK as an essential download (923 MB). I really hate downloading/installing something this big.

The rest is about 37 MB for a Windows installation.

Looks like a Python client driving a Flutter front-end via a Go server.

I was checking out "Wails" as another option.

But for now I really thinking hard about getting to know Nim - it has Fidget, a cross platform UI library for Nim.

I really wish Rebol had most of Nim's capabilities built in over the years.

posted by: Daniel 3-Dec-2022/11:45:22-8:00

BTW, for web development, Quasar CLI doesn't need any tooling whatsoever installed. With the UMD version, just import the CSS and JS files. These examples took a minute to copy and paste into a text editor, then upload to an old school shared hosting server:

https://com-pute.com/quasar/quasar-drawer-layout.html
https://com-pute.com/quasar/quasar-table-with-selections.html

Hook up the Quasar widgets to the MongoDB data API, for example, using Fetch or Axios, and you're most of way to building really useful modern web apps. And then when you want to package for mobile and desktop app stores, the Quasar CLI has you covered.

posted by: Nick 5-Dec-2022/16:50:15-8:00

With that said, 1 GB now costs literally a few cents, so 1 GB for a serious tool doesn't upset me. What upsets me is limitations.

My most recent micro SD cards cost $99, they store 1 TB, and transfer 1 GB in a few seconds, so for certain projects, I don't mind a heavy installation. For Flutter, that includes installing Visual Studio Code, with the Flutter and Dart plugins. They make editing *much more productive. A typical stack is Flutter + Firebase, Amplify, Mongo data API, or whatever other chosen BAAS is preferred.

The trade off for that heavy setup is the ability to accomplish just about any sort of imaginable work, with support in most mainstream development communities, the ability to work with potentially millions of other developers who have deep experience with that platform, and the fact that that big installation can produce the most cutting edge (useful and sellable) front ends for mobile, web, desktop and even future OSes (Fuchsia, for example). Those are real practical needs that are more important to satisfy in my life than saving 1 gig of HD space. There is no trade-off for capability...

posted by: Nick 5-Dec-2022/16:54:01-8:00

It's not about the storage cost. 1 GB has space for many millions of bugs and other vulnerabilities.
language.metaproject.frl#muda

posted by: Kaj 5-Dec-2022/19:36:38-8:00

For example, my official Google Chromebook regularly breaks my Microsoft Visual Studio Code on updates, so that I loose my development environment for some unknown period. Not exactly productive.

posted by: Kaj 5-Dec-2022/19:40:23-8:00

All I want is basic text editing and a 2022 setup doesn't even offer that.

posted by: Kaj 5-Dec-2022/19:47:18-8:00

I've never lost anything on Anvil. I just haven't had any pain with Anvil in any way at all, in any phase of development, deployment, working with others, etc. It's just been relentless pleasure and productivity :) We'll see how Flutter, Quasar, all these BAAS solutions work out...

posted by: Nick 5-Dec-2022/20:23:38-8:00

The main thing I don't like about all the heavy tools is that they require new machines with new operating systems. But I consider a solution like Flutter a solution for a particular set of problems - basically when best in class everything UI is required. So far, it's very exciting, but I'm still a baby with Flutter...

posted by: Nick 5-Dec-2022/20:26:12-8:00

Try Anvil on your Chromebook, even an old one. It works reliably and quickly - and you can jump between your Chromebook and another machine whenever you want. (You can also use jslinb on any machine the same way).

I tend to use notepad++ and CMD for anything on a local machine, but as a result of Anvil's fantastic IDE, I'm getting used to having autocomplete write 70ish percent of all my code. So I'm trying to get used to visual studio code, because the flutter plugins help in much the same way. So far, I'm not finding it buggy at all on any of my old Windows 10 netbooks...

posted by: Nick 5-Dec-2022/20:31:30-8:00

I was excited when I first saw vscode for the browser, but it's been a joke. None of the plugins work.

posted by: Nick 5-Dec-2022/20:36:30-8:00

I've been thoroughly amazed by the lack of trouble with Anvil throughout every phase of learning and use in productivity. It's been a complete answer to everything I've ever been looking for in a software development system for several decades. It feels so so right, like nothing else I've ever experienced. Everything just works the way it should, and it's infinitely expandable and connectable to every other tool. I haven't been disappointed or frustrated by it yet. Every new direction I go with it yields new fully working solutions within a few hours, and the process of getting things going has just felt enjoyable. Everything I jump into with it has been successful, and it's just been easy. Everything else I work with still feels like a painful mess.

posted by: Nick 5-Dec-2022/20:43-8:00

I'm exploring lots of alternatives for the database piece, only because hosted Anvil's database can get expensive. Right now I like MongoDB data API. That's one of the best things about Anvil, you can replace any piece of it with something else, either with web APIs, Python SDKs, Anvil's Uplink, and other tools that connect with it.

posted by: Nick 5-Dec-2022/20:47:39-8:00

What's clear is that having all the pieces of a system, whatever those pieces are, all integrated into one workflow - so that everything from code editor/IDE and UI designer, to code file management/hosting and revision history, to database and storage, to backend server logic, to API, etc. - everything is integrated with a consistent language and workflow interface. Integration of all the pieces is a huge part of what leads to enhanced productivity.

posted by: Nick 5-Dec-2022/22:11:45-8:00

I was happily usinf Geany, but wanted to know what the buzz was with VS Code. It has some nice touches, but nothing worth suffering unreliability over. As you say, the things that could make a difference, such as the Red plug-in, don't work. It's built on Electron, so it stands to reason that it can't be made reliable.

GTK+ is not well integrated on Chromebook, but if they break VS Code once more, I will go back to Geany and won't feel guilty for being old-fashioned.

I do strive for integrated environments, because I came from Lotus Notes, but with all other tools after it, it has been impossible to collect a good environment and keep it working. I hope to build it with Meta, but it will take time.

posted by: Kaj 6-Dec-2022/4:21:02-8:00

At least, I have Meta write 70ish percent of my code now. The C generated from a main program is typically around twice as large as the Meta source, and then it compiles in used parts of the runtime C functions.

posted by: Kaj 6-Dec-2022/4:24:34-8:00

A "syntax" highlighter for Meta in VS Code would be a nice addition. Looked at some tutorials but they use some Yeoman generator (for a plain-text file seriously?). And it is not clear which files to add to .vscode/extensions/ that do matter and how the coupling with the .meta extension would be made.
Everybody is making the same time consuming video tutorials nowadays so you can't even tell if they do or do not feature the content you really need at all.

posted by: Arnold 6-Dec-2022/5:21:32-8:00

That would be nice. It would probably be easiest to start from the Red plug-in server, but you would have to fix it. I saw someone say it works for them, but for me it always crashes at start, when opening a Red file.

posted by: Kaj 6-Dec-2022/7:55:37-8:00

One of the biggest things that keeps me away from big tools and systems like Flutter is the heavy hardware and OS installation requirements. I'm currently trying out https://flutlab.io/, since I can run it without any installation, on any machine with a modern browser. There are a bunch of other services like that, will build pipelines for iOS, Android, web, desktop, etc., without having to install anything. A good setup like that feels like it could be a very productive solution.

posted by: Nick 11-Dec-2022/12:34:27-8:00

I love the idea of owning and controlling every piece of tooling in my pipeline, so that there is no vendor lock-in, but when tools like that work, it makes sense to use them for the enormous majority of tasks. Just backup regularly and be able to switch to your own infrastructure if ever an online service stops working. That sort of routine feels pretty darn ideal to me.

posted by: Nick 11-Dec-2022/12:38:34-8:00

I also love that there are tools like Flutterflow, which enable super-productive work based on an open source tool, and which enable even non-technical people to get involved with creating actually useful software (especially pieces such as visual layouts) - without ever tying any project entirely to a single vendor or tool set.

posted by: Nick 11-Dec-2022/12:43:36-8:00

The problem with big tools is that even if they're open source, that's quite meaningless, because they're too big and complicated to take over their development, let alone their maintenance.

This is a big part of why noone took over Syllable, and I now have to resurrect it. There isn't even that much activity in continuing REBOL 3. Even though it was relentlessly focused on simplicity, it's still too much. Most parties who tried dropped it eventually.

posted by: Kaj 12-Dec-2022/14:26:54-8:00

Of course, I already started on the track of a web IDE that builds in the cloud:
console.metaproject.frl

posted by: Kaj 12-Dec-2022/15:05:21-8:00

I paid Cypher to port Rebol 3 to Android. It took him about a week to get a Rebol APK going, and a total of just a few weeks to complete Graphics, GUI, networking and everything else that I asked for working on Android. So I think for any system, it depends on the pool of people who are available to work on a project. With tens of millions of people using flutter, there are an enormous pool of people who are capable of adding and making changes to the system. On top of that, Google is supporting it! Just because the absolutely tiny crowd left in Rebol wasn't able to make Rebol move forward, doesn't mean that open source doesn't work, or that truly significant development doesn't happen in open source projects. It's a matter of support and demand. And demand for Flutter is astronomical. Most important for me with open source projects, is that they can be used freely. When a project or platform is past it's life, then there are new projects and platforms to replace them.

posted by: Nick 12-Dec-2022/15:32:23-8:00

That was much appreciated. Yet, not many people produce Android apps with REBOL 3. As you say, more is needed.

It's true that REBOL's implementation is outdated, but its design ideas are not.

It wouldn't be good to have to live in a world where only huge projects by huge corporations can exist. The Internet has enabled a long tail of just about anything. Smaller projects need to be nimbler in order to exist.

Being huge is no guarantee for survival, either, as the dinosaurs could attest to - if they were still alive and had evolved to develop speech. (Or perhaps one should ask a parrot.) I standardised on Lotus Notes because it was well designed and developed and supported by IBM - the best you could ask for. Yet, it's almost completely non-existent now; I can't use it anymore.

posted by: Kaj 12-Dec-2022/15:50:10-8:00

Yeah, but while the dinosaurs were here, I'd prefer to have beeen the biggest baddest dinosaur on the block :)

posted by: Nick 13-Dec-2022/21:31:04-8:00

AtheOS parrot was. :-)

posted by: Kaj 14-Dec-2022/3:32:45-8:00

We all know why R3 open source failed. It failed because there was no one there to ( A) explain a bit how it worked and B) ) accept changes into the original repository. It was open sourced and abandoned. I call this Open Source Carved into Stone variant.
And lastly R3 the major shortcomings of R3 (no GUI at no 1) were too big for many including myself to overcome.

I had not been aware that a port to Android has been made.

posted by: Arnold 15-Dec-2022/1:28:12-8:00

https://learnrebol.com/rebol3_book.html

That was for R3 Saphir, which runs on Android, with Cyphre's GUI (different than R2 VID, but mature). There are a bunch of examples on Rebol.org for it. I'll have to find a download link for the binaries and APK, because the Saphir link is now broken. It's been around for a decade :)

posted by: Nick 15-Dec-2022/6:12:04-8:00

For Android:

http://re-bol.com/r3-droid.apk
http://re-bol.com/r3-gui.r3

Windows:

http://re-bol.com/r3-view.exe

posted by: Nick 15-Dec-2022/6:22:21-8:00

For Android:

http://re-bol.com/r3-droid.apk
http://re-bol.com/r3-gui.r3

Windows:

http://re-bol.com/r3-view.exe

posted by: Nick 15-Dec-2022/6:22:24-8:00

There was even a attempt to port R2 VID to R3 View:

http://www.rebol.org/view-script.r?script=vid1r3.r3

posted by: Nick 15-Dec-2022/6:26:50-8:00

Ah I see. And also I notice that the script by Marco notes that you need to have SDK. When I came into the Rebol universe, Carl did not show up frequently so to say, and getting one seemed a risky business.

posted by: Arnold 15-Dec-2022/10:34:51-8:00

He gave that away at some point

posted by: Nick 16-Dec-2022/17:30:35-8:00

That was never advertised ;-)

posted by: Arnold 17-Dec-2022/14:41:42-8:00

Nick,

I haven't installed Anvil for offline use yet. I hope a local install results in a fully installed offline Postgresql server.

With Anvil, can I use Postgresql custom functions with it? I want to use the pgsql server as an application/logic layer.

Hope you can shed some light. I cannot find anything on the website.

posted by: Daniel 15-Jan-2023/10:22:56-8:00

Yes Anvil installs Postgresql. I haven't used Postgresql custom functions with Anvil.

posted by: Nick 15-Jan-2023/10:45:13-8:00

I'm curious what you need to Postgresl functions to accomplish.

posted by: Nick 15-Jan-2023/10:47:12-8:00

...and would love to hear what you're able to get done!

posted by: Nick 15-Jan-2023/10:48:32-8:00

Is there any reason that you can't use psycopg2 on the back end in Python to access Postgresql functions?

posted by: Nick 15-Jan-2023/10:53:29-8:00

psycopg2 2.7.1 is installed in the hosted version of Anvil (https://anvil.works/docs/server/packages), and you should be able to pip install anything you want in your self hosted Anvil environment.

posted by: Nick 15-Jan-2023/11:00:17-8:00

Theres's info about accessing the postgres db outside of Anvil at https://github.com/anvil-works/anvil-runtime. You can use psql-anvil-app-server together with psql and other command line and graphical tools, with direct access to the Anvil app tables schema.

posted by: Nick 15-Jan-2023/11:19:40-8:00

I am interested in pursuing it after seeing a blogpost on the versatility of Postgresql and I want to see how far I can push it. (Ref. this book:)
https://theartofpostgresql.com

Also this video:
https://youtu.be/Ztvst8IxtjE

I want to keep Python use to a minimum.
Also Postgresql offers of so much more, especially the security and concurrency aspects of it.

posted by: Daniel 15-Jan-2023/12:02:01-8:00

Anvil without Python? That seems like Rebol without series ;)

posted by: Nick 15-Jan-2023/17:55:40-8:00

Yeah Nick, :) but in Anvil it seems like the perfect and easiest place to see if this book can teach me some other ways to approach a problem.

The guy mentioned that an online playground would be the perfect place to practice the 300+ code examples found in the book, without the need to install Postgresql.

I know there is a lot of Python code on the internet. But it will be good to have more than one way to reach a solution. Postgresql gives you a lot of easier ways to do it.

But there are things you cannot do easily, like calling out to an external API in the middle of a sql query, and the call fails or takes to long to complete. Should you roll back on the data, or is there another way to have a successful outcome...

I have a Postgresql server installed with Anvil, might as well try it. Curiousity you know. ;)

How big is the total Anvil setup when installed?

posted by: Daniel 15-Jan-2023/22:49:57-8:00

Why not try bit.io?

posted by: Nick 17-Jan-2023/8:50:23-8:00

Bit.io is zero install postrgres and you get lots of free use

posted by: Nick 17-Jan-2023/8:51:32-8:00

They've also made it really easy to upload csv, sqlite, json, and other files.

posted by: Nick 17-Jan-2023/8:54:23-8:00

The biggest parts of Anvil app server appear to be Postgres and the Clojure web server that require JDK.

posted by: Nick 17-Jan-2023/9:07:49-8:00

BTW, I've used Firebase and MongoDB in Anvil apps also, and you can use any DB accessible via Python.
There's no tie-in to using Anvil's built-in DB - the built-in DB tooling just gives you a visual table editor, Python ORM, autocomplete in the IDE, all integrated in Anvil's single environment. The real thing that sells me on Anvil is having all the infrastructure and tools integrated and available in an environment that requires absolutely nothing but a browser. The workflow in Anvil is ridiculously productive - better than any no-code tool, but with such wide capability: Access to anything in the Python ecosystem on the server and access to anything in the JS ecosystem in the browser, all integrated with the visual tools for file and project management, GIT version (development and production) management, database, IDE with autocomplete, graphics/drawing canvase API, authentication, Google and MS services integrations (Maps, Docs, etc.), Stripe integration, email services integrations, the uplink (even with Micropython on Pico W boards!), and all in a beautiful workflow that runs entirely in a browser on any common modern OS. Rebol was 10x more productive than other tools in its day. Anvil is 10x more productive than Rebol ever was... and able to be connected to anything that's accessible via Python or JS. Whenever I hear someone disect one part of Anvil (like the database), I have to point out that the bigger picture is soooo much more than any single piece of the system.

posted by: Nick 17-Jan-2023/10:25:03-8:00

Also, the amount of Python understanding that's needed to use the majority of features in Anvil can be learned by any experienced developer in a day: mostly just some basic syntax, things like learning for loops and understanding how to use lists and dictionaries. Any other generic Python code, typically related to using the standard library and other libraries in the wild can generally be gotten with a Google search. I've found the Python ecosystem to be extremely pleasant - I rarely encounter troublesome gotchas or workarounds, everything tends to just work. It's nothing like the nightmare of JS and other language ecosystems (although just plugging in 3rd party libraries from a CDN and integrating them in Anvil tends to be super simple - as in a matter of minutes, even if you don't have background in JS and web development). Getting over the initial learning hump is a matter of days, for anyone with some development background, and then the ongoing productivity benefits increase really quickly.

posted by: Nick 17-Jan-2023/10:36-8:00

I'm sticking with Metro4ui as my HTML/CSS/JS framework of choice:

https://com-pute.com/metro4ui/index2.html
https://com-pute.com/nick/metro4uicrud.html
https://metroui.org.ua/intro.html

posted by: Nick 31-Jan-2023/16:43:05-8:00

I've been running all my Python backends using unmanaged VPS hosting, runway 4 at
https://www.a2hosting.com/vps-hosting

posted by: Nick 31-Jan-2023/16:45:15-8:00

Metro UI is phenomenal - I have to wonder how hard it would be to make a drag and drop builder for it with something like GrapesJS...

posted by: Nick 1-Feb-2023/8:48:58-8:00

I've also been playing with qooxdoo as another possible front end to support old browsers. I haven't used it anywhere in production, but like jslinb it supports really old browsers, and unlike jslinb it supports flexgrid and slightly more modern design. Jslinb is still my go-to if I need to support very old devices and browsers, because you can simply import the library and write code, or use the great visual layout builder.

Metro doesn't have any sort of drag and drop designer (yet), but it's so easy to use - basically like supercharged HTML with every common (and not so common) feature and styling option, that just works responsively on mobile and desktop - that I prefer just to lay things out in code.
It's the most productive, simple to use, and robust library for front end web design and that I've found yet.

posted by: Nick 1-Feb-2023/15:02:35-8:00

Just as important, Metro doesn't require any bundle/build system (web pack, parcel, etc.). Just import all (or any specific pieces) of the Metro library from CDN (or locally), and use the 137 HTML widgets on steroids, the robust layout and event handling system (no jquery needed), all in whatever text editor you like. It feels like using HTML from a quarter century ago, but looks and feels very modern on mobile and desktop. (He created complete React and Angular versions, and Vue can be integrated easily, but absolutely no 3rd party bits are needs).

posted by: Nick 1-Feb-2023/15:09:31-8:00

Everything is beautifully documented in Metro4ui, and the are some great examples. This one reminds me of some old Rebol experiences:

https://metroui.org.ua/examples/desktop/desktop.html
https://github.com/olton/Metro4-Examples/tree/master/src/desktop

This is the big one, with a bunch of common little app and site layout examples (which I re-mixed in my demo above):

https://themes.org.ua/pandora/

posted by: Nick 1-Feb-2023/15:13:52-8:00

Kaj,

Metro's built-in wrapping of XHR works great to send AJAX requests to any of the Python (or JS, Java, etc.) RESP API implementations, but it's also just as east to send requests to REBOL CGI scripts, etc. (as form-encoded, json, string, or file data). If you're interested in testing any more Meta backend with it, let me know!

posted by: Nick 1-Feb-2023/15:41:36-8:00

Qooxdoo is out of the running for now. It's slow and doesn't work as reliably as jslinb, on old machines.

Metro is a real pleasure to work with.

posted by: Nick 8-Feb-2023/19:10:31-8:00

Thanks, Nick. I have a long list of external projects to review now, and some projects of my own to work on, so it will take me a while.

posted by: Kaj 10-Feb-2023/14:19:03-8:00

I used Metro to layout my music instruction business website (completed while watching the superbowl):

http://rockfactory.us

I've also gotten into using MDB. I actually purchased their commercial version (the first tool aside from Anvil and A2 hosting that I've paid for in many years).

posted by: Nick 17-Feb-2023/9:41:57-8:00

Home