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

I've been on Linux kick lately, settled on using Q4OS (32bit) on old winXP netbooks (atom processors with less than a GB of RAM). We have a pile of those machines, and that OS has won out for a great balance of performance, features, usability, etc. It's fast and immediately usable - Chromium works best (much quicker than Firefox). All the development tools I use are immediately available and work perfectly on that platform.

posted by: Nick 3-Apr-2023/11:24:52-7:00

I've set up those Q4OS machines for non-techie users and my parents, and they've been instantly usable by anyone who's familiar with Windows (and the performance, even on very low powered machines) has been better than I ever expected.

Slitaz is faster, but hard for average users to set up and get started with.

posted by: Nick 3-Apr-2023/11:29:17-7:00

When Slitaz arrived, it was obvious to me that they tried to make it like Syllable. :-) The efficiency and for example the power-off menu.

posted by: Kaj 5-Apr-2023/21:09:23-7:00

There has been so much work done on all these distributions. It's humbling to think about how many man hours have gone into creating so many tools.

posted by: Nick 7-Apr-2023/17:19:38-7:00

I put together a nice little full stack toolkit that's usable on a wide range of older machines. It runs on stock python 2.7 or 3.x, without needing any additional libraries (nothing needs to be pip installed). It consists of Bottle (used as RESP API layer, although it can be used for much more), PyDAL (database abstraction layer that works with a huge variety of RDBMSs - Sqlite works out of the box, and I've included the required MySQL drivers in this little package), and jsLinb for a front end visual builder and framework that connects beautifully with the back end (although any other front end with REST requests can be used). The entire system weighs in at less than 1.5 Megabytes, and takes less than a minute to install (only requires downloading and unzipping - nothing else):

https://com-pute.com/nick/bottle-pydal-jslinb.zip

This is a bigger version with docs and more database drivers:

https://com-pute.com/nick/bottle-pydal-jslinb-complete.zip

I've run the back end and this entire development system on my old Android phone using Termux, on every main version of Windows back to WinXP (should be able to use it on win95 too), on a wide variety of 32 and 64 bit Linux distros, on my A2 hosting account (and pythonanywhere supports Bottle by default), etc. Just download/unzip it and go, it typically takes just a few seconds to get it rolling. Here's a little example with the back end running on A2 hosting (using the default sqlite DB out of the box):

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

Any of the components can be swapped out. I prefer MetroUI for a modern front end, and that framework has already been used with the back end components in this tool kit for several little CRUD projects - it's a beautiful and productive modern framework with a recent version that works back to IE9. I included jsLinb in this toolkit because it's tiny, has a really productive visual builder (the entire visual development system and runtime all together weighs around 600k), and runs universally on just about any any browser (if you code carefully using only the jsLinb API, it can work flawlessly in IE6, the very first iPhone browser, Android 1.2, win95 using Retrozilla browser, etc. - and in every modern browser I've ever tried). I was not careful with the quick example above, so only know that it runs in modern browsers like Chrome and Firefox. You can use any other web framework for the front end (any custom coded HTML/CSS/JS layout or any frameworks/tools (MUI, MDB, React, Angular, Svelte, etc.), that work with XUI, fetch, axios, jQuery, or any other library that enables ajax requests). You could also choose to use Bottle to deliver any front end code from the server - it's not limited to handling REST requests - but REST is Bottle's purpose in this tool kit.

On the back end, Bottle could be replace by Flask, FastAPI, Django Rest framework, Anvil, etc. And PyDAL could be replaced by SQLAlchemy, Pony, Django, Dataset, Anvil, any other ORM, or just pure SQL in Python. ORMs simply enable switching between any RDBMS without having to adjust any of your code for the various flavors of SQL - and they tend to be much more productive, faster, easier, and more enjoyable to work with.

The main benefit of this particular toolkit is that it's backward compatible to Python 2 and doesn't require any pip install, or even an Internet connection to run it - just unpack the 1.5 Meg zip file and it's fully installed, without any other dependencies beyond vanilla Python. It's all open source and free of course.

I've ported a number of little apps from Anvil - once you get the basics of pyDAL and the basics of routing REST requests with Bottle, you're on your way with the full power and connectivity of the Python ecosystem available on the back end, and all the power of the JS ecosystem on the front end (with any choice of frameworks to make work more productive - I love jsLinb for old systems, and metro4ui for new systems). Porting from the Anvil REST syntax to Bottle, and from the Anvil ORM to pyDAL is easy and fast, so back end code reuse and logic is simple.

You can use whatever editor/IDE is available on your development system. I'm happy with VIM or even Nano in a Linux console on a remote secure shell - using tmux to run and switch between processes - or Kate, or Kwrite or any text editor on a local desktop box - and on Windows I typically use Notepad++ (if you want all the autocomplete and modern IDE features, most people currently seem to choose MS Visual Studio Code). Bottle has a built in WSGI development server and I typically use python -m http.server to serve the front end code on a local development server, but basically any other servers work (but to be clear, you don't need anything else buy Python and the built-in tools to use this tool kit).

This toolkit can be used to build web apps that run on basically any common modern or legacy back end (it runs great on those old netbooks with Atom processors booting up to a Knoppix live USB, for example), but it's also a very productive and convenient lightweight toolkit for building desktop apps, since the entire thing can be delivered by simply unzipping and running a shell script, on virtually any remotely modern Windows/Linux/Mac machine from the past 20 years, or any mobile device that can run Python (Termux is very quick to get started with on Android).

Anvil, in its hosted version, is still more productive, powerful, and feature packed - I really prefer using Python function calls on the front end compared to JS and REST requests - but with tools like Metro4ui, jsLinb, or , it's still very productive (I'd like to try with many more visual front end builders...). I love having a little toolkit that works for a broad majority of tasks, which takes seconds to install and runs anywhere, uses Sqlite built in or connects to a massive list of other common DBs without re-writing any code, without any vendor lock-in, or even any lock-in to any particular tool in the kit. Things have really changed :)

posted by: Nick 27-Apr-2023/6:13:04-7:00

This little tool kit has really made me think about all the uses for old and inexpensive machines. Just as an experiment, I bought a little lot of old netbooks for $20 each, and I ran this system on a very fast and powerful Chromebook that cost $50, and on an Android that I bought new at Walmart for $19. Any Chromebook after 2018 should have the Linux developer backend available, and Termux can be installed quickly in the default Android environment on those machines (and Termux does work as a perfectly usable back end for this little tool kit). It looks like used lots of used Chromebooks made post-2018, with 4-8 gigs of RAM and really speedy processors (which run modern websites and all this server software FAST), can generally be bought for $20-$50.

