- You can pass unevaluated expressions to functions, which can then choose to evaluate the expressions any way they want. This sounds similar to 'fexprs' in some lisps.

- Scoping is very 'flexible' - you can take a function body and evaluate it in another 'context' which provides different values for all the words in the body.

- Making mini dialects (DSLs) is supposed to be easy and seems very common. It uses the `parse` function, which is a dialect used to define dialects. The parsing model is PEG like. The `view/options` for instance is a dialect being used for defining the GUI in the linked post.

- Red/System is a dialect for system programming (C-level semantics, and performance)

Overall it's a very interesting language and very impressive that it's also compact - the binaries are ~1MB on each platform.

- unevaluated expressions are called blocks, and with them the line between code and data blurs, since you can treat block as either one at any time (homoiconity);

- there're no scopes, only namespaces (contexts);

- yes, Parse is one of the Red's crown jewels, many people (and author of the article himself) treat it as some kind of "plain English regex", while in fact it's not limited only to string parsing, but can be applied to any other series-like value and code (i.e. blocks) itself, which allows for some cool metaprogramming tricks;

- R/S (without any optimization layers whatsoever) is 2-3 times slower than C.

> it's not limited only to string parsing, but can be applied to any other series-like value and code (i.e. blocks) itself

Sounds somewhat similar to OMeta (http://www.tinlizzie.org/ometa/) which can pattern match streams of objects.

With contexts it sounds like almost every word can be late bound? Also it seems blocks and contexts are decoupled which means you could evaluate multiple blocks from different parts of your program in the same context, or give each a unique context, etc?

Blocks can nest any other value, including words. At any point in runtime you can change this pointers (bound word to some value) for every word in a block or for separate words.

It's not black magic, by any means, but it's also not yet point and click. We'll build more tools, higher level pieces, and more in the future.

[1]: https://github.com/red/red/wiki/Red---Rebol-Dialects:--Selec...

With that said, I would appreciate if you'd listed what would you like to see in "How to bake DSL with Parse" guide of some sort, that would be really helpful when the time will come for writing tutorials and documentation.

Minor things, like common layouts, keyboard shortcuts, or just ways of doing things in general ("get info..." vs "properties" comes to mind) are a few of what cross platform toolkits never get right.

> sluggishness of the machine

So say a machine with 4GB ram and a decent 4-core CPU around 1.8 GHz is sluggish? Let's honestly say "we're sacrificing resources on the client side for ease of development on ours".

Funny. I just started working on an open source solution to that exact problem: https://github.com/mherrmann/fbs

https://trello.com/c/Iz0cl1e8/61-070-full-i-o-support

Technology doesn't exist in a timeless vacuum. VB was in the right place at the right time, and solved a big problem. Solving that same problem now isn't nearly as magical. We have new problems. Still, what people miss is that a person (often brilliant) has a vision and creates it. The result has conceptual integrity and resonates with some people. Not all, but some. The goal is not to be all things to all people. That never works.

I loved VB. Still do. I used it from v1.0 thru v6, and was one of the first 4 VB MVPs when they created the MVP program. As badsectoracula said, it wasn't any one thing that made it special; it was the whole. But, just as the Director's Cut of a movie isn't always better, there is the possibility of taking something and making it better. Maybe not in the visionary's view, but for others. A tale as old as time.

There is a time to hold tight to the past, and a time to move forward without forgetting it.

There is a time to fiercely defend our position, and a time to give way and relinquish victory in small battles so that we may win the war.

Red is still very young, but Rebol's design is old. The problems Rebol aimed to solve were like classics in literature (or algorithms in CS), long-lived. Red is not aimed at solving only today's problems, or tomorrow's. It's aimed at solving the future's problems. Not by being one amazing product or technology, but by being a language we can use to communicate about problems we don't even know we have yet. For most people, though, it can serve very well as a tool to solve problems we have today, without knowing any of that.

http://gambas.sourceforge.net/en/main.html

We don't have a real successor to VB (yet) because people always tend to overlook things and only focus on specific stuff, like the language or the form designer but those pieces weren't what made VB, it was the entire package - take a single element out and it falls apart.

Things i've seen people do in attempt to recapture VB:

* Start writing a compiler. The compiler part of VB was an afterthought (and wasn't even there in VB1-3), the important part is the IDE. Whenever i see someone trying to remake VB by even thinking about a compiler first, i'm certain that it'll fail (even if the project is made, it wont be VB, the developers' hearts are not in the right place).

* Ignore the "live" aspect of working with VB, like the ability to pause a program, modify it and continue or to execute statements, pause on errors, modify the code, continue, move the execution pointer around, modify variable values. You are interacting with a live system, there is no edit-compile-run cycle, it is just edit-run. Most attempts try to separate the IDE from the runtime, as if you were writing a C program with a form designer bolted on. A better system would try to eradicate the difference between designtime and runtime (e.g. allowing modifying forms while the program is running), not introduce additional steps or separation.

* Ignore the IDE. It was named "Visual" Basic for a reason. The documentation calls editing the forms as "painting the GUI" because it is a visual process. The IDE tries to make things as visually seamless (not always with success, TBH) - the form designer is the form itself, placed wherever you place the form (later this was diluted a bit in VB5 but you could switch to SDI to get the real deal), double clicking a button has you typing the code immediately for that button (or any other control's default event), you get a property panel with live editing of properties and in later versions (VB5, VB6) you even get those properties categorized, etc. You get a visual browser for every available class, method, function, etc available even with some brief documentation.

* Ignore extensions and composition. The entire reason Visual Basic exists is that Windows 3.0 got DLLs and someone (Alan Cooper) came up with the idea of using those DLLs to create reusable visual components. While Visual Basic does have a handful of "internal" controls (labels, listboxes, scrollbars, edit fields and a couple of others), most people using VB use external components.

* Try to make it possible to do everything in it with the apex of that being trying to write the language in the language itself. VB was the best example of a right tool for the right job - and an example that was very often ignored. VB's best use when was it was used to create front ends to machinery written in other languages that were better suited for the task. Sadly Microsoft dropped the ball here and made it too hard to expose components to VB since COM/ActiveX was a PITA and the only alternative was using DLLs (something they made way worse with VB.NET and C# by allowing only DLLs). This is something i never understood - they had their own C/C++ compiler, this was their own language, why couldn't they add an "add C++ header" (or just C header) command in the project window and have the IDE automatically parse and expose to VB whatever defined in the header? Even if it was only a subset of it (i wouldn't expect macros to work for example) it would be much easier. I believe that this is what led many people who otherwise should have known better to try and do too much in VB - because using another language had a lot of friction - and as a result, people who want to "revive" VB, try to solve the issue by improving the "do everything in VB" part instead of making interfacing with other languages easier.

* Focus too much on the language. This is really related to the first part, but really, i just cannot stress how often people miss the forest for the tree when it comes to VB - many programmers are attracted to VB's language like moths to flame. Originally VB was supposed to have pluggable languages and i don't know why this idea was scrapped - i'd guess it would make learning the system harder - but it is a testament to how unimportant the language was to the entire package.

* Try to bolt an existing language that simply doesn't fit. I'm not going to give examples for those because i don't want people to focus too much on defending their favorite language, but while the language isn't that important, it still needs to feel right at home with the rest of the package - especially the IDE. Every feature of the language needs to be able to be represented in the GUI itself and that without being overwhelming (to understand what i mean with overwhelming, imagine working on an XML document produced with LibreOffice with a plain text editor - the document is technically a text file and you can technically edit and even write new parts on it with the text editor, but it is clearly not a good fit. Similarly it isn't enough to be able to represent the language in a GUI, its features also need to be a good fit for visual representation through a GUI). Note BTW that taking an existing language and altering it to make it a better fit might work (after all that is what Microsoft did with BASIC).

There are other things of course (and i certainly do not include the most common case of people starting with an idea and going nowhere - but i suspect an easy language like VB attracted a lot of people who simply didn't know what they couldn't do), but the above are some of the main stuff in my mind (and this post is already too long).

Personally i find the desktop development process today a broken mess and most "modern" approaches to really be rooted in 70s mindset. GUI is by its nature graphical, making GUIs should be graphical itself - yet most systems regressed to text based descriptions.

The best system in active development today is Lazarus with Free Pascal. It is far from a VB alternative (despite how much people compared Delphi - Lazarus is practically an open source cross platform Delphi - and Visual Basic back in the 90s, the only common those two systems have is that they use form designers that if you squint hard enough look kinda similar - everything else is different) and IMO doesn't even reach Delphi 1's level of integration, it is kind of a mess in several places (some due to Free Pascal having a kitchensink philosophy, but also some due to just plain old sloppiness) and its cross platform support while there, has issues on anything except Windows (and personally i dislike how the only backend that really works on Linux is Gtk+ 2 and that they do not focus on their own backend - but that issue i have has a lot to do with how broken and hostile to backward compatibility is desktop development on Linux).

Still, i do all my complex GUI stuff on Lazarus. Now and then i also work on a GUI toolkit that i hope one day to use to build my dream GUI development environment on Linux (so i can finally get rid of any Windows dependencies) although the entire Wayland story with all of its limitations and other issues puts a major block there (and makes me lose my interest on Linux desktop altogether).

IIRC, VB's initial code name was Thunder. I worked on VB in a few commercial projects. Alan Cooper demoed VB 1 to Microsoft and they bought it.

[1] https://www.cooper.com/alan/father_of_vb.html

So many people are talking about missing the power of VB, early Delphi, Turbo Pascal etc. and WASM is first tech for a while that looks like it could take that power to the browser.

WASM kind of fixes that - it takes that 90s/00s native speed into the frontend of the moment and makes complex UIs more viable. Any dev with more than 20 years experience shakes their head that it takes WASM to make that happen - but I'm just grateful it is.

But if you look at the DOM and what Anders Hejlsberg was working on 25+ years ago with early Delphi - you can see a potential real step change from WASM - especially for enterprise tech to bring back some of that VB magic.

A lot can also be done with an interface designer like Glade.

Delphi is still around.

Maybe Rebol inspired some part of Mathematica that came later, like the manipulate/dynamic system?

https://jugad2.blogspot.in/2012/12/rebol-language-that-influ...

Edit: I found this https://github.com/red/red/issues/2399

Just to show you how they don't really care, here's a tweet discussion with Avira (dated July):

https://twitter.com/red_lang/status/887970289618829312

https://gitter.im/red/red/welcome

Here's a simple example: https://github.com/jcelerier/TodoMVC-QML

Notice how the whole thing is a bit less than 150 lines, whereas for instance a Vue.js (the web framework the closest to QML in concept I'd say, though JSX is also not far) implementation is around 200 lines with HTML / CSS / JS (even though they say 120 lines?) : https://fr.vuejs.org/v2/examples/todomvc.html

Thanks but no thanks.

On the other hand Delphi and its open source brother Lazarus are creating real (not html ones) native apps with sub mb binaries with minor memory footprints using a great IDE that reminds me of VB6.

This is definitely the way to go for desktop apps!

Feels nice? Try running an Electron app (for example atom or VS code) on a 4gb ram celeron (like the one I have at my 9-5 work) and I can guarantee that you won't like the feeling :/

I agree a lot of people care about looks and ergonomics, but none tech people complain about Electron apps: a lot of people know the standard things on Windows and these apps behave and look different. For young people this might not matter, but 40+ none technical friends ask me for help a lot with these none standard things where there is no normal menu or preferences is in a different place etc. I tell them to think of it like a webpage and not a Windows app. But it is a Windows app...

It is probably too late to turn things around, but I hope people keep trying. I will anyway. And these kind of articles (and Rebol) give me some hope.

Kivy is looking to have good principles, but the standard UI kit is quite awful. Supports popular targets except for the web. Qt quick (controls) enables both a good desktop feel and an aright one on mobile platforms. Doesn't support the web (but PureQML is an effort to port the language).

Haxe looks promising but public adoption, for some reason, seems very slim. Adobe Air and things like that promise similar things, but example apps are complete garbage.

React Native works quite well on mobile. There could probably be a similar effort on the desktop, it's surely possible to do something - but then again I'm not a huge fan of javascript either.

I have started doing projects in a browser myself because it is so easy to get started and share what you made, so I can understand that people would want to just use the work they did and bundle it up for shipping. It just looks like something could be done for Electron to lose some weight, at least. Why does it require a Nodejs environment and a browser for every app? Why not adopt the browser model of feeding apps into one renderer for display? Things like that. Maybe they'll wake up some day.

Which things? Interested to know, because I too like both Red and FPC (I use FPC to make it easier to distinguish Free Pascal (Compiler) from FP for Functional Programming).

Interesting. Did you manage to solve that? I had tried out a good number of Rebol features earlier, including some Internet ones [1], but do not remember if I tried email and if it worked or not.

[1] Pretty cool that you can do many Internet operations in one or a few lines of code, and also I like the functional / Lisp-y aspects of Rebol (and hence Red), and the minimal syntax.

http://guitarz.org/howtomakeaprogram.com/howtomakeaprogram.h...

http://easiestprogramminglanguage.com/easiest_programming_la...

http://business-programming.com/business_programming.html

http://personal-programming.com/personal-programming.html

[0] https://en.wikipedia.org/wiki/File:Tk-Demo_using_Tk_8.6.6_on...

[1] http://www.tkdocs.com/tutorial/idle.html

It is hard to know how to make it mainstream from where it is. If they changed keyboard behaviour to align with Windows-convention, it may annoy parts of its existing userbase who have become accustomed to it.

* the bezels don't look native (but look pretty much like 1990 toolkits like Motif)

* In your first screenshot:

- The checkbox seemingly changes size whenever it's checked or not.

- Likewise for the radio button, and the "small" one for some reason seems aliased or something like this.

- The small Tk logo in the tree view is also aliased and let's not talk about the canvas which looks like it's taken straight from a 1990's example.

- The tab sizes are weird and the spacing between the icon, the text and the border is uncanny, to say the least. Here's some example with Qt : https://i.stack.imgur.com/eoHaS.png or GTK: https://lists.gnu.org/archive/html/emacs-devel/2010-04/pngNP...

- The form containers (Label 1, Label 2, Label 3, Label 4) all have different sizes ; their bottom should be aligned.

* For your second screenshot, hre's another one fairly similar in concept (looks like it's made with GTK), but much prettier:

https://i.stack.imgur.com/7v6Ja.png

The most blatant thing is that the label "Direction" isn't aligned at all with the widgets that follow it. The placement of the widgets seems quite random, too. And why is there so much vertical spacing between the three rows of widgets ? But overall, notice how all the widgets in the GTK one line up nicely and have consistent margin and padding.

As an example I did a rough sketch (without caring too much) of the UI of the first screen shot with Qt. It took me 17 minutes (http://sendvid.com/f6gbp6el), with no prior try and without of a lot of habit with the Qt designer: https://i.imgur.com/4MLh48R.png and already I find it to look more professionnal (except of course the goofy canvas try :p). Another fifteen minutes and I feel like most of the Tk ui could be matched without too much stress.

Sure it has “native” widgets... but the layouts created have horrible, alien spacing and design.

This is completely unacceptable look and feel for a consumer macOS program.

[1] https://en.wikipedia.org/wiki/Core_War#Redcode