AltScript
SQLPAGE is fantastic as a Web App builder but it has nothing to do with a programming language like Rebol, Red and Meta.
Rebol, Red and Meta should incorporate a Web server with HTTPS provision, the AltBase DB and/or SQLITE and an HTML front end all with their own dialects.
If Carl was still working on Rebol he surely would have done just that as a natural progression of the language.
Working in Python or any other language other the Rebol/Red/Meta is clearly awful and always will be.
Can anyone close to Carl ask him what he wants to do with ASON/AltScript ?
posted by: Adam 3-Dec-2024/7:41:31-8:00
"SQLPAGE [...] has nothing to do with a programming language like Rebol, Red and Meta" - SQLPage uses a dialect of SQL to produce UI and HTTP endpoint output, which is fondly reminiscent of Rebol's purpose and goal as a programming language - as far as dialects are concerned. I think SQLPage is actually a fantastic example of the sort of dialect tools Carl had hoped might be created with Rebol. Also, it integrates nicely with SQL code, to produce database backed CRUD apps, which in the end, equates to much of the same functionality that I used Rebol to accomplish. SQLPage is also able to request and submit data from/to HTTP API endpoint functions, which is similar in many ways to how Rebol was intended to be used as a messaging language. SQLPage also exists as a small single executable without dependencies, which can be easily compiled to run on nearly common OS - which is one of the things that drew me towards Rebol's practical, useful ethos. SQLPage is really useful for data and analytics staff who have a need to build UIs and web APIs, and to consume web APIs - which goes a long way towards producing useful application functionality, especially for typical database backed CRUD apps, which is a lot the end goal I accomplished with Rebol. It's also got a useful auth system, and a nicely configurable UI component methodology built in, and the whole system integrates absolutely beautifully with SQL, UI, and language components that are used absolutely everywhere. In practical application, all those end goal purposes qualify nicely as having 'something' to do with the purpose and goals of Rebol, Red, and Meta :) ... and in most existing production environments, it's far more practical and useful at accomplishing actual data management work which needs to get done - at least in the environments I work in.
"If Carl was still working on Rebol he surely would have done just that as a natural progression of the language." - I agree that almost surely would have been a practical progression in the Rebol world... but, that never happened... SQLPage actually exists, it's productive, it's actively maintained and improving, it's a joy to use, it's backed by the big RDBMSs for real production data management, and it's useful. Existing and being actually useful, vs being an imagined hoped-for solution, isn't a valid comparison, for my needs.
"Working in Python or any other language other the Rebol/Red/Meta is clearly awful and always will be." - I'm generally curious why you say that? What sorts of experiences and tools led you to forming that impression? I and millions of other hard working developers who've put Python to use, love it. Python has been used to accomplish some of the most important work in the modern technology landscape. Python is the default interface language for CUDA, PyTorch, Tensorflow and other critically important ML frameworks, because developers have been successfully and happily using it for many years. Working with Anvil and the entire Python ecosystem, for thousands of hours over the past few years has been an absolutely fantastic experience, for the sorts of work I've done. I loved using Rebol, and I love using Python, Anvil, etc., also. I've been absolutely satisfied and have used Python based tools to successfully complete big projects, and I've been regularly amazed at how everything in the Python ecosystem regularly 'just works' (mostly because it gets used and put to the test by so many developers in production environments). I'm not sure why anyone would consider it to be 'clearly awful'. It's worth noting that nothing close to the actually significant accomplishments achieved in the Python ecosystem have yet been achieved with the Rebol lineage. At least in my experience, the difference is that Python is far more mature - clearly not even close when compared to Rebol - and those billions of hours of work, production implementation of solutions, etc. have sculpted the Python ecosystem into a fantastically useful world of tools that makes getting work done, a regularly enjoyable and consistently successful prospect, at least for the sort of work I do.
posted by: Nick 3-Dec-2024/20:20:58-8:00
This is honestly an interesting topic to me, because it cuts right to the heart of practical purpose and the productive potential of computing tools - everything which led me to using Rebol. I like to think about things in terms of 'what solutions are you trying to build?'. Clearly, a tool such as SQLPage is not similar in architecture to a programming language like Rebol, but the practical purpose, in many cases, ends up being very similar. The real power of SQLPage is it's ability to integrate with SQL, which takes the place of many of the actual language capabilities inherent in Rebol, when it comes to building actual applications. Of course, you won't build a VR game with SQLPage, but for building the sorts of end-user applications that the overwhelming majority of Rebol community members were building (lots of CRUD apps, and functionalities which led to being able to produce actually useful data management applications), SQLPage, together with SQL and the RDBMSs it supports, along with the UI dialect it enables, end up being able to produce end-user applications that are far more practical, performant, scalable, capable, and able to be integrated into modern business environments, far more easily and effectively than could ever be achieved with Rebol. That stack - RDBMS with web UI is capable of building applications which satisfy so many actually useful requirements.
I'm curious what sort of applications you'd hope to build which fall out of that scope? Clearly there are many, such as games, 3D, graphics, VR, etc. - and for those, tools such as Godot and other frameworks fill the gaps (and JS frameworks fit in beautifully with the whole set of RDBMS + web UI tooling solutions I've found useful). For me the killer space is now deep learning and all of AI, which of course is thoroughly dominated by Python - deeply and tightly integrated with CUDA, PyTorch, Tensorflow, etc., so very hard to get away from, not that I want to get away from Python. So what is it that's so novel and outside the typical business application space that you find Rebol to be so much more useful for, compared to anything in the Python world?
I'd take on *any challenge in the application spaces in which I have experience, using Anvil and Python ecosystem tools, compared to anyone using any of the Rebol lineage tools. I'd find it hard to imagine that anyone using Rebol tools could produce a better product, anywhere nearly as quickly, as effectively, as easily, with better user satisfaction, than I could with Anvil, other Python tools, and generative AI. I think that would be a really fun comparison to experience - I'd do that with anyone who wanted to try, without hesitation :)
What I used to do with Rebol regularly, was to look at applications that took hundreds or thousands of lines to create with other languages, tools, and ecosystems, and actually recreate their functionality in tens or hundreds of lines of Rebol. I did that numerous times, and was always amazed that developers who focused solely on other language tools would simply look away and not be interested, after such a fantastic display of practicality and productivity. Now I do the same with Anvil and other tools, and the few people left in the Rebol community have often disregarded such fantastic displays of practicality and productivity. I've listed literally hundreds of actual production experiences I've had using Anvil, Python tools, and generative AI, and never hear about comparable experiences from anyone who complains about Python. I just hear general comments, without any support in practical application experience, to back up claims - not even explanations about personal preferences which are based on details of successful experiences. Just general 'anything other than ___ sucks'. That's not much of a convincing argument which encourages excitement.
There's absolutely nothing that I ever created with Rebol that I couldn't create far more easily and more effectively, with a better final product outcome, a better user experience, a more pleasant developer experience, better integration with other moderns tools, and acceptance in the most stringent modern production environments, using Anvil, for example. And there are endless goals that can be achieved without any challenge whatsoever, using Python, Anvil, etc., which were never practically possible with Rebol. So what's all the hate about? I don't work in any environment where anyone from any data-associated discipline complains about having to use SQL, or Python - we all just get work done, focus on communicating about requirements and providing solid solutions which work. When tools such as SQLPage, or some library which truly help enable people to contribute to completing projects, then we evaluate the potential for that tooling to improve outcomes. My developer experience with Python, Anvil, generative AI and other recent tools has led to a 100x-1000x better, more enjoyable, and more successful set of experiences than I ever had with Rebol. For people who choose to ignore that outcome, that's fine, I have no argument - there's just more work for me, where others can't compete :)
posted by: Nick 3-Dec-2024/21:54:58-8:00
Nick I love SQLpage. It's a fantastic solution to create Web Apps in no time.
I get it. You use Anvil and love it. You use Python and love it. You make a living with it. You can get things done. It's the perfect tool for your needs. It saves you time. Your clients are happy. You are a magnitude more productive then writing Rebol apps
As you said Python is used by millions of people and it has unlimited libraries. It can talk to any hardware and software. It's used in AI. It's used in schools. There is MicroPython to talk to IOT. It is popular worldwide.
I can't stand Python.
The redundancy and syntax.
Parenthesis, equal operators, $, {}, spaces and the list goes on.
Useless rules and verbosity, basically like all the other programming languages.
now:
Rebol
Powerful, Essential, Beautiful.
just the function 'Parse'. Shocking, Outstanding.
Amiga OS was created 39 years ago.
Rebol 29 years ago.
Still as of today nothing compares to it.
posted by: Adam 3-Dec-2024/23:17:52-8:00
Nick what do you think of Pocketbase ?
posted by: pocketbase 4-Dec-2024/0:39:09-8:00
Adam, I appreciate your love of Rebol's beauty :) I can certainly understand that point of view (and also your appreciation of Amiga OS).
Pocketbase, I think Pocketbase offers useful value for people who prefer to work visually. It's fast, has a built-in auth system, exists as a single small executable, and the aside from visual schema building, it provides an automatically generated web API for querying, which eliminates the need to write a lot of server code to handle typical CRUD interactions. Pairing Pocketbase with tools like Appsmith, Tooljet, Noodl, etc. on the front end yields some real productive capability, all using visual tools.
The main limitation for me with Pocketbase is that it only supports Sqlite, which is perfectly fine for many projects, especially since Sqlite introduced WAL, but I'm often required to work with MSSQL, Postgres, MySQL, etc., so that's kept Pocketbase out of my production work. I also tend to prefer working entirely with code, over visual builders, especially since generative AI's ability to produce SQL, SQLAlchemy, and other ORM code is improving so rapidly. In my experience, I'd much rather have GPT produce a schema and generate/optimize CRUD functions, wire them to UI code, etc., than to do any of those things with visual tools. I did some really deep query optimization work for a project this year, and GPT was a life-saver when it came to speeding up complex SQLAlchemy queries, adding hairy sort and filter features, etc. I don't ever want to go back after that experience. I find a lot of beauty and deep joy working with GPT and generative AI to create productive solutions.
The same project which required deep SQLAlchemy query optimization also involved setting up a system to help users generate and test generated queries using AI tools, as a replacement for visual query builders. I did a case study in which the generative AI solution was capable of producing far better results for users who had limited experience writing SQL code. We ended up building a system which enabled non-technical users to create and save queries, which could be evaluated by in-house tech staff who otherwise didn't have the time to do all the work. In that experience, generated code enabled more complex solutions to be approached by non-technical users, and enabled easier communication and collaboration with data&analitics teams, DBAs, etc.
posted by: Nick 4-Dec-2024/9:09:58-8:00
Pocketbase, one of the best things about coding with generative AI is it's ability to help debug. I haven't experienced any bang-my-head-on-the-table debugging sessions in a very long time. Pop your schema, code, and errors into a GPT session, and it will say 'the error you're experiencing is caused by ___, here's where the trouble is in your code, and here are the potential ways to eliminate that error'. And debugging help is available for much more complex problems than having an unnecessary semi-colon at the end of line 5832 (although even simple syntactic errors like that can cause lots of head-table contact).
It's far more difficult and time consuming to work with generative AI when schema, queries, and other pieces of an application are created with visual tools. Instead of simply pasting schema code into GPT, you have to take the time to explain, for example, all the columns and datatypes in a table, and for databases which have even just a few dozen tables with a few dozen columns, that can be a total deal breaker when it comes to working with GTP to create and debug code, because there's no code.
posted by: Nick 4-Dec-2024/9:25:50-8:00
Adam, agreed. Meta will get there.
I made a web server in Red. Part of that is already in the Meta CGI program that serves the Meta web sites. So far I use Caddy as a proxy to add SSL and request certificates.
I made SQLite bindings for REBOL 3 and Red. In Meta, it will be much more elegant and efficient because Meta can seamlessly integrate external data types.
I made an HTML dialect in REBOL 3 and Red that I use to write the Meta web sites.
Meta's development is aimed to port these technologies to it over time.
posted by: Kaj 4-Dec-2024/21:33:09-8:00
I don't know if Carl would have done that. He was more focused on his own things and the core language. Yet, the REBOL implementation prevents deeply integrating external data types.
And we made Syllable to compare to Amiga OS:
syllable.metaproject.frl
Admittedly, Syllable carries a mess with it because it is largely POSIX/Linux/GNU compatible, but the core OS is an improvement over Amiga OS.
posted by: Kaj 4-Dec-2024/21:42:44-8:00
|