My interest is piqued about finding business and humanitarian applications - inexpensive machines have so many applications, and could be used to build up infrastructure in 3rd world countries. These sorts of software development toolkits make it possible to put old machines to use at nearly no cost. And as AI tools become more powerful and available (in the Python ecosystem in particular), the capabilities for putting computers to use beyond their traditional CRUD and information management, communication, and entertainment purposes, etc., really is exciting. In just a few years, for example, computer AI should be able to teach students math and reading as well as a human interactive instructor. And AI is already fantastic as writing code that takes many man-hours (I've been using ChatGPT to write and port code, and the productivity enhancements are STAGGERING). To have all those sorts of capabilities available on powerful and fast machines that cost a few dozen dollars each, and which may otherwise be destined for land fills, seems to be an opportunity for genuinely transformative possibilities in many areas of the world. Sure, people can use them to start businesses and run custom software for any traditionally useful purpose - but start using the capabilities of already existing AI, and those lots of cheap hardware which are treated like garbage, can be made to really increase human productivity around the world, in ways which we haven't seen yet in human history...

I'd like to find a way to put those machines to use - especially the mountainous piles of powerful used Chromebooks that could be used to perform really powerful work.

posted by: Nick 27-Apr-2023/6:51:21-7:00

BTW, Streamlit is also still a really cool tool, which makes me think a lot about the way that I could do CRUD work with a GUI in Rebol, except that Streamlit database apps are multi-user by default, and can run on any 'modern' desktop PC, mobile phone/device, Chromebook, etc. - by 'modern', I mean any computing device that has a decently modern browser available (on most platforms, this includes hardware from 10-20 years ago). The example below uses the super simple Dataset ORM library to perform database operations (this example uses Python's built-in sqlite DB, but you can switch to MySQL, Postgres, etc., just by changing the connection string - no other code changes need to be made). These 12 lines are the entire code listing required to build, configure, and instantiate every part of the fully functional CRUD app, with 2 database columns, including the user interface and all database interactions:

import streamlit as st, dataset
db=dataset.connect('sqlite:///db'); t=db['user']     #t=table
if st.button('Add Row'): t.insert(dict(x='',y='')) #x,y=name, note
for r in t:                                         #r=row in table
    with st.expander(r['x']):
     with st.form(str(r['id'])):
        x=st.text_input('Name', r['x'])
        y=st.text_area('Note', r['y'])
        if st.form_submit_button('Save'):
         t.update(dict(x=x,y=y,id=r['id']),['id'])
        if st.form_submit_button('Delete'):
         t.delete(id=r['id']); st.experimental_rerun()

The above code is running at:

https://datatable.streamlit.app/

To set up a computer system to use Streamlit and Dataset (on any 64 bit machine/OS with Python 3 installed and an Internet connection), you just type 'pip install streamlit dataset' in the console. There's nothing else to set up. As cool as this is, Anvil is still much more productive, powerful, easy to use, enjoyable, etc., for most of the sorts of work I've been doing for the past year. My little bottle-pydal-jslinb tool kit linked above is just more portable - the entire development system (with visual drag and drop front end layout), server, and client components can run on basically any device/platform that I'd imagine being in common use today.

posted by: Nick 27-Apr-2023/10:24:55-7:00

I should clarify: to set up a computer to *serve apps written in Streamlit/dataset, you just need to pip install streamlit and dataset. To *run the apps, you just need any modern browser on any device (as you see by going to https://datatable.streamlit.app/). BTW, the sqlite DB used by https://datatable.streamlit.app/ is automatically cleared periodically (this isn't the case if Streamlit is run in any other environment).

posted by: Nick 27-Apr-2023/10:29:51-7:00

I only get a wait animation on your JSLinB example.

posted by: Kaj 29-Apr-2023/7:17:05-7:00

Opening your Streamlit example from here takes around 40 seconds the first time, and 12 seconds the next time.

Performance for common applications is often determined more by keeping the platform small, than by using performant techniques for details.

posted by: Kaj 29-Apr-2023/7:47:26-7:00

There are people making Streamlit-like tools which are far more performant. It's a neat approach which is used mostly by data scientists to present visualizations and UI for in-house apps. I like the concept of a system which hides the complexities of front-end/back-end interactions. In production, Anvil's approach is still far and away more effective, but Streamlit has clearly struck a chord with data scientists who aren't software developers - it's tremendously useful for that crowd.

As I mentioned, I wasn't careful ensuring the app at http://musiclessonz.com/jslinbcrudgrid/bottlepydaljslinb.html ran in every browser, so it may need to run in Chrome. I'm curious about which browser didn't load it, and if this one runs any better:

https://musiclessonz.com/jslinbcrudgrid/linbDemo4.html

posted by: Nick 29-Apr-2023/10:30:03-7:00

I'm also curious if this runs in the browser which didn't load the link above:

https://com-pute.com/nick/metro4uicrud.html

If not, I may choose to use a slightly older version of Metro4UI for public facing apps. The jsLinb front end is meant for in-house apps that need to run in older browsers. I'll likely end up using a version of Metro or maybe MDB, which falls back to older custom HTML for really ancient platforms. It's getting harder and harder to want to support old platforms when lots of powerful Chromebooks can be bought $17 each, and they run Chrome ridiculously fast, without any n compatibility issues - or when we can boot a $10 netbook to Knoppix, and it runs all this stuff without any hitches or setup in Chromium or Firefox out of the box.

posted by: Nick 29-Apr-2023/10:42-7:00

... or in any Android or iPad/iPhone running Chrome. It's getting hard to find common machines and devices in actual productive which don't support modern front end web standards by default. In fact, most people I work with find my interest in supporting old systems a massive waste of time. I do it for personal reasons, but it's generally better just to require users to use a device with some semblance of modern usability. Deciding to not use a software development system because I can't get it to run on my Tandy handheld pc from 1984 is not practical in the environment in which I live life.

posted by: Nick 29-Apr-2023/10:49:46-7:00

It's faster and easier and better for me to even build 2 alternate front ends, than to deal with compatibility issues for users who don't want to use some sort of reasonably mainstream or modern device/UI. My back end toolkit above supports 99.9% of every sort of machine I'd ever expect to be un use by the sorts of people and organizations that I interact with in the mainstream world - Anvil even can claim that - and the developer comfort/productivity, and the lack of user troubles I now experience eclipses any experience I ever had with Rebol, far and away, without reservation.

posted by: Nick 29-Apr-2023/11:02:23-7:00

It's always possible to say 'I was able to get this app to not run' by using some system out of the mainstream, but does the fact that someone can't get Flappy Bird to run on a particular platform invalidate to choice to build that app to run on more popular and available platforms? I'd rather write software that will run for 99.9% of my users, because they're running a platform that 99.9% of users can be expected to be using. And if they don't have one of those platforms, and want to run some software I've created, they can buy a device that will run it fast and flawlessly for $20.

posted by: Nick 29-Apr-2023/11:08:48-7:00

I understand the point of wanting to build systems that can be compiled to run on an Atari, because that means that they can likely be ported to run on any machine. But then I could just say 'well it won't run on my abacus'. The fact is, the sorts of machines that are needed to run any sort of modern platform, are now old and being thrown in the trash, so that seems like a decent baseline requirement in terms of platform and hardware that should be required to run any sort of usable software these days. If old, trash hardware can run the software that I write, I don't think there's any need to support anything older. I'm not going to support an abacus.

posted by: Nick 29-Apr-2023/11:17:40-7:00

Honestly I think all of these discussions are going to be antiquated in just a couple years. It seems that the unstoppable force of AI will change how every bit of development is done, and even the idea of software development by humans, at the level we imagine it now, will just be a historical memory. What I've seen in just the last couple months, which has been mind blowing, is just the very beginning couple steps in the journey that AI will take us on.

posted by: Nick 29-Apr-2023/12:07:46-7:00

By the way, taking 40 seconds to open an app for the first time, without having to install anything, or do any other sort of prep to be able to run the sorts of powerful applications that are having profound effects in the environments in which streamlit is used, is not the bad thing that you seem to think it is.

posted by: Nick 29-Apr-2023/13:11:33-7:00

In any company where a data scientist would otherwise have had to work with their infrastructure's development team to deliver the results of their research, or otherwise take enormous amounts of time to perform the work and the maintenance required to deliver results and provide a workable user interface, it's an absolutely industry changing Improvement. That's not an opinion, just the reality of what's actually happening with that particular tool. My use of Anvil, and other tools, is likewise an unmitigated triumph (for my needs), compared to the overall issues I experienced using Rebol - in the same way that Rebol provided similar improvements over previous tools.

posted by: Nick 29-Apr-2023/13:19:17-7:00

Judging streamlit's value by the fact it took 40 seconds to open the first time feels comparable to hearing people judge Rebol because they didn't like the default colors and look of the VID interface.

posted by: Nick 29-Apr-2023/13:26:15-7:00

BTW, a part of that performance is also because it's running on the free streamlit hosting service... not to mention, it only took me *8 seconds to open that app for the first time on a 7-year-old Android phone that cost $20 new, and *4 seconds to open on a reasonably new netbook. That's not a problem by any measure, it's a valuable, useful, welcome solution.

posted by: Nick 29-Apr-2023/13:39:26-7:00

BTW, also my little bottle-pydal-jslinb demo takes *1 second to open on that same old Android phone, with no installation and no other requirements on the (multiple) users' side, and a minute to install on the server.

posted by: Nick 29-Apr-2023/13:47:23-7:00

Premature optimization is well understood as a problem in many environments. No one is using anvil to build a replacement for Unity or Unreal Engine, and of course most of the heavy hitting libraries in the python ecosystem are written in C, but they're written once and reused in a more productive tool set. Discarding the possibility of development using a system that doesn't support a small fraction of on a small fraction of all existing machines, when it's almost certainly better to replace an offending machine or the browser, is not something that works in my world.

posted by: Nick 29-Apr-2023/14:21:26-7:00

I'm definitely an outlier for even considering to put together a tool kit that runs on such a vastly broad variety of machines, compared to all the commonly used tool systems that are in popular use, and I'm really excited to have that set of tools available for the weird circumstances in which I can't use the other big systems I have available that work for the absolutely overwhelming majority of cases that I will ever be involved with, and to have such a system that makes the vast majority of the modern python ecosystem available to me in such a productive way.

posted by: Nick 29-Apr-2023/14:24:52-7:00

The circumstances, costs, scope, and capabilities of modern computing systems are very different than they were when the Atari was released. There's No Business justification to optimize any of the systems I'm using more than they already are. If I was a systems developer, I'd work in C and assembler. Those aren't the kinds of problems I'm interested in. We clearly have different perspectives about what we want to accomplish, and even the sorts of technological development we're interested in. The foundations of the systems that I'm using are clearly more complex at their heart, then you're willing to work with, but they are extremely well established, well tested by tens of millions of users, and generally problem-free for their users, compared to anything from previous generations. They are solid, productive, and useful in productive ways that absolutely blow away historical software development systems aimed at that sort of work.

posted by: Nick 29-Apr-2023/14:35:08-7:00

I recently had an experience with a businessman who decided to use Anvil to build his next project. He's a rockstar tech CEO who's made companies many hundreds of millions of dollars over the past 40 years. He chose Anvil out of a variety of other tools. My only role was to help him build certain features of the company's public facing app. Recently, I've been watching his marketing and data science teams do their work, and it's absolutely awesome to witness what is clearly going to save the company many millions of dollars and wasted effort, and likely turn this venture into another company worth $100M+. I'm interested in that sort of work. They did some absolutely remarkable computing work, often researching and finding extremely valuable results several times in a day, refining and focusing their market goals in ways that clearly will have a tremendously positive financial effect. At no point any of those interactions was anybody worried about wasting a few seconds waiting for an app to open. The value was in the computational work they were able to accomplish. That's not software development, but it's an extraordinarily valuable aid to business. That's what I've always been interested in - computing tools which provide real value to users in business in real life, as opposed to technical computing and software development accomplishments. Anvil, Streamlit, and this little tool kit that I posted, provide such value to me, and from what I see the mainstream tools do the same for many others.

posted by: Nick 29-Apr-2023/15:06:27-7:00

Being able to scrape third-party websites, perform complex analyses of trends in data, and provide various useful visualizations of the results is handled so dramatically easily with

tools such as streamlit. The value of fast productivity with powerful data collection and analytical tooling can't be overestimated. And that's much more exciting to me than low-level system development. I feel the same way about what AI has already done for me in the past couple months. I had a client who came to me with thousands of lines of production C# code that he wanted moved into a web app. In one night, I was able to accomplish what previously would have taken many weeks of grueling work, using ChatPT to analyze the logic, code structures, data structures, etc., of the previous app, write python code to replace it, structure, check and reevaluate, troubleshoot and debug my work, Etc. In the end, we chose to repurpose his existing code in a different way, but the AI did an absolutely amazing job that would have taken many dozens of human hours. Since then I've gotten used to using it for absolutely everything, and I expect that human work in software development will change dramatically within the next year or two. Like I said, I think the sort of things we're thinking about now will be antiquated in just a few more years after that, and I'm so excited to be able to use tools like what exist already!

posted by: Nick 29-Apr-2023/15:20:31-7:00

A little tool kit that I put together just enables me to use all the same ecosystem, which existing AI tools have proved to be able to work so beautifully with, and run code in environments that the newer productive tooling can't be used on. To me that's extraordinary valuable.

posted by: Nick 29-Apr-2023/15:22:51-7:00

JSLinB not working and the Streamlit form taking 40 seconds to load happens on the latest version of Brave on my new Samsung phone, which is based on the latest version of Chrome.

posted by: Kaj 29-Apr-2023/21:24:03-7:00

Thank you, that's helpful :) Does this work in Brave?:

https://musiclessonz.com/jslinbcrudgrid/linbDemo4.html

Or this metro front end?:

https://com-pute.com/nick/metro4uicrud.html


posted by: Nick 29-Apr-2023/22:21:39-7:00

Here's a copy of the jslinb demo above using another version of jslinb, does it work in your browser?:

https://musiclessonz.com/jslinbcrudgrid/linb4Demo/

I may end up using that version if it works for you (I've seen it work better in version 10 of IE):


posted by: Nick 29-Apr-2023/22:27:51-7:00

One of the nice things about all of these toolkits, is that any front end which can connect to a REST API can be swapped out easily.

posted by: Nick 29-Apr-2023/22:32:10-7:00

Does this Anvil front end work in your Brave browser?:

https://crudgrid.anvil.app

posted by: Nick 29-Apr-2023/22:35:35-7:00

Only the first JSLinB hangs on the wait animation.

The others have reasonable load time of a few to several seconds. However, my Meta/REBOL web apps load faster, in around a second, depending on your location and Internet quality. This is important for not turning away modern users with short attention spans.

posted by: Kaj 30-Apr-2023/6:05:06-7:00

Thank you! To be clear, both of these work?:

https://musiclessonz.com/jslinbcrudgrid/linbDemo4.html

https://musiclessonz.com/jslinbcrudgrid/linb4Demo

All of those examples use a back end on the shared host version of Anvil in a small personal account based in England, so yes, it is slow. The same Anvil code is *very fast when served on my A2 account, and of course that speed can be optimized with faster dedicated machines and other significant server optimizations. My little tool kit is *dramatically fast compared to Anvil, because it is much simpler (Bottle is a single code file of only ~4000 lines), and the built-in development server can be *swapped out* for other lightning fast servers that can compete in performance with any other server in the market (and can scale up to handle any load), so performance speed can be absolutely world class. Of course, some of the biggest busiest sites in the world run on Python.

posted by: Nick 30-Apr-2023/10:20:50-7:00

https://musiclessonz.com/jslinbcrudgrid/linbDemo4.html
does not work.

England should be fast here in the Netherlands.

Your Anvil example above is only slightly slower than the others, about three versus two seconds.

posted by: Kaj 30-Apr-2023/10:43:14-7:00

Streamlit is not fast, and I expect it doesn't scale well. It's purpose is developer productivity - used to deliver the sorts of daily in-house work such as the back and forth marketing research/analysis I witnessed. For that sort of work, it's a phenomenally useful tool. Some people do use it to build web sites with moderate traffic, but it's clearly not suited for busy e-commerce.

The nice thing about the massive Python ecosystem is that there are tools to satisfy every need. There is free hosting available to support all the productive little tools such as streamlit, and porting Python code between frameworks is fast and easy. By using an ORM such as PyDAL I can use sqlite for development and light production use, and then switch to postgres, oracle, mysql, mssql, mongo, google app engine, etc., without changing any code at all (just a connection string), and aditionally, pydal can help scaling up with connection pooling, connecting multiple servers, etc. There are so many options for perfect, hyper-productive prototyping environments, and also for deploying at the largest scale, using battle-tested frameworks that handle 100s of millions of users. And of course, there are libraries that make quick, reliable, and performant work of just about any task, and there are billions of lines of code that are already being used to train AI.

posted by: Nick 30-Apr-2023/11:01:17-7:00

Thank you so much for the feedback! It's very helpful to know that https://musiclessonz.com/jslinbcrudgrid/linb4Demo works where https://musiclessonz.com/jslinbcrudgrid/linbDemo4.html doesn't. That's been the case with 2 other browsers, and since my only point in using jslinb is to have a visual layout tool that produces front end code that connects to any of the back end systems, and works in the broadest range of new and very old browsers, I'll stick with that version. That version of the editor also includes autocompletion and a few more widgets. I'll upload a version of my toolkit with that jslinb:(

posted by: Nick 30-Apr-2023/11:12:30-7:00

The Anvil example above is only slightly slower than the others because those other front ends are running on the same Anvil back end for REST functions. I'll publish a version using the better jslinb with the bottle-pydal backend, and several different DBs. I should also try using something other than the development web server in Bottle. The end result of all that should be blazing fast and scalable.

posted by: Nick 30-Apr-2023/11:22:19-7:00

This should work now:

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

And here it is hosted on the same server as the back end (still running in Bottle's development web server). I'm not sure yet if that makes much of a difference:

http://server.py-thon.com/bottlepydaljslinb.html

posted by: Nick 30-Apr-2023/17:27:24-7:00

First one hangs on the wait animation, second loads in about six seconds here.

posted by: Kaj 1-May-2023/5:49:32-7:00

Thank you for checking - that's bizarre They're the exact same code and CORS is set up properly (and both use the exact same back end). I'll focus on the other version of jsLinb - I've notices that safari and IE 10 also have some unexpected interactions with that older version of jsLinb, but not with the newer one (I was hoping to use the smallest, simplest version possible). That feedback is very helpful - I appreciate it.

posted by: Nick 1-May-2023/7:44:58-7:00

I'm curious what about your situation is making everything take so long. The apps above open fully on my old Android (and a massive variety of other devices, OSs, browsers, and Internet connections) in less than a second, so it's not something inherent in the software or the hosting. Why it's taking so dramatically long for you, makes me wonder what other layer between your new phone and these apps is causing such exceptional delays.

posted by: Nick 1-May-2023/8:28:34-7:00

Right, there is no silver bullet. ;-)

posted by: Kaj 1-May-2023/8:28:35-7:00

RockFactory from England is OK, 2 seconds.

I suspect RockFactory 6s is US? Across the pond, inefficiency multiplies.

posted by: Kaj 1-May-2023/8:32:49-7:00

Most popular web frameworks work for the overwhelming majority of users, with the overwhelming majority of devices in common use, at least in my sphere of existence. I haven't had a single client, or any of their users ever have any usability issues or make any mention whatsoever about slow performance with any Anvil app, so it has absolutely been a silver bullet for mainstream users using all the most popular devices in common use. Your experience here has been the sole outlier. My little toolkit is just an effort to support ancient systems which generally aren't used any more by mainstream users, but which are interesting to me.

posted by: Nick 1-May-2023/8:39:45-7:00

Rockfactory is currently hosted on Hostpapa (cheap shared Apache hosting account), using metro4ui as the front end. It also opens instantly on any device/OS I've seen. Our clients use it every day.

posted by: Nick 1-May-2023/8:44:06-7:00

Your feedback here has been very helpful. For any production app not developed in Anvil (not in the cards for me generally right now), I'll use metro4ui (or maybe MDBootstrap) for any public facing UI. I'll get the newer version of jsLinb working, for my own interest in supporting special old devices and ancient browsers - it seems to work on 99% of every old browser/OS, and all the new ones. I was hoping to use the older, lighter version, but that's not as important as compatibility, for its use case.

Thank you for all your help. If you need any help testing your new build servers (very exciting - I'm so happy to see you making progress!), please let me know.

posted by: Nick 1-May-2023/8:54:40-7:00

Here's little toolkit demo, redone using the newer version of jsLinb, with front end and back end both hosted on the same server (A2):

http://server.py-thon.com/botdalinb4/linb4demoNEW-botdalinb.html

Here it is with the front end hosted on my HostPapa shared account:

http://musiclessonz.com/jslinbcrudgrid/linb4Demo/linb4demoNEW-botdalinb.html

Here's the same front end, with Anvil as the REST back end:

https://musiclessonz.com/jslinbcrudgrid/linb4Demo/linb4demoNEW.html

I'm curious if there are any browsers or devices that have any problems with them.

posted by: Nick 1-May-2023/23:59:33-7:00

Most of them load in 3 seconds the first time, then 2 seconds the second time.

The first one takes 4 seconds the first time.

The second one keeps saying: Error: Network problems-0

It's very unlikely that this has to do with the browser. Brave is a fairly common, popular browser, anyway, based on Chrome.

posted by: Kaj 2-May-2023/4:31-7:00

Those results are exceptional, and nothing inherent in the software. Here's a video of the demo apps running on an old Lenovo Thinkpad netbook and an old Android phone, connected to the Internet using a T-Mobile home cellular router.

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

Here it is running in the very old QTWeb browser on that same underpowered Thinkpad netbook:

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

Here are a couple Streamlit and Anvil app examples:

https://www.youtube.com/watch?v=4z97odNdN20


I tried my little toolkit demo app example yesterday on a variety of old $20 netbooks running Knoppix, 32 bit Q4OS and various versions of old Windows, Chromebooks, new and old iPhones, iPads, and Androids, and in a wide variety of browsers, all run by me and a random assortment of friends at a number of locations, without any hiccups or delays of any sort whatsoever.

In every case, each version always takes less than a second to load, without exception.

It's important to note that *those Youtube videos*, as well as any of the other common Google apps, and all of the common web sites in popular use by hundreds of millions of people, ALL take several seconds longer* to load on those same devices, so the idea that this software itself doesn't perform well, clearly doesn't hold water.

My experience delivering web apps for the past year+ has actually been exactly the opposite of problematic. The truth is, delivery of software using Anvil and python web apps has been an absolutely glorious, trouble free pleasure, compared to my previous experiences trying to get people to download and run apps across a variety of platforms and devices. Rebol made that situation a bit easier than it had been previously (in the dark ages), because it was so light weight and simple - but of course there were still always a mountains of user issues and troubles getting people to use any installable software on any machines in the wild. With many hundreds of regular client users, using every sort of mobile and desktop device/OS/browser in the wild, I've never had even a single complaint or trouble getting people to use my Anvil web apps. I just send them a link. That's it. They click the link and the apps runs - whether they're on desktop or mobile, and whatever version OS, hardware, etc. Web apps have have been so dramatically easy to deploy - not to mention *upgrade. Users are automatically using the most recent version of Anvil apps, just by opening the link in their browser - there's no upgrade procedure - the worst thing a user might have to do is refresh their web page, or God forbid, try another browser (I haven't even run into that yet).

These demos of my little toolkit with jslinb are an experimental side project at the moment, in the very first few days of development - the Anvil apps are what I'm currently using in production (and a bit of metro4ui with self-hosted Anvil on the back end). The fact is, there are clearly not any *inherent performance issues with *any of these platforms - no more so than any other web app, and in fact better than most massively adopted web apps. And I'm demonstrating these apps on ancient hardware and browsers.

You can see that they clearly perform fast. Your unusual outlier experience is introducing some obviously significant delay for *every single* platform and hosting environment that I've linked to here, so that's telling. Streamlit is a slow system, but it clearly doesn't take 40 seconds to load for most users - just a few seconds on an old device with slow hosting. It's much faster, closer to instant, on any common modern device. Obviously, it wouldn't be adopted the way it is, if a typical user's experience required that sort of wait time. If you were a client, clearly I'd have to help you determine the cause of your particular slowdown, but I've not had that experience with any user in production yet, using any of these platforms.

posted by: Nick 2-May-2023/8:49:32-7:00

It's got to be pointed out that no Rebol app was ever used by nearly as many people as any of these Python platforms, not even Streamlit. And there's no comparison to the battle tested, rock solid use examples of Python platforms such as Django and Flask in production at Instagram and other sites that have hundreds of millions of users. I'm not crazy to think that these platforms are viable, stable, and performant.

posted by: Nick 2-May-2023/8:58:27-7:00

jsLinb is clearly the weak link in my little toolkit, but that's easily replaced. I'm just motivated to put that to use, because it's the best all-round solution I've found for ancient browsers (that doesn't apply to mainstream users). Bottle, pyDAL, and other front end options are battle tested.

I appreciate your help looking at the toolkit examples. I'm satisfied with my local results with jsLinb, but now motivated to continue working with metro4UI and other front end options. Anvil will continue to be my production system.

I can't help by wonder why every single platform example you've tried here has performed so remarkably badly.

posted by: Nick 2-May-2023/9:10:17-7:00

I should reiterate my perspective about everything related to software and tech in general. The greatest value I find in computer technology is as an aid for improving processes and productivity in 'natural' life. In an afternoon, I can build an app to handle ticketing and admissions for performances of my new musical. Or I can take 20 minutes to write an app that connects with the dall-e or chatGPT APIs, to interact with and use those resources in ways that are repeatedly productive and beneficial for my business and personal needs. Or I can likewise use the Twilio or Dailyy APIs to add custom text message and videoconference capabilities to an app in a few minutes. Or I can take a few days and write a business system for an accountant friend which runs all his payroll and billing, saving a dramatic amount of work and trouble for everyone in that office. Or I can build custom software to run every piece of operations at Merchants Village, Rockfactory, and all my other endeavors, in my odd free hours.

Being able to simply text, email, or verbally give a link to every mainstream user of my current apps which they can just open on whatever phone, tablet, or computer they have, is a life changing improvement, compared to the old ways of doing things, which eliminates most of the time consuming problems inherent is distribution of apps (and development productivity, of course).

Giving data scientists and other professionals, whose main focus is not software development, the ability to quickly deliver the results of research, enables improved progress in so many industries. Making quick work of that goal is worth making their users wait a few seconds to open an in-house app, if they're using an unusually old or otherwise disabled or specialized device/system.

I have an interest is making software work 'everywhere', but that takes a resolved back seat to 'productive use of computing resources', which in my applications, has been tremendously improved by all these Python tools, in the same way that Rebol had improved that situation previously.

I'll likely never take part in systems development. My tools are not meant for that purpose. I deeply respect that sort of work, and every value that you have related to developing Meta.

I'm just sharing what is working for me, and working brilliantly, compared to every system I've used and tried in the past (many hundreds, of which Rebol had previously been the best choice for my needs), in the hopes that someone with my same values and requirements may find my current experiences helpful. Compared to Rebol, Anvil and the Python ecosystem has been far and away more effective at enabling the sort of productive use of computers, and I think some of these other Python tools will fill in the gaps for which Anvil is not effective, without much additional overhead (and the ability to port working code, etc.).

That's not to say I don't appreciate and look forward to seeing what you'll accomplish with Meta. It's exciting to you move forward and hopefull building something even better, and with more potential!

posted by: Nick 2-May-2023/11:28:06-7:00

I'm doing nothing special to provoke this, just clicking the links you ask me to try in my popular browser of choice.

I think you need to accept that performance of web apps from the other side of the world is different than nationally. It is dominated by how your software performs over the Internet, performance of your devices becomes a minor matter.

My Meta/REBOL web apps are currently hosted in the middle of the US, but I can access them in around a second mobile from the Netherlands. This is a comparable situation to when I access your demos that run in the US.

posted by: Kaj 2-May-2023/16:03:33-7:00

You're not provoking any trouble, just helping to clarify our perspective and priorities. The performance troubles you're experiencing are not a problem for my use. My Anvil apps are hosted in England. There has been no performance problem using them in the US, and the self-hosted app implementations have performed faster for my use. My little toolkit isn't meant to be used to serve apps to an international community at a large scale. It's meant to be used to build in-house and local apps that can run on as broad a variety of systems as I may ever want to use, including old and under-powered devices which are generally just thrown away these day (I imagine potentially valuable uses for those sorts of machines). It satisfies that requirement effectively and productively, while supporting the most important requirement of mine, which is to enable the availability of all the tools in the Python ecosystem. Any code I develop with that little tool kit, Anvil, vice-versa, or with any other Python tools is then portable to bigger systems, with more performance options engineered in and scaling practices that have been put to the test by some of the biggest deployments online.

The speed of the systems I'm mentioning here doesn't create any usability problem for me. The lack of capability, connectivity, deep support, convenient deployment options, and productivity features, has been my problem with other systems. The Python ecosystem and these tools have solved those problems, and I can scale up using any of a variety of tooling options that an army of developers know how to use (not to mention existing AI tools that are phenomenally productive). If I ever need to hire others for a big project, collaborate personally or to do work in a organization with other developers, for example, I don't experience any friction using Python, JS, etc. And beyond that, I get lots of enjoyable work being hired to satisfy needs with these tools, which I find satisfying and fulfilling.

I'm just sharing my experiences and my excitement with what these tools have enabled for my needs. We currently have different requirements for tooling systems. I'm simply posting and clarifying my personal thoughts and experiences related to my long list of experiences with Rebol, in a thread entitled 'What I'm using now instead of Rebol'. I don't know if anyone else will ever read any of this, by I hope it's useful for someone, especially as an extension of (or comparison with) anything that I ever wrote about how Rebol was useful and productive for my needs. To that end, it's important to put into perspective how your usability issues are not at all a trouble for my use cases. I'm glad for the feedback, to know some metrics about how my particular little toolkit and hosting choices are not best used to deploy a multinational site/app, but those results don't effect my current use, and deployment practices can be dealt with as needed, if I ever happen to become involved with a project that must scale for a wider user base around the world. It seems that my hosted Anvil apps deployed on AWS already work well all around the world, and they can be scaled up dramatically (one of my clients was able to get support from Anvil to scale up to 300,000 requests per *second*, if his needs grew to that level! Of course that would cost a lot, but still just a fraction of his proposed budget). So I appreciate your feedback, and welcome any criticism and comparison with what Meta can accomplish. I'm fully aware that your intention to eliminate complexity is quite worth while, and I do deeply respect what you're working to achieve, and the challenges you face. My needs and goals in working with development tools are currently different, but I'm keen to keep an eye on what you create - and willing to help if I can potentially make a difference.

posted by: Nick 2-May-2023/20:19:06-7:00

If you want to try installing any Meta applications on my server, for the sake of performance comparisons that may be beneficial to you, for testing purposes, or any other reason, please let me know :)

posted by: Nick 2-May-2023/20:26:14-7:00

BTW, one of the things I'm eager to try after your feedback here is faster WSGI servers that work with Bottle - something other than the built-in development server, which isn't intended to be performant. Also, I'm curious to compare the performance of Flask, Django, and FastAPI (I've seen some benchmarks in which fastAPI is 3x faster than Django), and compare the performance of pyDAL, SQLAlchemy, Pony, Django ORM, and various pure SQL drivers in Python (I've seen benchmarks of pure SQL being 2x faster than sqlalchemy in some case). Also, different implementations of Python, and various established distribution methods are beyond my current scope of knowledge, but tools such as Django are used to deploy sites/apps at absolutely massive scale, so I'm excited to learn. At this point, I (or clients) can simply pay Anvil to manage that work - they're capable of handling any imaginable scale that Anvil might possibly be put to use for (that's pretty cool, because it provides single developers the possibility of writing an app which can actually grow significantly, without having to know much at all about how to manage those requirements). I'd love to see how far my new little toolkit could actually be pushed eventually...

posted by: Nick 2-May-2023/20:47:26-7:00

BTW,

I'm curious how long these database requests take from your location:

http://216.137.179.125:8080/repeating_panel?color=red&date=none

http://216.137.179.125:8080/readgrid

Those are pure back-end requests which code be used by any front end, delivered by my little toolkit, hosted on A2. If they're not as instant as any other sort of request for a few characters of static data from a typical shared host Apache server, then I need to change the WSGI server, or the hosting.

posted by: Nick 2-May-2023/22:51:44-7:00

"I think you need to accept that performance of web apps from the other side of the world is different than nationally. It is dominated by how your software performs over the Internet, performance of your devices becomes a minor matter."

That is incorrect in this situation. The fact is, responses to those servers requests are *consistently* delivered in a matter of milliseconds. The only additional delay you should experience in receiving them is the time it takes your client computer to generate the request, the time it takes for the request to travel from your location to the server, the time it takes the response to travel back to your machine, and the time it takes your machine to display the response data.

I've already demonstrated that my software generates and sends the request at the client side, sends the result on the server side, and displays the result on the client side *instantly*, consistenyly. There's nothing more that can be improved as far as the performance of the software goes. The speed of light and the routing of those signals between your location and the server is out of my control. The performance of your machine is out of my control. Those back-end requests are consistently producing instant results on my server - there's nothing to be realistically improved (perhaps a few milliseconds, but that's not any significant part of the difference in performance you're experiencing).

So, I have to insist that I don't need to "accept that performance of web apps from the other side of the world is different than nationally. It is dominated by how your software performs over the Internet". Every piece of my demo IS performing every bit as well as any other framework would, at least as far as you should be able to perceive a difference in performance. The way it can handle a load and handle 300,000 requests per second is another issue, but that's not the case here, and that would have more to do with load balancing and distributing work to multiple processors, syncing the availability of database results, using tools such as caches, etc. In this case there is *nothing inherent in the performance of my little toolkit which makes it perform any worse than the same demo written in Meta, or any other back end - not to the degree that you're seeing performance deteriorated. Everything about the server and client performance is fast enough that you shouldn't be able to perceive a difference between it and another system. If you could measure a difference in performance in milliseconds, the potential variations in travel time between client and server, due to distance, routing paths, etc., which are out of the scope of what the serve and client software can control, are likely greater than the differences in those potential performance improvements.

Something else about your particular setup, on the client side, outside the performance of anything in my toolkit, is causing those delays.

BTW, that's not entirely true for the Streamlit example - that toolkit IS slow and does take a few seconds to display client results - because it completely reloads the entire interface every time any request is sent - but even for the example you saw, that performance difference should be measured in perhaps a second, or maybe 3-4 at the most - not the delays you've experienced. Either way, that is not true of my simple toolkit - requests, responses, and the display of responses are all instant, as far as what can be perceived by humans. And my hosting isn't the problem - it's delivering those performance results. Everything else is due to third party infrastructure, routing, and device performance that is out of my control.

posted by: Nick 3-May-2023/1:31:43-7:00

The only exception to that would be if you're able to control the routing and network configuration between the server and client, but again, that isn't limited by the language that runs on the server. None of the performance issues you're experience are a Python vs. Meta issue. It either has to do with the performance of your client machine, your network connection, or the performance of the front end interface in your browser (and that's not a matter of Python vs Meta either). The server responses are already blazingly fast, to the point of being perceived as instant, and can not be improved in any way that would make the app perform perceive-ably better.

posted by: Nick 3-May-2023/1:42-7:00

... and when it comes to scaling to handle a tremendous traffic load, support for the tools in the Python ecosystem are already built, and deeply battle tested, to make that escalation happen as painlessly as possible.

posted by: Nick 3-May-2023/1:45-7:00

I'm genuinely curious about what the cause of you performance delay is. The responses to those REST requests above are instant, no matter what sort of front end sends the request and displays the response. They can't be improved in any practical way. Nothing about any front end I'm using is slowing done the sending of those requests, or the display of the responses (and that doesn't really matter because it can be swapped out with any other front end interface). So where is the problem?

posted by: Nick 3-May-2023/1:52:23-7:00

To be clear, you don't need to take part in this discussion if you don't have time or interest. Like I said, the system is performing fast, it doesn't need to be tweaked. I'm just curious about what is causing the delays in your situation. Those delays are not due to anything in my toolkit or anything else I can control, as far as I can tell. The server responses are instant - they can't really get faster in any way that would make any sort of practical difference.

posted by: Nick 3-May-2023/1:55:35-7:00

For what it's worth, you should be able to read those REST URLs with your browser, Rebol, Meta, Curl, or a Python client, and the results should be instant, and delayed only by the speed of light + routing. If not, then there is something outside the software causing the delay.

Perhaps the A2 environment is the problem, or perhaps the development WSGI server in Bottle, but as I've demonstrated, that doesn't seem to be the case...

posted by: Nick 3-May-2023/2:11:34-7:00

Thanks for the server offer. I currently have a network of seven servers around the world, so I have enough testing opportunities.

Your two test requests open near-instantly in Firefox, but they don't open in Brave.

However, network app performance is not about single requests, it's about multiple requests that need to wait for each other. I guarantee you that the delays in your demos are linear with the number of roundtrips they make to the server that are waiting for each other.

The best way to speed up work is always to make that work unnecessary. That's why I present reduction of complexity in Meta as a performance feature. Dependent roundtrips dwarve any other considerations in the design of network apps and need to be minimised.

posted by: Kaj 3-May-2023/5:23:37-7:00

I could eliminate CORS handling, and that would cut out a round trip, but that also has nothing to do with language.

posted by: Nick 3-May-2023/10:25:23-7:00

I could eliminate CORS handling, and that would cut out a round trip, but that also has nothing to do with language, and is entirely controllable using my little tool kit.

posted by: Nick 3-May-2023/10:59:10-7:00

That's just a matter of momentary convenience, all I need to do is serve the front end HTML file from Bottle, instead of from a process running on a different port.

posted by: Nick 3-May-2023/11:01:20-7:00

It seems clear that Brave is enforcing CORS requirements in ways that are more strict that expected. I actually did include some stock code to handle 'OPTIONS' requests in some functions, but not in all. The fact that you received some network connection errors at one point using Brave indicates that it's certainly handling CORS requirements more strictly than the other browsers I've tried. So that's adding *at least* one additional round trip. Of course my HTML hosted on Hostpapa is then requiring at least one additional round trip, and even the HTML hosted on A2 is experience the same, because it's served on port 8000 and the Bottle code runs on port 8080. I'll just serve the HTML from Bottle - that should be a very simple fix. The instant response from those Get requests,using the other browser, is more indicative of the performance speed of this little toolkit. Thanks for the feedback, that's helpful!

posted by: Nick 3-May-2023/11:32:49-7:00

I could write very fast web apps in Python, but where's the fun in that? ;-) If I have to write them from the ground up, anyway, because all those frameworks are sprinkled with way too many dependent roundtrips, I might as well do it right and throw in a REBOL language.

The next consideration in performance, after the app has loaded, is how the client performs. Python doesn't run in browsers, and it's an interpreter, anyway. Meta does run in browsers, and it's compiled, much faster.

posted by: Kaj 3-May-2023/11:40:11-7:00

If you're spreading parts of your apps over different URL's, that's one sign of complexity to me. Even without knowing if it would cause any issues, I would avoid such constructs, unless there's a clear advantage to them.

That's one of the reasons I want maximum control over my software.

posted by: Kaj 3-May-2023/11:50:44-7:00

I spread part of my demo app across different urls, exactly to uncover issues such as what was discovered here. There's no inherent complexity or need to do that. It was simply a convenience in the moment to upload HTML to that server, and my server code up to my A2 Hosting account. I'm glad to learn a little bit more about Brave browser, my whole point in using that silly old JSlinb front end was to continue testing it and using it in every available browser that I can come across. I'll look at brave, and also check to see how that framework is sending requests, especially how brave browser deals with CORD, there's clearly a difference there. There's nothing in any of this tooling I don't have maximum control over. It just saves me lots of work, and allows me to connect to the largest number of existing pieces in the modern computing ecosystem via libraries and apis that are supported healthily in Python and JavaScript. Web apps are going to have a front end and a back end, there's no sort of outrageous complexity in that arrangement. I just like my back end to be powerful and connected to a massive ecosystem, so I don't have to reinvent the wheel for every task I want to complete. That's eventually what killed Rebol for me. I couldn't make use of all the modern services, apis, and other existing tooling that's just sitting there and waiting to do amazing things, without having to write an enormous amount of code to do make connections, to have to build apis from the ground up, and in many cases there wasn't even any real way for Rebol to nicely connect to many tools. The biggest benefit I get from working with Python and JavaScript.

By the way, Anvil does run python directly in the client side browser, using skulpt. That's one of the things that makes it so nice to use. There are no rest API calls, or conversions between data structures on the front end or back end. Your front end functions simply call back and functions, all in pure python, and all using python data structures.

posted by: Nick 3-May-2023/15:51:25-7:00

Of course, Anvil does give you full access to Javascript in the client - I've built a video recording app using native MediaStream API calls in Javascript, and controlled the recording stop/start etc. with Anvil UI, and saved the recorded video directly back to the server side in Anvil - it's absolutely brilliant how effective and trouble free is it to do things like that in Anvil. I've integrated the Coppercude 3D engine (a JS engine) directly into my Anvil front end - again all controlled with Anvil UI - it took me one sitting to do that - dead simple! Anvil makes it easy to interact with all those JS functions *directly in Python*. There's nothing else I've ever worked with that's so nice to use, productive, effective, and which eliminates problems and lets me actually get real work done, without having to get bogged down with time consuming 'gotchas'. I'm constantly amazed at how every 'just works', with everything I try to get done with it. My projects that used to take days/weeks in Rebol, are often a single afternoon in Anvil. It's hard for me to find fault with the kind of consistent, reliable solutions it enables.

posted by: Nick 3-May-2023/16:05:40-7:00

I originally was attracted to Streamlit because it's also a pure Python API, which actually goes a step further by removing the intellectual overhead of having to think about how data is transferred between front end and back end. Lots of people love it because the mental model is just so simple - building multi-user client-server apps feels like building single users apps that run locally - but its performance, lack of control, and other limitations make it pale dramatically in comparison Anvil's power, capability, and ease of use. It's just simple for non-developers to learn and use, and it really is practical for the data science community, because it natively integrates with Pandas and all the visualizations, as well as all the other machine learning, AI, etc. libraries.

The goal of my little toolkit is to provide the most productive connection with the full Python and JS ecosystems, using the lightest possible server, DB, and UI layers in those ecosystems, without having any heavy or complex dependencies.

posted by: Nick 3-May-2023/16:21:10-7:00

Skulpt is not really Python, it's a separate implementation. There are differences in the languages, mostly because it's incomplete. This means, for example, that you can not necessarily use all Python code in the browser.

Anvil effectively uses two different languages on the server and client sides, adding to its complexity, and needs to integrate them.

With Meta, you get the real thing everywhere, from Atari 2600 to the browser, and the same language on the client and the server.

posted by: Kaj 3-May-2023/17:06:57-7:00

They've used Skulpt to implement Python language and data structures for the purposes that are needed in the browser, and it works fantastically. It's limited to interacting with the objects that live in the front end UI, as it should be. You do front ends things in the front end, and back end things in the back end - (the back end is where the heavy lifting and all the ecosystem is available. The point isn't to make every bit of computing capable of being performed in the browser (that's the goal of pyscript - with many of the most common data science libraries ported to run entirely in the browser, and there's even an implementation of Streamlit which runs entirely in the browser - both of those projects are currently way to heavy to really useful in modern browsers, so they are silly now, but they could become more useful in the future). The benefit of Anvil's Python in the browser is that the language model and data structures are all the same as on the back end - you just call server functions on the front end - and it feels SO ergonomic and works beautifully (compared to any other mess in the web development landscape). Again, I can simply point to my *results* that have materialized from actually using Anvil, to demonstrate how effective it is. Anyone can be critical about something they don't like, but my productivity is through the roof, and I don't need to argue with anyone about how great it's been to use.

With all that said, I fully back your goals, without reservation. Less complexity, better performance, more portability, control at every level, etc., is of course better than the alternatives (that's why I'm hoping to trim down to the smallest possible requirements with my little Python toolkit). I'd like nothing more than to see Meta be successful, and it's exciting to know you've got financial support now. I just need to get work done, and writing software has only ever been *part of my professional life, so I just need to be utterly productive when I write any code... My tools are suiting my current needs better than I ever expected would be possible, after being previously spoiled by Rebol's productivity, lack of complexity, etc. I'm just happy to find some tools that tick all my boxes dramatically well. You have many more boxes to tick, and it's great to see that you're able to thrive making that happen. ... I still want Meta for my 198s Tandy Pocket computer:

http://pocket.free.fr/html/tandy/pc-2_e.html

I still have one of those! And check this out - these machines were what really lit the fire in me about computing:

https://antonaccio.net/mc10/IMG_20150816_084041.jpg
https://antonaccio.net/mc10/IMG_20150816_084053.jpg
https://antonaccio.net/mc10/IMG_20150816_090530.jpg
https://antonaccio.net/mc10/IMG_20150816_090430.jpg

posted by: Nick 3-May-2023/18:38:27-7:00

I followed with interest the discussion about Anvil, I played a bit with both the online application and the server installed on my computer. It seems interesting and promising, especially since it could be used for free (at least that's what I understood so far). I wonder if it is a long-term solution for the development of large applications. A few years from now, will there still be Anvil? Things change extremely quickly in the software world, all applications have dependencies and vulnerabilities, therefore they must be kept up to date. So, the local installation of Anvil would not save me from possible problems if those who develop it no longer take care of it.
I ask myself these questions because for many years I have been developing an ERP application written in VFP even more years ago. I was lucky that until now VFP has worked on Windows, although it is no longer supported. Over time, I implemented functionalities in the application using various other tools: curl, winscp, ruby, nodejs, etc., but the base remained VFP (I have not yet found something comparable, with the same functionalities)

posted by: iontab 4-May-2023/1:32:02-7:00

Iontab, I have the same doubts. And the higher the complexity, the larger the risks. In fact, all of society is now operating at a level of complexity that will be unsustainable in some societal crunch.

Cool pictures, Nick. I'm open to funding to target Tandy pocket computers with Meta; although TRS-80 should be easier. ;-)

posted by: Kaj 4-May-2023/4:17:50-7:00

Iontab,

... meanwhile, a huge portion of the world is *actually running* on Python and JS, doing trillions of dollars of business, and developing AI that is changing everything about the potential capabilities of mankind, using tools in those ecosystems. If Anvil goes away, it will be because something better will evolve to replace it in these massive communities of hundreds of millions of users working competitively, with massive financial backing in a tumultuous, explosive commercial environment that requires successful outcomes with the tools that are commonly used. It's not realistic to question whether Python and JS are viable in our current environment - they are far and away the most used languages. But with that said, I think all of the tools we use at the moment will most likely be replaced in the very near future, with infrastructures that will evolve quickly to support AI driven development. If you're not following how that has evolved during the past months, it's moving at light speed. ChatGPT is already better at writing code than many experienced professionals. We're just experiencing the first glimmer of light at the dawn of this new era for mankind, and burying heads in the sand about what's already occurring (50% increases in productivity at companies where AI is used to write code, already, at this moment, and that will change *dramatically in the next couple years). In a few years, everything we're discussing about how software development works will be eclipsed by AI driven methodologies. The age of software written primarily by humans is very quickly coming to an end. Humans are mostly going to be needed to guide, test, and evaluate the effectiveness of AI training output, for our needs, in the *very near* future. Not many disciplines or businesses are really safe from sweeping changes that will be made by AI automation in the coming decade.

posted by: Nick 4-May-2023/7:03:18-7:00

To be clear, Anvil is just the best tool that I've found, for my own requirements, to productively put to use and orchestrate the massive capabilities of existing and evolving libraries (video, 3D, machine learning, AI, etc.) and connectivity with established services (payment gateways, communications tools like Twilio, database services such as bit.io, machine learning environments such as hugging face, and AI apis such as those by OpenAI) and other tools that save developers the work of re-inventing the wheel for any given purpose, and enable the use of tools which no single develop can even begin to create in a lifetime. Replace Anvil with whatever toolkit makes more sense for your needs - Django has been around for nearly 2 decades - it's Python backend with web based front end that currently enables high level productivity. Anvil just does it in the most eloquent and productive way I've seen yet. But that productive advantage is very quickly being eclipsed by having AI write code - in whatever language you prefer. The paradigms and problems in software development are going through a massive transformation at the moment, and the next few years or going to rock the foundations of society.

posted by: Nick 4-May-2023/7:26:56-7:00

Kaj,

'the higher the complexity, the larger the risks' - that's 100% true - and we're all about to be bulldozed by a level of complexity that humans won't be able to keep up with.

posted by: Nick 4-May-2023/7:29:09-7:00

What I've been experiencing during the past few months with deep dives into using AI has been exhilarating and awesome, and the prospects are truly world changing and terrifying.

posted by: Nick 4-May-2023/7:31:25-7:00

AI is so much more dramatically capable than it was last year (particularly OpenAI's implementations), and particularly at generating, evaluating, explaining, connecting, reasoning about, teaching, debugging, transforming, etc. code. Working with it properly, you can currently multiply productivity manyfold. What I've been particularly impressed by is it's ability to write code that orchestrates the interaction of multiple disparate tools, in ways that most experienced human developers can - simply by entering prompts with the conceptual meaning that describes the intended outcome. The already existing ability to work that way is transformative in ways that are hard to communicate with anyone who isn't using it to complete work.

posted by: Nick 4-May-2023/7:41:06-7:00

Feed it error messages, and it explains what it happening to cause any errors, you can discuss with it the intended outcome, as you would with a human pair programmer, and it debugs your code and provides the working code you need - instantly. It can write 5000 lines of working code for you in a sitting. You can iterate with it, as you would with a human, ask it questions about how to accomplish whatever goal you sit down to achieve, and have it teach you exactly what you need to do to achieve your conceptual goal, while all the while writing and explaining every bit of actual working code you need to implement your intended outcome. You can ask for alternate solutions, and it will explain the options which had previously been unaware of, and provide working examples of their implementation, which you can then cycle through iterations and variations of. I'm learning to do months of work in days with it, and I wouldn't want to be using any tools/languages that it's not deeply trained in...

posted by: Nick 4-May-2023/7:49:15-7:00

It does hallucinate sometimes, and get things wrong, but dealing with that is far and away more productive than sitting down to a blank page and using Google to search for, learn about, assimilate, experiment, and iterate through writing code in traditional ways.

posted by: Nick 4-May-2023/7:53:11-7:00

Ignoring the use of AI tools at the moment, is probably the worst potential mistake any developer could currently make. That's clearly just an opinion, based on my own needs and perspective, but I expect that disagreement about that outlook is likely driven by lack of real experience using it. Here's 1 of hundreds of articles that may provide some genuine insight:

https://dev.to/wesen/llms-will-fundamentally-change-software-engineering-3oj8

posted by: Nick 4-May-2023/8:11:36-7:00

AI and many other things are not running on Python, that would be way too slow. Python is surfing on AI and other libraries, written in faster and safer languages.

Most other languages can also do that. Meta is suitable for both binding to other libraries and implementing the core libraries themselves.

Current AI is just regurgitating what it finds on the Internet written by humans, both good and bad examples. Of course it helps beginning and mid-level humans to be assisted by all other humans at once, but innovation still needs to be done by expert humans.

posted by: Kaj 4-May-2023/8:11:47-7:00

Nick,

My doubt is about the framework/tool, and not about the language (Python or JS or anything else). I said that I have been maintaining and developing a large application for many years, with tens of thousands of lines of code. If the tool I use in development disappears, it will be very painful for me. Even if the language used is all JS, for example, it is not easy to switch from React to VueJS when you have thousands of lines of code behind you.
I'm just trying to clarify my ideas and find viable long-term solutions, I have nothing against framework X or Y.
And yes, AI is already changing the rules of the game.

posted by: Iontab 4-May-2023/8:19:47-7:00

Kaj,

The human interfaces to those AI libraries is most often Python. I think everyone is aware that the hard work is done on a lower level. I'm interested in USING those capabilities, not dedicating my like to building one little microscopic piece of that environment.

If you don't respect my perspective, I think you may be interested in and surprised by the article I linked.

posted by: Nick 4-May-2023/8:26:08-7:00

I do respect your perspective, but there are definite limits to current AI.

If AI is as smart as you claim, I look forward to it, because it will start choosing Meta over Python in a few years. :-)

posted by: Kaj 4-May-2023/8:29:51-7:00

Iontab,

What's to stop you from learning a few frameworks? The Python/JS ecosystem is filled with great productive tools. Learn a mainstream Web framework for front end - take your pick from one of the most popular, use a popular backend such as Django or Flask, and an ORM. MUI or m3.material.io for front end, together with Flask and SQLAlchemy are good mainstream choices that can be mastered in a few months.

posted by: Nick 4-May-2023/8:34:25-7:00

archive.is/2023.03.08-154241/https://www.nytimes.com/2023/03/08/opinion/noam-chomsky-chatgpt-ai.html

posted by: Kaj 4-May-2023/8:35:27-7:00

You can replace any piece of the Anvil framework however and whenever you see fit. Use it just a back end REST and database system, and replace the front end with any toolkit that can make REST request. Swap out the ORM for any other database system. Or just use the visual layout builder to connect with any other back end. Anvil is just an integrated environment that enables you to use the Python and JS ecosystems effectively. It's a work environment with browser based IDE, GIT integration, slick back end and front end language integration all in Python, etc., but there's no inherent vendor lock-in. You can use it just to prototype and swap out any layer of the system when design is complete. Learning to use a different UI layor, or a different ORM, or a different IDE, etc, can be done piecemeal, and none of those layers require any sort of massive learning curve to become productive with. You can begin to be build powerfully useful front ends with metro in a few days - or maybe take a look at MDB - any framework that encapsulates all the UI componentry that is needed for front end work. Choose the one that satisfies your needs, use different frameworks for different projects. With a base in generic Python and web UI, there are endless options which can be learned and used as needed. For me Python and (name a front end web framework - or use a visual builder if that suits your needs), is the core that will stick around. Porting from Anvil, and swapping out any piece of it has been relatively easy - at least compared to previous tool systems. I just love the productivity and workflow enabled by the entire integrated browser based IDE (with autocomplete and GIT), all-python, built-in database, email, Google, Stripe, PDF printing, drawing API, and all the other out of the box integrations in Anvil, hosting, etc. But every one of those things can be swapped out to use any other option in the Python and JS ecosystems, without any vendor lock in, if any part of the Anvil system doesn't suit your needs or if it becomes obsolete.

posted by: Nick 4-May-2023/8:59:20-7:00

It's not the kind of lock-in that users of Rebol or Visual Fox Pro experienced. It's just Python and JS packaged nicely. There are endless existing alternative options to any piece of the Anvil environment, so the core of any work done in Anvil never needs to be abandoned.

posted by: Nick 4-May-2023/9:01:43-7:00

Kaj,

from the article:

"However useful these programs may be in some narrow domains (they can be helpful in computer programming, for example, or in suggesting rhymes for light verse)"

We're talking about the narrow domain of computer programming! I have a suspicion that Noam Chompsky hasn't spent the kind of time anyone reading this text may have, sitting to create a CRUD app for a client, to help run their business, and the dealt with the UX issues that come from supporting that software. I really doubt he's gone through the process of spending hours every day into deep in the night iterating though thousands of lines of code with ChatGTP, even to the degree I have. The link I posted is from a professional career developer who has written millions of lines of code over decade.

I agree with much of what Noam Chompsky wrote in that philosophical article, but I think the link I posted is filled with real usable and productive, actionable information related to actually writing software in a complex real life environment, in a way that is more directly relevant to what we're interested in as productive human software developers.

posted by: Nick 4-May-2023/9:17:02-7:00

Noam Chomsky is one of the founders of our field. I wouldn't accuse him of lack of experience.

If all parts of Anvil are so replacable, why not replace Python with Meta?

Is there anything that makes you think Meta won't be usable by AI?

posted by: Kaj 4-May-2023/10:45:31-7:00

In the article, Noam Chomsky was just addressing the topic of what AI currently isn't good at, and the value of human capability. He acknowledged that AI is good at writing code. I throw no shade at him whatsoever, just don't think he's likely grinding away at building CRUD apps, the same way most working commercial developers spend a huge portion of their career, and he most likely hasn't spent the last couple months using ChapGPT to write glue code and evaluate which combinations of frameworks are best used for the next project the marketing department needs completed by Friday. That's in no way an indictment of any lack of other experience.

I look forward to when I can replace Python with Meta. It's not an urgent need, but I would love to see that happen :)

There's nothing inherent in Meta that won't be usable by AI, it simply hasn't been trained in billions of lines of existing Meta code, the way it has been with Python, JS, C#, C++, SQL, etc.

posted by: Nick 4-May-2023/15:16:56-7:00

That's a matter of time, and since AI accelerates things, it could happen quite fast. At least AI doesn't have the strong inertia of humans.

The article you linked is quite useful, and confirms some of my hunches from reading up on generative AI the last few months.

It seems to me that Meta both competes with generative AI and can facilitate it. The programmers who are enthusiastic about AI use it to make it generate lots of code based on a mere few hints. In REBOL, we have had that for a quarter century and call it a dialect. But where the execution of a dialect is automatic and deterministic, all code generated by AI needs to be checked by an expert human at every generation cycle. Further, the least complex way to execute a dialect is to interpret it. Generating other code from it is a huge complexity bomb. Meta only does it to 100-fold performance.

Another oddity is that everyone makes AI generate programs in existing languages, which are created by humans. Noone makes it generate machine code, so AI is still heavily dependent on human creations. That being the case, Meta can infer the same advantages on AI as it can on human programmers. All of Meta's advantages apply to AI, as well.

posted by: Kaj 4-May-2023/16:07:24-7:00

Yep, it's interesting that I haven't seen anyone talk about generating machine code.

It's funny, I was originally attracted to Rebol because I was searching for work that had been done on converting natural language to working code.

There are a chasm of differences between working with dialects and using AI. The biggest is that you can interact with AI iteratively, asking it to demonstrate potential solutions, ask it to perform variations, request help in complex conceptual ways, and learn from it while guiding it to teach you about what to search for. You can begin a project, for example, by asking it to outline some suggested approaches to complete the project. You could then, for example, ask it to suggest any libraries which can help accomplish some part of a task, and if one sounds interesting, ask it to generate some code, using that library to perform a particular task, ask it to explain any piece of the code, ask it for alternative ways to complete the same task, write some come from what you've learning, ask it to debug and improve your code, and deal with it as if you have an all-knowing pair programming partner who knows more about everything in an any ecosystem than any single person could ever learn in a lifetime, and provide suggestions which aren't colored by a single person's limited ability to learn about and use just a limited number of favorite tools.

It does most of those sorts of things instantly, and already better than most experienced professional can.

posted by: Nick 4-May-2023/21:37:53-7:00

You could train an open source project such a Llama to learn Meta.

posted by: Nick 4-May-2023/21:40:15-7:00

Your first 5 minutes with ChatGPT:


Why is this Rebol code not working:


random/seed now g: [style t box red [
    if not find [0x108 108x0 0x-108 -108x0] face/offset - e/offset [exit]
    x: face/offset face/offset: ef/offset e/offset: x
] across] x: random repeat i 15 [append x:[] i] repeat i 15 [
    repend g ['t mold x/:i random white] if find[4 8 12] i [append g 'return]
] append g [e: box] view layout g


ChatGPT

The code you provided has a syntax error in the second line. ef/offset should be e/offset. Here's the corrected code:


random/seed now
g: [style t box red [
    if not find [0x108 108x0 0x-108 -108x0] face/offset - e/offset [exit]
    x: face/offset face/offset: e/offset e/offset: x
] across]
x: random repeat i 15 [append x:[] i]
repeat i 15 [
    repend g ['t mold x/:i random white]
    if find [4 8 12] i [append g 'return]
]
append g [e: box]
view layout g


This code generates a grid of 15x15 colored boxes, which change position when clicked. The g variable is a block of GUI objects that define the grid layout, while the x variable is a block of numbers used to determine the initial color of each box.

The random/seed now line sets the seed for the random number generator, ensuring that the same sequence of random numbers is generated each time the script is run. The style function defines a style for the boxes, which are instances of the box function. The repeat and repend functions are used to fill in the initial colors of the boxes, while the if statement checks whether the box has been moved to a valid position.

Finally, the append function adds a box to the end of the g block, and the view function displays the grid as a graphical user interface.






Please generate the pydal code to create an sqlite database with a 1 table, with columns "name" and "birthday". Create a function to insert new rows, and a function to search for rows containing a given name.


ChatGPT

Sure, here's the PyDAL code to create an SQLite database with a single table named "people", with columns "name" and "birthday":

from datetime import datetime
from pydal import DAL, Field

db = DAL('sqlite://mydatabase.db')

db.define_table('people',
                 Field('name', 'string'),
                 Field('birthday', 'date'))

To insert new rows into the "people" table, you can create a function like this:

def add_person(name, birthday):
     db.people.insert(name=name, birthday=birthday)

This function takes two arguments, the name and birthday of the person to be added, and inserts a new row into the "people" table.

To search for rows containing a given name, you can create a function like this:

def search_by_name(name):
     results = db(db.people.name.contains(name)).select()
     return results

This function takes a name argument and searches the "people" table for rows containing that name using the contains() method. It then returns the results as a Rows object, which you can iterate over to access individual rows.

Note that you'll need to adjust the SQLite connection string to reflect the path and filename of your SQLite database file. Also, make sure to import the datetime module if you want to use the date field type in your table.





User

Please integrate that code into Python Bottle, so that the add_person() and search_by_name() functions run at routes of the same name


ChatGPT

Certainly! Here's an example of how you can integrate the PyDAL code I provided earlier into a Python Bottle web application:

from bottle import Bottle, request
from datetime import datetime
from pydal import DAL, Field

# Create a new Bottle app
app = Bottle()

# Connect to the SQLite database using PyDAL
db = DAL('sqlite://mydatabase.db')

# Define a "people" table with "name" and "birthday" columns
db.define_table('people',
                 Field('name', 'string'),
                 Field('birthday', 'date'))

# Define a route for adding a new person to the database
@app.route('/add_person', method='POST')
def add_person():
     name = request.forms.get('name')
     birthday = datetime.strptime(request.forms.get('birthday'), '%Y-%m-%d').date()
     db.people.insert(name=name, birthday=birthday)
     return f"Added {name} with birthday {birthday}"

# Define a route for searching for people by name
@app.route('/search_by_name', method='GET')
def search_by_name():
     name = request.query.name
     results = db(db.people.name.contains(name)).select()
     return f"Results: {results}"

# Run the app on port 8080
app.run(host='localhost', port=8080)

In this example, we're using the Bottle web framework to define two routes for adding new people to the database (/add_person) and searching for people by name (/search_by_name). Both routes call the add_person() and search_by_name() functions that we defined earlier, passing in the request data (in the case of /add_person) or the query parameter (in the case of /search_by_name).

Note that we're using the strptime() method from the datetime module to convert the birthday string from the request data into a date object that can be stored in the database.

Also, make sure to adjust the SQLite connection string to reflect the path and filename of your SQLite database file. And don't forget to import the bottle module at the beginning of your script.





I'd like to make the bottle server restart every time the source file is edited


ChatGPT

To make the Bottle server restart every time the source file is edited, you can use a Python package called watchdog.

Here's an example of how you can modify the previous code to use watchdog:

python
Copy code
from bottle import Bottle, request
from datetime import datetime
from pydal import DAL, Field
from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler
import os

# Create a new Bottle app
app = Bottle()

# Connect to the SQLite database using PyDAL
db = DAL('sqlite://mydatabase.db')

# Define a "people" table with "name" and "birthday" columns
db.define_table('people',
                 Field('name', 'string'),
                 Field('birthday', 'date'))

# Define a route for adding a new person to the database
@app.route('/add_person', method='POST')
def add_person():
     name = request.forms.get('name')
     birthday = datetime.strptime(request.forms.get('birthday'), '%Y-%m-%d').date()
     db.people.insert(name=name, birthday=birthday)
     return f"Added {name} with birthday {birthday}"

# Define a route for searching for people by name
@app.route('/search_by_name', method='GET')
def search_by_name():
     name = request.query.name
     results = db(db.people.name.contains(name)).select()
     return f"Results: {results}"

# Define a watchdog event handler to restart the server when the source file is modified
class WatchdogHandler(FileSystemEventHandler):
     def on_modified(self, event):
         if event.src_path == os.path.abspath(__file__):
             print("Restarting server...")
             observer.stop()
             observer.join()
             os.execv(__file__, sys.argv)

# Set up a watchdog observer to monitor the source file for changes
event_handler = WatchdogHandler()
observer = Observer()
observer.schedule(event_handler, path='.', recursive=False)
observer.start()

# Run the app on port 8080
app.run(host='localhost', port=8080)
In this modified code, we're using the watchdog package to monitor the source file for changes. We define a WatchdogHandler class that subclasses FileSystemEventHandler and overrides the on_modified() method to restart the server when the source file is modified. We create an instance of this class and use it to set up a watchdog observer that monitors the current directory for changes.

When the source file is modified, the on_modified() method of the WatchdogHandler class is called, and if the modified file is the source file itself (__file__), the observer is stopped and joined, and the server is restarted using the os.execv() method.

Note that this code assumes that the source file is located in the current directory ('.'). If your source file is located in a different directory, you'll need to adjust the path argument of the observer.schedule() method accordingly.






is there an easier way to achieve that?



ChatGPT

Yes, there is an easier way to achieve auto-reloading of the Bottle server when the source code is edited, without using watchdog.

You can use the reloader=True option when calling the run() method of your Bottle app, like this:

from bottle import Bottle, request
from datetime import datetime
from pydal import DAL, Field

# Create a new Bottle app
app = Bottle()

# Connect to the SQLite database using PyDAL
db = DAL('sqlite://mydatabase.db')

# Define a "people" table with "name" and "birthday" columns
db.define_table('people',
                 Field('name', 'string'),
                 Field('birthday', 'date'))

# Define a route for adding a new person to the database
@app.route('/add_person', method='POST')
def add_person():
     name = request.forms.get('name')
     birthday = datetime.strptime(request.forms.get('birthday'), '%Y-%m-%d').date()
     db.people.insert(name=name, birthday=birthday)
     return f"Added {name} with birthday {birthday}"

# Define a route for searching for people by name
@app.route('/search_by_name', method='GET')
def search_by_name():
     name = request.query.name
     results = db(db.people.name.contains(name)).select()
     return f"Results: {results}"

# Run the app on port 8080, with auto-reloading enabled

if __name__ == '__main__':
     app.run(host='localhost', port=8080, reloader=True)

When you run this code using the Python interpreter (python app.py), the Bottle server will start on port 8080, with auto-reloading enabled. This means that the server will automatically restart every time you modify the source code.

Note that you should only use the reloader=True option during development, as it can have performance implications in production environments. Also, make sure that you only call the run() method when the script is executed directly (i.e., if __name__ == '__main__':), to avoid starting the server multiple times in a single script.








Please convert this example to run in Flask:

from bottle import Bottle, request
from datetime import datetime
from pydal import DAL, Field
from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler
import os

# Create a new Bottle app
app = Bottle()

# Connect to the SQLite database using PyDAL
db = DAL('sqlite://mydatabase.db')

# Define a "people" table with "name" and "birthday" columns
db.define_table('people',
                 Field('name', 'string'),
                 Field('birthday', 'date'))

# Define a route for adding a new person to the database
@app.route('/add_person', method='POST')
def add_person():
     name = request.forms.get('name')
     birthday = datetime.strptime(request.forms.get('birthday'), '%Y-%m-%d').date()
     db.people.insert(name=name, birthday=birthday)
     return f"Added {name} with birthday {birthday}"

# Define a route for searching for people by name
@app.route('/search_by_name', method='GET')
def search_by_name():
     name = request.query.name
     results = db(db.people.name.contains(name)).select()
     return f"Results: {results}"

# Define a watchdog event handler to restart the server when the source file is modified
class WatchdogHandler(FileSystemEventHandler):
     def on_modified(self, event):
         if event.src_path == os.path.abspath(__file__):
             print("Restarting server...")
             observer.stop()
             observer.join()
             os.execv(__file__, sys.argv)

# Set up a watchdog observer to monitor the source file for changes
event_handler = WatchdogHandler()
observer = Observer()
observer.schedule(event_handler, path='.', recursive=False)
observer.start()

# Run the app on port 8080
app.run(host='localhost', port=8080)






ChatGPT

Sure, here's the equivalent Flask code:

from flask import Flask, request
from datetime import datetime
from pydal import DAL, Field
from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler
import os

# Create a new Flask app
app = Flask(__name__)

# Connect to the SQLite database using PyDAL
db = DAL('sqlite://mydatabase.db')

# Define a "people" table with "name" and "birthday" columns
db.define_table('people',
                 Field('name', 'string'),
                 Field('birthday', 'date'))

# Define a route for adding a new person to the database
@app.route('/add_person', methods=['POST'])
def add_person():
     name = request.form.get('name')
     birthday = datetime.strptime(request.form.get('birthday'), '%Y-%m-%d').date()
     db.people.insert(name=name, birthday=birthday)
     return f"Added {name} with birthday {birthday}"

# Define a route for searching for people by name
@app.route('/search_by_name', methods=['GET'])
def search_by_name():
     name = request.args.get('name')
     results = db(db.people.name.contains(name)).select()
     return f"Results: {results}"

# Define a watchdog event handler to restart the server when the source file is modified
class WatchdogHandler(FileSystemEventHandler):
     def on_modified(self, event):
         if event.src_path == os.path.abspath(__file__):
             print("Restarting server...")
             observer.stop()
             observer.join()
             os.execv(__file__, sys.argv)

# Set up a watchdog observer to monitor the source file for changes
event_handler = WatchdogHandler()
observer = Observer()
observer.schedule(event_handler, path='.', recursive=False)
observer.start()

# Run the app on port 8080
if __name__ == '__main__':
     app.run(host='localhost', port=8080, debug=True)

The Flask version of the code is almost identical to the Bottle version, with a few minor differences in syntax and naming conventions. For example, Flask uses Flask instead of Bottle to create a new app instance, and the route() decorator takes a methods argument instead of a method argument. Additionally, Flask uses request.form.get() instead of request.forms.get() to access form data in POST requests, and request.args.get() instead of request.query.get() to access query parameters in GET requests.

Note that you should only call the run() method when the script is executed directly (i.e., if __name__ == '__main__':), to avoid starting the server multiple times in a single script.





Please suggest and alternative to using pydal, which can connect to oracle


ChatGPT

An alternative to PyDAL for connecting to Oracle databases is the cx_Oracle library, which is a Python extension module that enables access to Oracle databases. cx_Oracle provides a Python DB API 2.0-compliant interface for connecting to Oracle databases and executing SQL statements.

Here's an example of how to use cx_Oracle to connect to an Oracle database, create a table, and insert data into it:

python
Copy code
import cx_Oracle

# Connect to the Oracle database
dsn = cx_Oracle.makedsn('hostname', port, service_name='service_name')
conn = cx_Oracle.connect(user='username', password='password', dsn=dsn)

# Create a new table
cur = conn.cursor()
cur.execute("CREATE TABLE people (name VARCHAR2(50), birthday DATE)")

# Insert data into the table
cur.execute("INSERT INTO people (name, birthday) VALUES (:name, :birthday)",
             {'name': 'John Smith', 'birthday': '1980-01-01'})

# Commit the changes
conn.commit()

# Close the connection
conn.close()
In this example, we first create a connection to the Oracle database using cx_Oracle.connect(), passing in the necessary connection parameters such as the hostname, port, service name, username, and password. We then create a new table using cur.execute(), which creates a cursor and executes the SQL statement. We insert data into the table using a parameterized SQL statement, which helps prevent SQL injection attacks. Finally, we commit the changes and close the connection using conn.commit() and conn.close().

cx_Oracle provides many other features and options for working with Oracle databases, such as support for PL/SQL procedures, query optimization, and error handling. You can find more information about cx_Oracle in the official documentation: https://cx-oracle.readthedocs.io/en/latest/index.html





Please recommend some additional ORM instead, which can connect to oracle, mysql, and postgres


ChatGPT

One popular ORM that can connect to Oracle, MySQL, and PostgreSQL is SQLAlchemy. SQLAlchemy is a Python library that provides a set of high-level tools for working with relational databases, including a SQL expression language, an object-relational mapper (ORM), and support for multiple database backends.

Here's an example of how to use SQLAlchemy to connect to a MySQL database, create a table, and insert data into it:

from sqlalchemy import create_engine, Column, Integer, String, Date
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm import sessionmaker
from datetime import date

# Connect to the MySQL database
engine = create_engine('mysql+mysqldb://username:password@hostname:port/database')
Session = sessionmaker(bind=engine)
Base = declarative_base()

# Define a "Person" table using SQLAlchemy's declarative syntax
class Person(Base):
     __tablename__ = 'people'
     id = Column(Integer, primary_key=True)
     name = Column(String(50))
     birthday = Column(Date)

# Create the "Person" table in the database
Base.metadata.create_all(engine)

# Insert data into the "Person" table using a session
session = Session()
person = Person(name='John Smith', birthday=date(1980, 1, 1))
session.add(person)
session.commit()

# Close the session
session.close()
In this example, we first create an engine object using create_engine(), passing in the necessary connection parameters for the MySQL database. We then define a Person class using SQLAlchemy's declarative syntax, which maps to the people table in the database. We create the table in the database using Base.metadata.create_all(). We insert data into the table using a session object, which we create using Session(). Finally, we commit the changes and close the session using session.commit() and session.close().

To connect to an Oracle or PostgreSQL database, you can simply change the connection string in create_engine() to use the appropriate database backend. SQLAlchemy provides a consistent API for working with different database backends, so you can use the same code to interact with multiple databases.

You can find more information about SQLAlchemy in the official documentation: https://docs.sqlalchemy.org/en/14/







Please convert the final pydal and bottle example above to use sqlalchemy instead of pydal


ChatGPT

Sure, here's the updated code that uses SQLAlchemy instead of PyDAL:

python
Copy code
from flask import Flask, request
from datetime import datetime
from sqlalchemy import create_engine, Column, Integer, String, Date
from sqlalchemy.orm import sessionmaker
from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler
import os

# Create a new Flask app
app = Flask(__name__)

# Connect to the SQLite database using SQLAlchemy
engine = create_engine('sqlite:///mydatabase.db')
Session = sessionmaker(bind=engine)

# Define a "Person" table using SQLAlchemy's declarative syntax
class Person(Base):
     __tablename__ = 'people'
     id = Column(Integer, primary_key=True)
     name = Column(String(50))
     birthday = Column(Date)

# Create the "Person" table in the database
Base.metadata.create_all(engine)

# Define a route for adding a new person to the database
@app.route('/add_person', methods=['POST'])
def add_person():
     session = Session()
     name = request.form.get('name')
     birthday = datetime.strptime(request.form.get('birthday'), '%Y-%m-%d').date()
     person = Person(name=name, birthday=birthday)
     session.add(person)
     session.commit()
     session.close()
     return f"Added {name} with birthday {birthday}"

# Define a route for searching for people by name
@app.route('/search_by_name', methods=['GET'])
def search_by_name():
     session = Session()
     name = request.args.get('name')
     results = session.query(Person).filter(Person.name.contains(name)).all()
     session.close()
     return f"Results: {results}"

# Define a watchdog event handler to restart the server when the source file is modified
class WatchdogHandler(FileSystemEventHandler):
     def on_modified(self, event):
         if event.src_path == os.path.abspath(__file__):
             print("Restarting server...")
             observer.stop()
             observer.join()
             os.execv(__file__, sys.argv)

# Set up a watchdog observer to monitor the source file for changes
event_handler = WatchdogHandler()
observer = Observer()
observer.schedule(event_handler, path='.', recursive=False)
observer.start()

# Run the app on port 8080
if __name__ == '__main__':
     app.run(host='localhost', port=8080, debug=True)

In this updated code, we first create an SQLAlchemy engine using create_engine(), passing in the appropriate connection string for the SQLite database. We then define a Person class using SQLAlchemy's declarative syntax, which maps to the people table in the database. We create the table in the database using Base.metadata.create_all(). We insert data into the table using an SQLAlchemy session object, which we create using Session(). Finally, we query the data from the table using session.query(), and filter the results using filter().

Note that we have to define Base and metadata before defining the Person class, as SQLAlchemy requires this to work properly. Also, we have to change the syntax of the filter() call to match SQLAlchemy's syntax.








Of course those are baby steps - it's MUCH more capable.

posted by: Nick 4-May-2023/22:57:22-7:00

Kaj,

Maybe take a look at this:

https://www.businesswire.com/news/home/20230504005419/en/ServiceNow-and-Hugging-Face-release-StarCoder-one-of-the-world%E2%80%99s-most-responsibly-developed-and-strongest-performing-open-access-large-language-model-for-code-generation

posted by: Nick 5-May-2023/0:15:23-7:00

Thanks for the link.

Your example session is both impressive and awkward. Many of those queries would not be needed if there weren't so much sprawl in modern software and documentation. In that sense, generative AI is just the next step to keep heads just above water while exploding the mess further, instead of cleaning it up.

That said, REBOL was successful as a clean platform, but then failed because it refused in many ways to collaborate with other, upcoming forces. Meta is designed to collaborate just like, or even more than other languages, while shrinking the mess.

posted by: Kaj 5-May-2023/7:39:17-7:00

I imagine that using AI to generate machine language will likely be more common in the future. As it can easily explain any code, generate test suites, instantly port code between platforms, etc., there's not the same need for the intermediate step of using any human readable language.

posted by: Nick 5-May-2023/7:48:48-7:00

I don't think so. The human-readable level is essential, because AI functions as a pair programmer. It's both all-knowing and not-understanding, so it's essential that it works together with a human.

I don't see any reason why competition for the most human-readable and efficient language would stop.

It's similar to REBOL/Meta as a data format. Even if you need to communicate with other systems in other formats, you still need internal data formats for your programs, and REBOL is the most effective, while Meta will also make it the most efficient.

posted by: Kaj 5-May-2023/7:55:56-7:00

Last year, GPT made news because it was able to pass the SAT and the Bar exams - but only in the 10th percentile. *Now it can pass those exams consistently in the 90th percentile. Next year it will be able to best any human taking the tests. Add such rapidly improving AI to robots that can walk and perform the same fine motor skills as humans, and we have a fast-changing environment for humans. One of the potential problems with the astoundingly quick improvement of AI capabilities is that in the near future, human work will be devalued in virtually *every discipline, to the point that the economic foundations of our civilization evaporate. When computers can perform most useful tasks better, faster, and cheaper than humans, members of human society will no longer be paid to do that work. How does a capitalistic society survive when the overwhelming majority of members can't do work that is valuable to others?

And of course there's the fact that a portion of human will always be evil. How do we oversee AI so that some rich person who hates American values, for example, doesn't build and deploy 10 million trained killer drones with guns with the instructions 'kill everyone in America'. That sort of production can't be overseen in the same way that nukes can.

Of course, maybe this development will lead to utopia, and everyone will just be so happy with a work-free environment filled with amazing joys, that we'll all finally just be nice to one another :) ... I'm less than optimistic that that will be the end result :(

posted by: Nick 5-May-2023/8:09:05-7:00

As long as it is adamant that RANDOM/SEED NOW serves to generate a fixed random series, I am not convinced.

In my youth, many articles claimed that the big problem of the future was exactly that: that we would be automated away and out of work. Now, in the real future, we are inundated with work created by computers. AI is going to explode that and claim any fragment of free time we have left.

posted by: Kaj 5-May-2023/8:22:16-7:00

In response to acting as a pair-programmer, the big difference with AI is that the need for human understanding can be replaced by an infrastructure of tools that evaluate, test, and explain generated machine code - any other workflows that have been utterly unimaginable until now. The bigger difference is that such a system can be made usable by humans who have absolutely no training whatsoever - basically everyone.

We have to face that job disruption from AI will be tremendous, and that new forms of societal structure will evolve, from these current blazing fast developments. I agree with Sundar Pichai that AI is "more profound than fire or electricity or anything that we�ve done in the past".

posted by: Nick 5-May-2023/8:22:32-7:00

Wishful thinking, Sundar has a lot of money riding on that wish. Beam him back to before fire and he will reconsider.

As Noam Chomsky says, current AI is not capable of that.

posted by: Kaj 5-May-2023/8:31:37-7:00

I think this essay by Bill Gates is an informative and balanced overview of the current and potential future state of AI:

https://www.weforum.org/agenda/2023/03/heres-what-the-age-of-ai-means-for-the-world-according-to-bill-gates/

posted by: Nick 5-May-2023/8:38:31-7:00

I stopped listening to Bill a long time ago. The only way his wishful futures come true is if he can get the majority to follow him. I prefer different futures.

posted by: Kaj 5-May-2023/8:42:02-7:00

As much as Noam Chomsky may have influenced the creation of computer programming language structure, I think the expert opinion of the likes of Bill Gates, Sundar Pachai, and much more importantly, people such as Geoffrey Hinton hold a bit more water about the current state of AI. Here's a relevant article by the New York Times:

https://www.nytimes.com/2023/05/01/technology/ai-google-chatbot-engineer-quits-hinton.html

posted by: Nick 5-May-2023/8:44:09-7:00

Right, Hinton is one of the considerable number of scientists warning against current AI, so taking it with a grain of salt is the least you can do.

While it's true that generative AI is the revenge of Clippy, you always have to remember that Bill's assessment of the here and now as its greatest expert is that Windows has zero bugs, and his prediction of the future is that 640 KB ought to be enough for everyone.

posted by: Kaj 5-May-2023/8:50:39-7:00

Discounting the disruptive potential of AI feels similar to the Rebol community insisting that getting Rebol running on mobile platforms in 2007 was not of any interest. But that comparison is trivial. Head in the sand about AI eliminating the software development industry as it currently exists is similar the horse industry insisting that it would continue to exist alongside the auto industry as a primary mode of transportation in the early 1900s. We're about to see the tech industry paved over by AI.

posted by: Nick 5-May-2023/8:54:52-7:00

Clearly, I'm not saying I like the fact that that's happening - it's clear that this development is going to have tremendously bad side effects. It's just going to be hard to beat, in the same way that the freakin iPhone was the model that so many humans chose to use, and how that disrupted the industry. Humanity makes bad choices.

posted by: Nick 5-May-2023/8:58:33-7:00

It's not that black and white. I'm not at all discounting the disruptive potential of AI. But there are many sides to it, and one is that it's just the next in a long series of disruptive changes, which basically always turn out differently than expected.

posted by: Kaj 5-May-2023/9:00:09-7:00

With that said, I think that developments like Meta ARE positive forces that can improve our condition. When society burns itself down, humans may potentially go back to riding horses - and maybe then we'll learn to build back our world in more reasonable and sustainable ways... if we survive.

posted by: Nick 5-May-2023/9:01:30-7:00

I hope that the Meta horse can survive this crazy race :)

posted by: Nick 5-May-2023/9:02:49-7:00

I'm well prepared. I master fire and electricity and can ride a horse. I make my own water and my own programming language. Meta is developed on solar power. We'll see.

posted by: Kaj 5-May-2023/9:09:31-7:00

Do your thing man, I'm watching hopefully :)

posted by: Nick 5-May-2023/9:13:07-7:00

Perhaps fine tuning an LLM to work with Meta provides the opportunity for a competitive marketing message, even if you consider it a counterproductive gimmick:

https://thenewstack.io/why-open-source-developers-are-using-llama-metas-ai-model/

posted by: Nick 5-May-2023/10:07:59-7:00

Thanks.

posted by: Kaj 5-May-2023/11:25:41-7:00

https://analyticsindiamag.com/uc-berkeley-release-an-open-source-alternative-to-metas-llama/

posted by: Nick 5-May-2023/14:26:06-7:00

https://analyticsindiamag.com/14-open-source-llms-you-need-to-know/

posted by: Nick 5-May-2023/14:31:09-7:00

Sprawl and information overload already, but thanks. :-S

posted by: Kaj 5-May-2023/16:14:01-7:00

Best thing to remember is GIGO, Garbage In -> Garbage Out. The more stuff you throw in, the more low quality stuff there is included. Like the crowd growing dumber when it is growing bigger, otoh predictions of sportsmatches made by many people tend to be pretty decent LoL!
But what I wanted to point out, the way to fight GPT's is to create many bogey repos.

posted by: Arnold 7-May-2023/17:25:29-7:00

AI ranks stuff by popularity. If popularity converges towards quality over time, AI will converge to Meta. :-)

posted by: Kaj 8-May-2023/7:29:40-7:00

Popularity ordinarily does not seem to behave in any logical sense

posted by: Arnold 8-May-2023/16:34:29-7:00

Arnold,

That's obviously true. Many of the world's inhabitants think Eric Clapton is the best guitarist who ever lived :)

Still, there are benefits to working with systems that have been fully evolved, tested, and used by popularly by 10s of millions of people, so that they work productively, stably, and reliably in our modern world. Python and Anvil, as I've worked with them, for example, is far more stable and usable towards the productive ends I require, than Rebol ever was. If I wanted to go to extremes, I could choose to say, well computers just aren't naturally necessary, and they require a level of complexity that is not required for healthy human survival, and happy existence - so maybe it's better to just eliminate that complexity altogether and just farm land and write on stone tablets, and electronics and computers are just pointless trappings of stupid modern popular trends in society, technology, etc.

Or maybe it would be great if we could restructure society so that all of our work could be done in cities which require only bicycles to travel, and solar power ... but wait, then how would we mine/distribute the metal and materials needed to build bicycles and solar panels.

The world is obviously a massively complex mess, and most humans are impossibly stupid. But there are truly great and valuable achievements that arise out of all the chaos driven by stupid popular trends. Navigating intelligent and productive channels through existing messy infrastructure is a huge challenge, but I don't think disregarding every bit of good work that exists within every messy ecosystem is the best way to live, at least with the constraints and values that exist in my life, to find a positive outcome and thoroughly satisfying path. There are jewels that get formed in the pressure of those enormously messy pressurized ecosystems, and incredibly intelligent people working in every environment.

I'm very happy with the architecture of my current life, including the tech tools that I use, to be massively productive and successful at achieving the goals that are important to me - which include doing all the things I like, and having the time and resources that I need to enable the lifestyle that's most satisfying to me. I'm not willing to give all that up to materialize a pure technical computing vision that is outside the scope of what I can achieve. I respect Kaj for his ability to maintain that focus and to work realistically toward that vision, but I always continue to explore and embrace the amazingly engineered and productively useful gems of technology that exist in any ecosystem.

posted by: Nick 9-May-2023/10:49:45-7:00

For many years, Rebol was the best embodiment of a tool I could find which satisfied my productivity end goals, but coming from that experience, that's no longer the case.

posted by: Nick 9-May-2023/10:53:37-7:00

I don't have the skills, background, time, or opportunity to change the underpinnings of how the future ecology of all computing, programming languages, etc., might potentially be able to improve, in terms of eliminating complexity, the way Carl had hoped to accomplish, and the way Kaj still does hope to accomplish.

I do have 40+ years of using computing platforms and hundreds of software development tools in many ecosystems - Rebol included (and of course previously favored).

What I *can say for sure, for example, is that I could build a replacement for this forum software in a matter of minutes, instead of hours or days, and with far greater facility, convenience during each step of development and deployment, and the ability to include a massive array additional useful features, in a way that would look and function better, and be more secure, etc. on 99% of the devices, for 99% of the users that would ever want to use such an app, and with the ability to scale traffic to 100s of millions of users, with either just a few hours work or a trivial amount of money (compared to that sort of scaled use case).

That wasn't true before Rebol, but it is now, with Anvil. And the truth is, it would likely be far more stable in production than anything that existing in Rebol's life, particularly it has been tested and used in environments in which millions or uneducated users do everything possible to break it. The massive use and adoption of popular tools, as complex as they are under the hood, leads to far less complexity during every step of development, deployment, maintenance and support, for me the developer.

posted by: Nick 9-May-2023/11:27:53-7:00

The idea that those systems are somehow otherwise unruly or prone to come crashing down just isn't the reality I live in.

posted by: Name 9-May-2023/11:30:02-7:00

A common thought I've been hoping to communicate in this thread is that the tools I've been using are just the opposite: beautifully engineered, tested, reliable, pleasant to use, productive, massively capable in simple ways I had hoped Rebol would have eventually come to embody. These aren't hopes, they're my current reality.

posted by: Nick 9-May-2023/11:33:01-7:00

It's not about compexity itself, it's about essential versus accidental complexity, and identifying accidental complexity as the waste it is:
language.metaproject.frl#muda

It's not a purely technical vision, it's very much a vision about society and its future, but it's about technology, so instead of just philosophising, there needs to be a technical vision to achieve anything.

posted by: Kaj 9-May-2023/11:38:34-7:00

In all of history, it has always been the case that the dominance of an incumbent doesn't matter in the long run. What defines the outcome are relative growth rates. Meta's goal is not to be bigger than Python and Anvil, but to grow faster.

posted by: Kaj 9-May-2023/11:47:39-7:00

In all of history, entire infrastructure systems, communities, and their surrounding ecosystems have tended to be replaced by evolving generations of community who use completely new tech/ecosystems. Getting stuck trying to perfect the early steam engine wasn't the path toward our current level of technological evolution. I see our current technological state as just a moment along an eventual future evolutionary path, and I don't expect the historical approach to computer system architecture, programming language design or related tools will play as important a part of that future technology. Trying to perfect old approaches *could* potentially end up being an exercise in futility, as entirely new, more efficient, and more powerful generations of technology are devised, built, and perfected by armies of imperfect scientists, developers, business people, etc., all using the imperfect tools and technologies of today to build the new classes of future tools.

Python and JS are both *currently bigger, and growing faster than Meta (by an outrageous, incomparable degree). I'd love to see that change - of course I do see and embrace the benefit of such an improvement to the foundations upon which future tech will be built (and I encourage and would like to support that end goal) - but until there's a convincing reason to *use some other tech tools for my own work that leads to future benefit in the natural world encompassed by my sphere of influence, it's impossible to make such a switch in my own production tooling - and expect there are many people like me, who are searching desperately for such useful tools to use right now. The Python and JS tools I currently use are not failing in any way, they're not too slow for any of my users, or characterized as anything but an absolute pleasure to use. They're productive, stable, secure powerhouses - plus, they *enable the initial ability to take part in using of all the most cutting edge implementations of new technology tools which are paving the way to better, totally ground-breaking generations of entirely new tech (currently AI).

If/when something comes along that can improve that situation, then that's fantastic, but my interests are not affected by *potential problems and improvements that don't require solutions in my scope of life. I don't experience any downside from the troubles that are magnified in the experiences of a system engineer. I'm not a system engineer - I'm a tech user and an entrepreneur (who prefers to use better and more powerful/malleable tech than the overwhelming majority of humanity limits itself to using). My experience *would be significantly disabled by having to give up all the connectivity with new tools, community and commercial support and established infrastructure, vast seas of libraries that save work, etc., which are enabled in the Python and JS ecosystems, and particularly with the extraordinarily productive tools within those ecosystems that I've searched out and which I currently use.

I deeply appreciate the work of every system engineer, scientist, etc. who has created a piece of any tool that I currently use, but I'm not currently a person who has the opportunity to work at solving those sorts of problems. I just think there are many more people like me, who could use the class of tools that I currently advocate.

posted by: Nick 9-May-2023/16:02:19-7:00

REBOL as a language design is not a steam engine. Perhaps its implementation is, hence why Meta has a completely different implementation.

By the way, Pyhon has much the same implementation as REBOL. I consider both its language design and implementation outdated.

Your statements about the relative growth rates of Meta and Python are baseless: you have don't have any information about Meta's growth rate.

I'm not sure why you keep telling us that you are not motivated to spend an effort on Meta. This is not asked of you, I and others are doing it. Obviously, any project including Meta is not meant for people who vehemently don't want to use it, it's meant for people who would consider using it.

posted by: Kaj 9-May-2023/17:03:04-7:00

This particular thread is about 'What I'm using now instead of Rebol', not about Meta. Any comments I've made about Meta are simply responses to what's been said about how the tools I'm describing are somehow deficient in comparison to Meta, or how they're otherwise lacking - and those statements simply miss the point, in my experience. The tools I started this thread to discuss work fantastically well for my purposes, and for a massive community of others. I've only hoped to clarify and support that point, based upon my actual real-life experiences, throughout this thread.

I've said nothing to the effect of not being motivated to spend effort on Meta - in fact I've been clear that I'm excited to see it continue to develop, that I would love to see it become successful, that I'd be happy to help test, and even offered server resources if they'd be useful. I've also said that we have different perspectives about the purposes of the tools we're interested in. In this thread, I've intended to talk about the value of 'What I'm using now instead of Rebol'. If that means responding to comparisons and contrasts with other tools, or with statements specifically about the tools I'm using (especially when those statement aren't coming from the perspective of deep experience using those tools), then I'll engage in that conversation. Although that's not my purpose in discussing this topic, I do appreciate hearing and reacting to other perspectives. Just because someone's needs are different than mine doesn't mean I consider that perspective lacking in value - I've just continued to focus on 'What I'm using now instead of Rebol' in this thread.

The growth rates of Python and Javascript during the past few years have led to them occupying leading positions among the most popular programming languages on the planet. The statement that 'Python and JS are both *currently bigger, and growing faster than Meta' is simply the truth. Whatever the numbers, that truth is not baseless by any stretch of the imagination. Meta simply hasn't seen that sort of enormous world wide growth yet. If a user base grows from 1000 to 10000, that's a 10x growth rate, but that growth rate doesn't have the same powerful impact and reach of a user base that grows from 50 million to 100 million in the same period of time. Python and Javascript's growth has already spread to tens of millions of developers, and *billions of users. That's in no way a criticism or evaluation of the potential future value of Meta, just a truth about the current undeniably true wide spread use of Python and Javascript. It's kind of hard to get bigger than that...

Kaj, You seem to think I have some sort of fight to pick. I dont'. I'm genuinely sorry if anything I've said comes across any other way. I've been very careful to explain how much I deeply respect and support all of your values and your work. I have no criticisms of any perspective you have to offer. I'd just like to share the value of 'What I'm using now instead of Rebol' in this thread, because I do know it can be helpful to others like me. I can prove the value of those tools in my experience, in terms of the number of jobs I've been able to complete for myself and others. That doesn't take away from Meta's value. You seem to want to prove that I'm wrong, but for the purposes I've described so far in this thread, what I've described and explained about my tools has been the truth of my experience, and I've only tried to clarify the value of the experience using those tools, and the positive effect they've had in my life. I don't have any argument with you or anyone else about those experiences, just hoping to share the value of my perspective about them. I wish you the absolute best of luck with Meta, and all the success in the world. I think what you're doing is fantastic. I'd like to simply share how 'What I'm using now instead of Rebol' has been beneficial to me, with anyone for whom those tools might be similar useful and productive.

posted by: Nick 9-May-2023/20:34:38-7:00

Iontab,

'it is not easy to switch from React to VueJS when you have thousands of lines of code behind you' - that is exactly the sort of thing that current AI tools can help with tremendously, in terms of work load, what used to be a relentlessly time-consuming, painfully difficult grind required to port logic and working code between frameworks, dealing with troubleshooting challenges, etc. ChatGPT has been ridiculously helpful at debugging and porting code logic, in my uses so far. When a huge portion of your existing logic and code base can be ported relatively easily between a variety of similar and comparably useful options in a large open-source ecosystem used by millions, the dangers of vendor lock-in are not nearly as dire as they were with a small, idiosyncratic, closed source solution such as Rebol. I've used chatGPT to port Anvil ORM code to pyDAL, for example, and Anvil REST functions to Bottle routes, for example, and to convert Anvil front end UI layout & functions that call Anvil server functions to, for example, JS Linb and Metro layout and AJAX code - and the speed/ease of that work flow has been astonishingly productive, compared to any other experiences I've had porting code previously. I've also used chatGPT to outline, explain, and convert several thousands lines of a legacy C# codebase - one night doing that saved potential weeks of work, meetings, and grinding careful analysis (chatGPT provided 80+ pages of outlines, explanations, and detailed code analysis/conversion in one sitting). Together with a wide variety of similar-enough framework options (several of which are used by hundreds of thousand/millions of developers), it's my point of view that there is likely enough support to focus on Python and Javascript as the primary ecosystem choices, and to deal with framework choice as only of secondary importance. I don't think anyone could ever lose their work to the same degree as one ever could with tools such as Rebol, Visual Fox Pro, etc., if the choice is to use any framework in the Python & JS ecosystems.

posted by: Nick 9-May-2023/21:34:33-7:00

There seem to be several contradictions in your convictions.

You are confusing growth rate and current size, which is exactly my point. Interest in Meta is still small, so you could argue it's statistically insignificant, but every project has to start somewhere, and the fact is that interest in Meta is multiplying over a year or two. With Python and JavaScript being so big already, there's no way they are still multiplying that way.

I know the thread topic is about not-REBOL, but when you promote that on your REBOL forum, you will naturally get some counterarguments, including from my REBOL alternative Meta.

You claim that Anvil and Python are the superior framework, but then you also present tens of other frameworks, and even put together your own. It's all very interesting, and I certainly look at them for inspiration, but if a reader is to switch away from REBOL, it's hard to make a choice.

posted by: Kaj 10-May-2023/3:24:51-7:00

Have to split my post here, because my modern browser consistently crashes here and looses my work, on a standard input area. One of the reasons why my confidence in current software is limited.

... Then you proceed to claim that AI makes framework and language choices insignificant. If that is the case, why would Python and Anvil keep reigning? And why would frameworks such as Anvil remain tied to Python?

Your objections to Meta start to sound a lot like the objections I got from several people in the Atari 8-bit community: just inertia and wanting to stay in the herd of the day. Both Atari and Python predate REBOL, so I wonder who is clinging to steam engines.

posted by: Kaj 10-May-2023/3:37:51-7:00

You say you respond to comparisons by people who are not deeply familiar with the technology you promote. That's not surprising, because this is your REBOL forum. There is probably only one Anvil expert here.

Well, it's the same for me. You compare REBOL with an early steam engine, and Meta with an attempt to perfect it, without regard for other developments. All three of these views are wrong, and for the readers here, I don't want to leave it at that.

I have already written a lot here about why those views are wrong, but it seems I need to keep repeating it. I'm not sure I can make you see it if you don't look at Meta from a perspective of what it can do instead of what it cannot do yet, and actually try it.

posted by: Kaj 10-May-2023/6:22:04-7:00

I have clarified that Anvil is a work environment which provides uniquely productive and pleasant access to the Python and JS ecosystems, with some additional special features. Adding additionally useful tools to my quiver, from the same ecosystems, is not a contradiction. My last post was specifically about the benefits of being able to make choices between tools which are similar. The fact that a variety of screwdrivers are manufactured which are tailored for use in different environments and situations doesn't mean that all screwdrivers fundamentally suck and that all screw technology should be avoided wholesale. That doesn't constitute a mess, but a situation in which specifically useful choices are available. I put together my own toolkit using other Python and JS tools because I wanted a light weight work environment which could run on a variety of old machines where Anvil couldn't be installed (not necessarily where Anvil apps couldn't be run, but where the server and development environment couldn't be run - old phones, ancient netbooks, etc.), which provides access to the same massive Python and JS ecosystems. That's not a contradiction - I'm excited to have so many choices between effective tools in those ecosystems. My toolkit is a useful little multitool that I'm crafting from available pieces in the Python and JS world, to fit specific interests of my own.

Part of the point I've made about AI has been that it'll likely pave over how developers currently work, and I've been clear that I expect Anvil, Python, and so much more about how software is currently created will likely be entirely superseded by new generations of tools - that they may not be used at all in the future. Those changes are already in the process of taking shape, today.

I didn't mean to compare Rebol and Meta specifically to a steam engine, but the entire current state of software development, and the entire historical process of software development before AI. From what I've experienced during the past few months, it's difficult to imagine we won't have entirely new ecosystems which enable average users to create powerfully useful software just by speaking with an AI, and that the roles of professional developers will change significantly. Creating entire applications by speaking to a computer in plain English is already possible, but I expect we're about to see an explosion in the development of new infrastructure and tooling which eclipses the value and capability of traditional non-AI software development practices, and that new paradigms will most likely form the basis of how software is developed in the future. I'm sure it'll be a messy process, but like it or not, that process has already begun.

Brave does seem to be causing some unusual problems. I can't remember a single time any browser I use has ever lost work using a standard HTML text area. If that were the case, I think the Internet fundamentally wouldn't work for the purposes that billions of people have actually been using it during the past few decades.

posted by: Nick 10-May-2023/8:22:45-7:00

I've made it clear that I think what you're doing is valuable. Horses were *mostly superseded by the auto and airline industries as primary modes of transportation for humanity (include bikes, trains, etc. if you'd like). But horses are still used in situations where they're appropriate. And I can imagine a world which is far better off without cars, modern pollution, etc. (who knows if it's possible to eliminate pollution and destruction on the path which humanity is currently moving...) I think what you're accomplishing with Meta is driven by perhaps a similar value system - one in which the hope that a better, cleaner, rethinking of values provides options to enable an entirely different outlook about what's important in human existence. I've been clear that I respect that value system, your work and your skill. I've many times thought that I'd love to build a sustainable farm which didn't rely on the grid and all the mess of modern life, but unfortunately, I am currently bound to many of the trappings of modern society. I think what you're doing provides some hope for a more sane and pleasant working software development environment. My current needs are just tied to the trappings of the mainstream modern software development ecosystem. I'm cheering you on with Meta, because I understand, appreciate, and support the values and the reasons you have for creating it. Even though I can't necessarily take part in using it at the moment (not that you even have any reason to want that), I think what you're doing, and why you're motivated to do it are entirely valid and useful for all the reasons you embrace.

posted by: Nick 10-May-2023/8:47:10-7:00

Please don't take that as a criticism. I don't mean necessarily to compare Python to automobiles and Meta to riding a horse. My intent is to clarify that I understand the modern software development ecosystem is a complex mess, but just like I can't reasonably drop out of modern society, I can't currently drop out of the modern software development ecosystem. Your vision of a better world is valid, and I want to see you be entirely successful constructing and living in an environment of your own creation, which is cleanly crafted and built on solid core values. I'm so glad to hear that you've got financial support to do that, and that your vision is growing and taking shape.

posted by: Nick 10-May-2023/8:55:29-7:00

We're both clearly crafting our lives to operate in different environments, and with some different values. I deeply respect your values and your choices, and I appreciate the work you're doing. I'm excited to see and hear about every bit of success you have on your current path. Those values are meaningful to me, but not suited to the way I'm currently able to work. I'm just sharing my experiences about which tools are working well to satisfy the needs of my own current working environment. I think people reading this far will have no trouble whatsoever being left with any disparity in our views. I have thoroughly enjoyed learning from your perspective throughout this discussion, and I appreciate the time you've taken to engage with me in some conversation about all these related topics.

posted by: Nick 10-May-2023/9:05:15-7:00

These are not all-or-nothing propositions. It's entirely possible to withdraw from parts of modern life that are detrimental, while still making use of parts you can't get rid of. And in the same way, it's entirely possible to replace parts of modern software where you can, while leaving other parts to be replaced in the future.

I don't care too much about what I cannot do now, I care about the direction I'm going.

posted by: Kaj 10-May-2023/9:13:47-7:00

I think you're going in a great direction. Keep going :)

posted by: Nick 10-May-2023/9:15:30-7:00

Thanks!

posted by: Kaj 10-May-2023/9:16:51-7:00

In the same way that committing to a career path means withdrawing from doing many other things in life (we all have only so much time), committing to a software development path means largely withdrawing from taking part in other methodologies. Nearly all my close friends have chosen wildly different career paths, but we spend our free personal time doing things that are meaningful in shared ways. What you're doing with Meta is meaningful to me - you and I are just involved in different career paths (I have mostly used software development to build tools used in other career paths).

posted by: Nick 10-May-2023/9:24:10-7:00

Yes, I'm strongly focusing, because otherwise it's too much work to accomplish. It's also why people here try to stick with REBOL, so Meta is less of a stretch for them than Python.

posted by: Kaj 10-May-2023/10:11:45-7:00

Well, I still do understand and appreciate the Rebol values, just can't use Rebol as a tool for most projects now because it was left by Carl in a condition that doesn't support connectivity with too many other modern infrastructure pieces that I need. But I did enjoy many years using Rebol to solve real world problems in demanding environments, and I spend lots of time, money, and effort trying to help the open source version move forward - and I still do use a number of my Rebol apps regularly. I hated to abandon it. So I'm certainly interested in hearing about any accomplishments with Meta that you're willing to disclose, and I'm willing to take part in testing, documenting, or otherwise helping in any way that I might be able, if that ever becomes a need.

posted by: Nick 10-May-2023/12:02:31-7:00

spent* lots of time, ...

posted by: Nick 10-May-2023/12:04:03-7:00

The goal is to get real-world usability as quickly as possible.

So far, I spent most of the time getting the core of the language to work, but that already includes direct hardware access and basic connectivity with operating systems: file I/O, command-line arguments, environment variables, date/time access, running other programs, and random numbers and such.

The core is not finished yet, but I will spend most time implementing more access to other sub-systems.

posted by: Kaj 10-May-2023/12:43:23-7:00

Nick, are you sure? Eric Clapton is NOT t-h-e best guitar player in the world??

LoL!!

He is better than I am that is a sure thing, but I never have been impressed very much if I compared him with others.

Anyway. Meta is so small that any growth quickly outperforms growth in the huge existing ecosystems.

And about the dependency crap
I have upgraded to Ubuntu 23 now. My browser is showing tabs in bold typefaces now, The program Keepass I was using has been replaced with an upgraded version using huge icons, making the app almost impossible to use. Libreoffice cannot open a spreadsheet anymore because the program crashes instantly (missing lib). And who know what else sh*t awaits, all because of some programs need for the newest library of some sort that made upgrading "unavoidable".

posted by: Arnold 10-May-2023/14:02:18-7:00

Arnold,

That's why I use web apps, with front ends that run in the widest variety of browsers possible (even ancient ones). I've used no fewer than 7 different machines today, running various versions of Windows, Android, iOS, and Chromebook. I don't install any software on those machines, and I can just pick up right where I left off in any app on any of those machines. I move between my laptops, tablets, phone, etc., in various rooms in my work environment, at client sites, at home, at my girlfriend's house, at the homes of my family and fiends, on the road, etc., using whatever device is convenient in those environments at the moment.

;)

posted by: Nick 10-May-2023/15:47:18-7:00

That sort of freedom to move between machines without ever performing any sort of traditional software install is life changing and tremendously enabling in my natural life.

posted by: Nick 10-May-2023/15:48:36-7:00

I ran these round trip latency tests for Anvil, with the server in England:

1) newer laptop, ISP #1 - From America/New_York, the first round trip took 0.458 s. The subsequent 5 round trips took 0.140 s on average, with a min of 0.133 s and max of 0.151 s.

1a) newer laptop, ISP #1 - From America/New_York, the first round trip took 0.532 s. The subsequent 5 round trips took 0.167 s on average, with a min of 0.159 s and max of 0.175 s.

1b) newer laptop, ISP #2 - From America/New_York, the first round trip took 0.789 s. The subsequent 5 round trips took 0.227 s on average, with a min of 0.194 s and max of 0.266 s.

2a) slow old netbook, ISP #1 - From America/New_York, the first round trip took 0.491 s. The subsequent 5 round trips took 0.149 s on average, with a min of 0.134 s and max of 0.169 s.

2b) slow old netbook ISP #2 - From America/New_York, the first round trip took 0.708 s. The subsequent 5 round trips took 0.257 s on average, with a min of 0.191 s and max of 0.403 s

3a) old Android, ISP #1 - From America/Indianapolis, the first round trip took 0.514 s. The subsequent 5 round trips took 0.166 s on average, with a min of 0.149 s and max of 0.178 s.

3b) old Android, ISP #2 - From America/Indianapolis, the first round trip took 0.841 s. The subsequent 5 round trips took 0.355 s on average, with a min of 0.298 s and max of 0.497 s.

3c) old Android, ISP #3 (phone data plan) - From America/Indianapolis, the first round trip took 0.572 s. The subsequent 5 round trips took 0.209 s on average, with a min of 0.185 s and max of 0.243 s.

The ISP (Internet Service Provider used to provide Internet connectivity to my local machine) consistently made a difference. Not surprising, that ISP #2 is generally slower.

posted by: Nick 12-May-2023/5:20:20-7:00

I've started to put together an info/instruction/guide sheet for my little development kit:

https://com-pute.com/nick/bottle-pydal-jslinb--instructions.txt

BTW, yesterday I tried running an app made with my little toolkit in one of the old Kindle 'experimental' browsers, and the full feature set of the front-end jsLinb system even runs there (that's a notoriously useless browser). I'm tickled that I can run the development environment and server, and the front end, on such a complete range of common platforms. So far I've tested the full back-end development/deployment system (server and REST API infrastructure, database ORM, visual builder), and well as the front-end app framework on the following platforms, and it runs out of the box, without any configuration or setup (just download the 2.3 MB file and unzip it):

- Windows XP, 7, 8, 10, and 11 (layout portions of the front-end even run in Windows 95 and 98, using Retrozilla browser)

- 64bit and legacy 32bit Linux distros (even stock 32bit Knoppix, Puppy, Q4OS, Slitaz, and other live boot disks, as well as modern Debian, Ubuntu, and other common flavors)

- Android and iOS phones and tablets (even very old ones - as long as you can run Termux on Android, Alpine Linux in iSH on iOS, or any other environment in which Python can be installed (if you can do something comparable to 'apt-get install python3' (or python 2.7), you're in business))

- Chromebook using the default Crostini Linux environment and/or Termux in the Android environment

- Raspberry PI (any other single board PC should work too, as long as it can run Python)

- The full feature set of the front-end jsLinb system even runs in the old Kindle 'experimental' browser

As long as you can run Python 3.x or 2.7 on your device, the *full development system just works, out of the box, without any install. To be clear, there is absolutely no setup or install required to *run apps created with this toolkit. App users simply open their browsers to the URL of a deployed app. Python is only required to run the development/deployment back-end server environment used to build and host web apps with this tool kit.

posted by: Nick 12-May-2023/14:11:35-7:00

I made a video introduction and some tutorials for my little bottle-pydal-jslinb toolkit:

https://youtu.be/FoUBhEQ6bDI - Intro (~10 minutes)
https://youtu.be/4OP48hnldds - Back-end tutorial (~45 minutes)
https://youtu.be/_GF6DMdOXnM - Front-end tutorial, part1 (~60 minutes)
https://youtu.be/jHRyPdSZurM - Front-end tutorial, part2 (~80 minutes)

The full toolkit, with all the tutorial examples, is available here:

https://com-pute.com/nick/bottle-pydal-jslinb--tutorial.zip

posted by: Nick 15-May-2023/14:55:40-7:00

At face value, and by what the video tutorials demonstrate, the toolkit just looks like any other simple CRUD system, but for me, the great strength of this toolkit isn't the toolkit itself, but the ecosystems which they enable developers to make use of. For example, add a few lines of Python code on the back-end, and I can use it to quickly (as in minutes) build a web app that sends text messages with my Twilio account - and the same is true with almost any other commercial service, or system that publishes a Python API. Or, for example, if I want to integrate video recording in the front-end using the mediastream browser API, or integrate a 3D layout using the Coppercube library, or any other AI that works in a browser, it's again just a quick job, with thousands of examples of existing code and community support to get the job done immediately.

The toolkit itself makes CRUD work, connection to (and migration between) any of the common database systems, as well as layout of common UI interfaces easy and fast. The server and development back-end runs on new and legacy 32 and 64 bit Windows, Linux, and Mac machines, Android and iOS phones and tablets, Chromebooks, etc. - the only requirements are Python, a text editor, and a browser, and the front end runs on an extraordinarily wide range of new and very old browsers. Any piece of the toolkit (front end, back end server, database abstraction layer, etc.) can be swapped out for any of the many alternatives in each ecosystem (i.e., Bottle can be replaced with Flask, FastAPI, Django Rest framework, Anvil, etc., and PyDAL can be replaced by SQLAlchemy, Pony, Django, Dataset, Anvil, any other Python ORM, or just pure SQL in Python. You can also choose to swap out the built-in Bottle development web server with any other more performant WSGI web server. The front end can be replaced by any React framework, custom HTML/CSS/JS, jQuery, Angular, MUI, MDB, Metro4ui, etc., or any other tool that works with XUI, Fetch, Axios, or any other library that enables HTTP requests (even Curl and/or native OS frameworks that can send requests to an Internet URL and read the response)).

The point of this particular toolkit is to be tiny (less than 3Mb) and portable to as many OS platforms as possible, with no install required, and to include a productive set of tools including visual layout builder, code auto-complete, etc.

posted by: Nick 15-May-2023/15:29:08-7:00

Unlike Anvil, this little toolkit is a work in progress, but the tools I included have been around for years, and have been used in production (likely more than Rebol ever saw), so using them and relying on them is more about using and relying on the Python and JS ecosystems, which are about as sure a bet as you can find in the current landscape of choices.

posted by: Nick 15-May-2023/15:31:41-7:00

Since this thread is at rebolforum.com, I should make it clear that my transition to Python was painless. Just a basic understanding of how to use variables, functions, list and dictionary data structure, and other fundamentals like how to use pip-install are all that's needed to get started with getting really useful back-end code working. I still despise most of the mess in the HTML/CSS/JS/REACT/ETC world, but frameworks like metro4ui, MDB, jsLinb, and others, make building front ends that run on most platforms of interest (without installation), much more palatable.

posted by: Nick 15-May-2023/15:38:46-7:00

If you want to use my little toolkit to run a server on a Pico W micro-controller board, for example, you can simply replace Bottle with microdot:

http://www.doctormonk.com/2022/09/a-better-web-server-for-raspberry-pi.html?m=1

or use any of the many available alternatives to run on any board that supports micropython:

https://awesome-micropython.com/

And I like the MicroPyDatabase module, for example, to enable simple json storage in micropython, but there are libraries to access every common serious database system, at the link above.

That's the sort of benefit I'm absolutely enamored with, using Python's massive ecosystem. Everything is so freakin easy to accomplish - the solutions already exist, they're tested in production by millions of users, they're free, there are multiple options to accomplish any end goal, and they just work. Want to implement deep learning models into your apps? There are many libraries for that:

https://www.tinyml.org/

Just that one little library represents the refined work of millions of hours of human labor by extremely intelligent people who are pushing the bleeding edge of what is possible with computers in our world. And there's no other ecosystem where that is as developed in the fields of machine learning, AI, etc. What's exciting to me in the Python ecosystem is that it has moved so far beyond creating CRUD apps - truly amazing new capabilities are available at anyone's fingertips, and it's flourishing in a way that opens up all sorts of new frontiers in computing. That's what I mean when I talk about the 'massive power of the Python ecosystem'. Between it and the massive JS ecosystem, you can accomplish anything that has been explored in computing. When people think that working in those ecosystems has to be a mess (because there *is so much noise and churn in those ecosystems), it's mostly from lack of experience, and too much attention to the chaos which appears on the surface. Out of that chaos emerges truly fantastic tools.

posted by: Nick 22-May-2023/8:49:08-7:00

I don't know if anyone else in this forum is experiencing this yet, but every client I've spoken with during the past few months has asked me about incorporating AI into their projects. Here's a 17 minute intro to demonstrate just how easy it is to begin doing that in the Python ecosystem, no prior experience required:

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

One of the biggest clients I had last year chose to use Python, and eventually Anvil to build their app, because they wanted to be able to take advantage of potential data science tools in the Python ecosystem, even though it wasn't part of their original business requirements. In the past weeks, the development of their product took a turn which has hinged on being able to take advantage of that ecosystem, and they've forged ahead powerfully. That company was started by a rockstar tech CEO who had experience with previous companies that died because people in the organization hadn't anticipated the value of those sorts of integrated capabilities. Big ecosystems can be messy, but your own choice of tools can be guided by values that are appropriate for the specific needs of a given situation, and the big ecosystem provides already established solutions to unbridled capabilities needed to actually dive in and achieve end goals, with the least resistance possible caused by the tooling. To me, being able to reach those end goals is the #1 priority.

posted by: Nick 22-May-2023/12:09:26-7:00

If I want to incorporate web scraping, image recognition or any other complex data analysis, or if I need to connect to any service that does anything of value (communications for example), the tools to do that, and the connectivity to those systems are established in the Python and JS ecosystems. I don't need to spend a minute learning how to build a videoconference system - that's been the life long work of other professionals, and the infrastructure, tooling, and easy integration, has already been built, using best practices that have been established through millions of hours of others' work. Python and JS ecosystems enable connectivity to and implementation of all the capabilities that are the result of armies of smart people working to make those pieces work well. It goes so far beyond CRUD application development - although solutions for that, and every other imaginable problem, exist in droves, and there are bountiful choices to fit the needs of every common situation.

posted by: Nick 22-May-2023/12:24:10-7:00

Have you looked at Cuis smalltalk?
http://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev#the-philosophy-behind-cuis

excerpt: "What sets Cuis apart from the other members of the Squeak family is the focus on the original values of the Smalltalk project at Xerox PARC, and an active attitude towards system complexity...Unbound complexity growth, together with development strategies focused only in the short term, are the worst long term enemies of all software systems. As systems grow older, they usually become more complex....
Cuis is continuously evolving towards simplicity. Each release is better (i.e. simpler) than the previous one.

posted by: CuriousGeorge 30-May-2023/22:34:28-7:00

Thanks CuriousGeorge! I noticed that it shares the same VM as Pharo - have you used it with Pharo? Have you run it on Android and iOS (those platforms are critical for my needs)?

posted by: Nick 2-Jun-2023/7:56:36-7:00

There's always so much going on in the Python world. I'm looking forward to this development:

https://www.theregister.com/2023/05/05/modular_struts_its_mojo_a/

posted by: Nick 2-Jun-2023/17:55:50-7:00

BTW, Chris Lattner is the creator of LLVM, Clang, Swift, MLIR, was an important tech leader at Apple, Google, Tesla, and has many other ridiculously great credits, so I'm particularly interested to see what happens with Mojo.

posted by: Nick 7-Jun-2023/13:11:57-7:00

Within the first thirty seconds of this interview he lays down his thoughts about 'simplicity' in software development:

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

I think his perspective, experience, and understanding about potential solutions to complexity problems are unavoidably relevant to anyone who was ever interested in Rebol's values.

posted by: Nick 7-Jun-2023/13:18:34-7:00

There are several things here.

With Mojo, Python finally seems to get an efficient variant. This trend of efficient high-level languages started about a decade ago with Julia, Ruby got Crystal, and even Go got V. Mojo has a lot of overlap with Meta, so that confirms my direction.

I like Modular's mission. It is closed now, but if it is serieus about its modular approach, Meta will be able to integrate with the same framework as Mojo, like with LLVM.

One of their goals is broad reach, but they are quite focused on AI, and thus on large, modern systems. I think Meta fulfills their goal of broad reach better.

The same goes for complexity. Their statements you refer to are about complexity in the ecosystem, not so much reduction of complexity in their own framework. Meta goes much farther there.

posted by: Kaj 12-Jun-2023/8:35:37-7:00

Your response clarifies how our perceptions have been formed by different perspectives. My interests are currently geared towards *using and connecting to pieces of existing ecosystems - reigning in the complexity of existing powerful mainstream tools, so that they are manageable and productively useful. Your interest is in building a more efficient new ecosystem - I admire that, it's outside my wheelhouse :)

posted by: Nick 13-Jun-2023/21:06:15-7:00

That's what Modular wants: they want to replace the AI ecosystem.

posted by: Kaj 14-Jun-2023/11:50:06-7:00

The AI arms race is in full swing. The next few years are going to be *interesting for humanity.

posted by: Name 16-Jun-2023/11:20:10-7:00

"...I don't know if anyone else will ever read any of this, by I hope it's useful for someone..."

I find it tremendously interesting.

posted by: Sam the Truck 24-Jun-2023/12:05:07-7:00

One thing I've noticed about peoples beliefs about the intelligence and capabilities of computers. They always say, well it may do this,(checkers) but it will never do that,(chess), and this goes on and on but every single time the computing power goes up enough the computer beats the human. Every time. Now people say AI, well it's good at simple stuff but it will never do...(whatever). But what we have now in AI is an infant. The next five years and with maybe a doubling or couple of doubling of computing power and I think humans will have an extremely hard time keeping up with AI doing anything. Anything at all. Ten years, maybe 15, forget it. We will be totally at the AI's mercy. Whether you think this is good or bad... great and powerful people do not show a great deal of empathy towards those lower than them. And we will be lower.

Following up on the tinyML. There's some guys who had a company, XNOR.ai, that could recognize all sorts of real time video when trained They could recognize people, bikes, animals, all sorts of stuff. The amazing thing was they used cell phones and raspberry pi's to do this. They were getting rid of all the multiply and divide processing and had reduced the AI to yes or no binary. It was super fast. They used have a lot of videos but Apple bought them and a lot of it disappeared. It was extraordinary stuff, and I can't help but think Apple made a huge and profitable decision in acquiring them. Impressive stuff.

I saved in a folder a bunch of stuff related to XNOR.ai before they went dark. Here's some of the links

https://github.com/jojonki/BiDAF

https://github.com/allenai/XNOR-Net

https://people.utm.my/asmawisham/xnor-ai-frees-ai-from-the-prison-of-the-supercomputer/

I will say their stuff was MAJOR super impressive. They were talking two orders of magnitude less processing power.

A paper they are basing this off of.

XNOR-Net: ImageNet Classification Using Binary Convolutional Neural Networks

https://arxiv.org/abs/1603.05279

Part of the abstract,

"... In Binary-Weight-Networks, the filters are approximated with binary values resulting in 32x memory saving. In XNOR-Networks, both the filters and the input to convolutional layers are binary. XNOR-Networks approximate convolutions using primarily binary operations. This results in 58x faster convolutional operations and 32x memory savings. XNOR-Nets offer the possibility of running state-of-the-art networks on CPUs (rather than GPUs) in real-time..."

XNOR video

https://www.youtube.com/watch?v=3cD9bpfX9FA


posted by: Sam the Truck 24-Jun-2023/13:47:03-7:00

I watched the XNOR video. My understanding is that it's not a standalone framework or library, but a technique applied to neural net models to reduce memory footprint and improve efficiency. I wonder if it could be applied to tensorflow lite or other popular tools. Either way, I think tflite does the sort of image classification shown in the XNOR video, at 27 frames per second on the same board demoed in the video, which is practically useful.

posted by: Nick 24-Jun-2023/23:15:38-7:00

"My understanding is that it's not a standalone framework or library, but a technique applied to neural net models to reduce memory footprint and improve efficiency..."

Sorta. It�s a new math formula that instead of a lot of multiply and divide it uses binary XNOR, hence the name. The amount of computing needed is VASTLY lower. They say it will work for any sort of AI work.

One of the disadvantages is reduced accuracy but, I think, by raising the number of neurons, while vastly reducing the compute time it evens out while still gaining performance. (I may be stating this wrong or may be wrong). I saw a video where they said they had high accuracy but not as high as normal. Like 10%-20% difference off the top of my head but they were doing stuff with 10X-20X less processing power. If it works as they say, and it seems to, we may see some extraordinary things come out of Apple in a few years since they bought them out.

I don't think TensorFlow Lite is the same. I think they lower the number of bits used but process them in the same way with lots of matrix operations. I fully admit I do not understand these AI operations except in the broadest sense. So I could be wrong.

I don't think people have really internalized how dangerous AI is. Musk has. And it could all work out but if it doesn't. We're screwed. Done, unless it keeps us as pets.

People talk about all the "tokens" they load up and then make fun of AI because it�s not perfect but while the tokens (words) are important the number of parameters (likely wrong nomenclature) or neurons or nodes that operate on these tokens is far, far lower than human level brain cells. Once these numbers of computing neurons start to get much higher. THEN that�s when the trouble starts. They will be able to operate and remember this vast amount of human knowledge instantly. Something no human can do. As the nodes go up, the reasoning ability will also. Or so I theorize.

We may need a Butlerian Jihad!

posted by: Sam the Truck 25-Jun-2023/21:20:17-7:00

The head of Stability AI said in a recent interview that we'll have ChatGPT quality LLMs running locally on cell phones by next year (no cloud needed). He seems to be the optimistic type, but it's at least a bit of insight into what might be coming soon.

posted by: Nick 4-Jul-2023/8:53:51-7:00

I've been using ChatGPT to help write code and to perform useful data manipulation tasks.

I had it read the source code of web pages from my github account, and recreate the page layouts in both Bootstrap and Metro4ui. It did an amazing job with Bootstrap, creating dropdown menus and adjusting content on the page, which saved me hours of work. I actually did a huge amount of work with that process in a single sitting, using voice dictation while hanging on a hammock in the woods :)

One client sent me 38 pages of table data scanned from a paper book. I loaded the scanned image files into Google Docs, which performed OCR to create a very messy document. ChatGPT was not only able to clean and convert the OCR document into multiple CSV files, and then merge all those files into a single Python dictionary, it was also able to discern patterns in the data and recognize whenever there were anomalies and errors in the data caused by slight imperfections in the scanned images (warped/stretched values, spots on the pages that were perceived incorrectly by the OCR process, etc.). I didn't have to write a single line of code for any of that process, and what would have been a grudging multi-day volume of mind-numbing tedious work, was tranformed into a fun little easy project in a couple short sittings.

I'm regularly finding situations like this which save me countless hours of work, and one of the most important aspects is that the AI does far better when using tools that it's been trained upon extensively. For example, it does a far better job creating layouts exactly the way intended, when using Bootstrap (which I use in MDBootstrap), compared to using Metro4ui, because it's been trained on millions/billions of examples of Bootstrap code and documentation. And of course it's amazingly fluent in Python and JS and their massive ecosystems. It is familiar with more of the available tools in those ecosystems than any single human could ever begin to experience or even know about, so comparing the use of libraries, for example, is sped up in a way no human could ever being to dive into and evaluate. You can ask ChatGPT which tools may be useful for a particular problem, then to compare and evaluate the benefits and drawbacks of each tool (security implications, limitations and features, etc.), and then to write working code examples using each tool, with a given data set, etc. - this can save hundreds of hours of research and coding work, and lead directly to better solutions to problems, with fewer limitations and unexpected walls hit during the larger scope of a complex project.

I'm looking forward to trying tools like this:

https://medium.com/codingthesmartway-com-blog/the-dawn-of-a-new-era-chatgpts-code-interpreter-f276f36eeab7

And I can't wait for when we have capable AIs like this running on our local machines (that situation is improving dramatically every day). It's an absolutely astounding time to be alive.

posted by: Nick 11-Jul-2023/6:38:01-7:00

This is going to be so useful for non-programmers, to do the kinds of things that I used to tell people Rebol was fantastic for:

https://youtu.be/p6Yw0Bx5dbw

https://levelup.gitconnected.com/the-magical-chatgpt-code-interpreter-plugin-your-personal-programmer-and-data-analyst-f8cd69e8323b

posted by: Nick 11-Jul-2023/10:40:51-7:00

Your explanations of how you are using ChatGPT is inspirational. Would you happen to have a link or a simple way that would explain how I would get started with this? What I would like to do is to get it to format data for a program called BRL-CAD which a geometric CAD. It's a heavy duty, oldest maintained open source program, or so they say. I would like to use it for electromagnetic simulation. Or even better, have ChatGPT draw the forces and simulation for different motor type structures.

2nd, do you have to pay them, what is the cost and where?

3rd I see all these models that can be used locally. I wonder if on a fairly weak consumer computer with 16GB memory if I could do some of this electromagnetic research but have the answers not immediately pop up but work on them at the rate of the processor.

I look at these and see some that do text ad some that do graphics but I don't see how you've linked them. When asking for this sort of data displayed, would it be capable of making a file by telling it to display a set of data in a jpg with so and so size?

I've never seen anything move quite so fast as AI software. The usability lags far behind.

posted by: Sam the Truck 13-Jul-2023/13:54:48-7:00

Ok I see the link you have

https://levelup.gitconnected.com/the-magical-chatgpt-code-interpreter-plugin-your-personal-programmer-and-data-analyst-f8cd69e8323b

has some of this. I looked at it but did not scroll down and look at all of it. Oops.

posted by: Sam the Truck 13-Jul-2023/14:12:46-7:00

Note that at the moment, the code interpreter is Python only. It also requires a paid account ($20 per month). I previously chose to get a paid account to enable much faster response times, and also for GPT4 access. You can use the free GPT 3.5 model to help solve problems interactively, and it can do a lot of great work with languages and libraries that are very well known. It's not so great with tools that don't have millions of examples and tons of documentation online.

The code interpreter is really neat to watch - it alters and improves its own code iteratively as it deals with your data set, explaining the 'thought' process, and optionally displaying the code it creates to solve the problem you've given to it. It's amazing to think what it'll be able to do in the coming years!

I think open source models will follow closely on the heels of everything the big commercial models do - give it a few months to a year initially. By 2025, the software development landscape, and many other engineering and scientific professions will be totally transformed by AI solutions that evolve faster than anything we've ever seen.

posted by: Nick 16-Jul-2023/1:05:10-7:00

BTW, I've been gradually moving to using Bootstrap and MDBootstrap for my UI needs. Bootstrap studio is a nice visual editor for Bootstrap (and there are others such as Pinegrow) - plus, MDBootstrap provides every imaginable pre-built widget and expected UI functionality, with lots of complex functionality ready to go, in beautiful ready-to-use components (I bought the full commercial version a while back, but have been slow to get using it in projects - I'll use the jQuery version, although there are React, Vue, and Angular options available).

This week I may choose to accept a large public-facing commercial project, which will likely keep me busy for the rest of the year. For that, I'll use MDBootstrap, Flask, SQLalchemy (with either mysql or postgres, depending upon the hosting preferences of the client), and all Python ecosystem on the back end. This will be a deep commercial project - the client should be able to hire from the largest possible pool of developers, down the road, if I'm ever not available. Using these tools, he should be able to easily find people to help work on / extend any portion of the project, front-end or back-end, whenever needed, since there are millions of developers available who know those tools.

For smaller projects, I still absolutely love using Anvil. Nothing I've ever touched has been more productive, powerful, or enjoyable to actually get work done. I've been such a happy camper for the past year and a half, and have been more easily productive with tech, than I've ever experienced in my lifetime.

posted by: Nick 16-Jul-2023/11:54:20-7:00

One of the benefits of using Bootstrap, MDB, etc., is that older versions work in all but the most ancient browsers, so I only have to resort to using things like jslinb to support the most ridiculously outdated front end requirements (Bootstrap 4 even runs in qtweb, IE 10/11, and all the mainstream mobile/desktop browsers).

posted by: Nick 16-Jul-2023/13:29:08-7:00

Thanks

posted by: Sam the Truck 4-Aug-2023/19:45:28-7:00

Nick, you haven't done educational material like Anvin for Red?

posted by: Sergey 6-Nov-2023/6:37:06-8:00

* Anvin -> Anvil
... or like your other teaching materials

posted by: Sergey 6-Nov-2023/6:41:06-8:00

I had written some introductory material at:

redprogramming.com

but support for mobile and web platforms was never established during the time period I needed it (that was my main motivation for supporting Red in the beginning), so I had to move on.

I am *extremely happy with my current tool set, compared to anything I ever experienced in the Rebol ecosystem. From first steps in big projects, to deployment and support, Anvil (+python on the back end, and some HTML/CSS/JS on the front) has satisfied an enormous variety for modern requirements for a wide variety of projects.

I'm always on the lookout for productive tools - currently taking a look at TotalJS (and another retro little peek at Vaadin), as well as always keeping other mainstream python web frameworks, and a variety of HTML/CSS/JS/React/etc front-end frameworks, plus Streamlit, NiceGUI, and other full stack python tools (along with ORMs) on hand, but so far nothing has been as outrageously productive, versatile, enjoyable to use, powerful, etc. across a wider range of cases, than Anvil... for me.

posted by: Nick 6-Nov-2023/12:36:06-8:00

Thank you. I'll take a look.
About Python and HTML/JS - I used PHP instead of Python because I knew it, but I didn�t know Python :)

posted by: Sergey 6-Nov-2023/20:06:57-8:00

Thank you. I'll take a look.
About Python and HTML/JS - I used PHP instead of Python because I knew it, but I didn�t know Python :)

posted by: Sergey 6-Nov-2023/20:07-8:00

I was taking a look at altme, which I had used productively years ago. It still seems functional, (downloaded to a chromebook, and running as a pc app, using wine), but it appears an abandoned relic, persisting with no intervention or support. This led me back to rebol.com, which linked here. Some interesting discussion, such as ChatGPT for coding and data massaging. A quick question - how would one increase the font in Altme? I need a magnifier to read it, even with my screen resolution set to 850 by 560! I need to come back and read more closely the posts. Thanks.

posted by: Antony 13-Feb-2024/1:56:08-8:00

You are right about the state of AltME. I used to use the Linux version, but it doesn't work anymore on most recent Linux distributions, so now I use the Windows version under WINE, too. As far as I know, there is no way to enlarge the fonts. Perhaps some deep fiddling with system or WINE settings.

posted by: Kaj 13-Feb-2024/15:08:53-8:00

There are AltMe messages from public posts until 2013 on rebol.org.
Monitor on really low resolution or use a magnifying glass.

posted by: Arnold 14-Feb-2024/11:04:26-8:00

https://www.marktechpost.com/2024/03/31/modular-open-sources-mojo-the-programming-language-that-turns-python-into-a-beast/

posted by: Nick 1-Apr-2024/22:58:53-7:00

Found a better Pig Latin:
people.sc.fsu.edu/~jburkardt/c_src/pig_latin/pig_l

posted by: Kaj 4-Apr-2024/10:08:10-7:00

Aargh
people.sc.fsu.edu/~jburkardt/c_src/pig_latin/pig_latin.html

posted by: Kaj 4-Apr-2024/10:12:04-7:00

Forget bootstrapping compilers - this is now the bar that every programming language must pass to be considered legit.

posted by: Nick 6-Apr-2024/9:48:20-7:00

Home