TL;DR

• It wasn’t a design priority
• They use external toolkits that were designed for C, or something other than the host language
• They weren’t designed for building DSLs, which is where Redbol langs shine, and is key to the standard GUI system’s ease of use.
• They aren’t dynamic to the extent that attaching code (actions) to UI controls, declaratively is easy
• They lack a rich set of datatypes that make it easy to specify the most common attributes clearly and succinctly.

I love and hate anecdotal answers, but that’s all we really have in many cases. That is, we don’t have measurements, or even criteria for what “hassle” and “elegant” mean. I do think it’s possible, though, to find some root causes that lead to differences.

For context, I’ve been using Rebol since 2001, and have put a lot of R2 code in production through the years. I write R2 code directly, but have also used it extensively for code generation (e.g. C# and SQL). Prior to Rebol, I spent 11 years specializing in VB (and was one of the first 4 MVPs in the world for it), from v1 through v6. I’ve dabbled and tinkered in a lot of other languages, always looking for what fits best in my brain, is pleasant to use, and (subjectively) makes me most effective. Those criteria certainly relate to “hassle” and “elegant”, but doesn’t mean my choices will be the same as the next person. One man’s hassle is another man’s elegance.

The most direct answer to your question is probably: Because making an easy-to-use GUI system was not a priority for them. Many languages included them as an afterthought, or not at all. Most use an existing GUI system, library, or toolkit which was not originally designed for use with that language, so there is a lack of conceptual integrity and, often, an impedance mismatch when working with them. This is where VB was brilliant. It hid almost all the gory details. Having a drag-drop UI builder was wonderful as well, because you could prototype the layout of your GUI without worrying about any functionality. In those days (1991), the alternative (for Windows) was to write a *lot* of C code, with various window flags, hard-coded offsets, and a main loop if you wanted even the simplest navigation.

If, perchance, you peeked behind the curtain at the code VB generated in the %.frm files (after the %.frx binary-only format was done away with), you would see, lo and behold, a lot of the same kind of code. Different language, of course, and nice OO property syntax, with names instead of bitmask flag values. But all the fixed top/left/bottom/right values were still there. I was going to include a couple examples, but that’s another tricky area, and easily criticized (cherry picking things to make my horse look better). Instead, VB references notwithstanding, look at eugenkiss/7guis for a comparison of implementing various, small GUIs in different languages. Full disclosure: I am the author of the Red examples there.

Coming back to “Why”, languages are products of their environments and the times, as much as their designer’s preferences, skill, and experience. The GUI aspect is then either a separate “language” or system, or was part of the plan all along, so it could be seamlessly integrated with the rest of the language. The latter is the case in Rebol (and, by inheritance, Red), even though the core language came first, and the GUI added later. This was possible because of the fundamental goal of the language, which was designed for this specific purpose. Not GUI systems, but specific language domains. You may say to yourself “Bah! Lots of languages can do DSLs now.” True, to some extent, though some of it is marketing hype. So, tell me, how many languages have a core datatype built in that represents XY coordinates? Does that matter, if you use an OO language that can just create a `point` class? Hassle or elegance?

Languages are also subject to the vagaries of their hosts. Do you need to run in a browser (welcome to HTML, JS, CSS, and frameworks du jour). Do you need a native solution? For which OSs? Mobile apps? To design an elegant system takes time, effort, and, perhaps the hardest of all, patience. We also have legacy concerns. If you have legacy code, and now need to support a new GUI, what do you do? More than likely, you tack it on to what you already have. Did you plan for that? If not, you chip away at the elegance factor over time.

I will argue, though am happy to see examples proving me wrong, that complexity is not elegant. Rich Hickey gives a great talk about the difference between *simple* and *easy*, which is worth looking up. One way to avoid complexity is to limit functionality. This is the foundation of DSLs/POLs. Rebol 2’s GUI system was constrained by design. Other GUI systems were built for R2, but its standard VID system was good enough that most people stuck with it. Bumping up against its limits was not hard, but you could work around most of them. Then you decide if it’s worth it, when 98% of your apps work just fine within its limits. YMMV. Red’s GUI system keeps the same VID approach on the front end, but the back end is all native now, and it vastly extends the GUI capabilities. e.g., it has a reactive system built in, but reactivity isn’t just for the GUI, it’s universally available, built for general computation, with the GUI system leveraging it in that domain.

Red/Rebol are powerful in very different ways than UWP or Cocoa. There are some large-ish GUI apps written in Rebol, but the largest Win/OSX apps will dwarf them. The question is, what’s the best way to build any given app? I’ve put probably 300 KLOC of Rebol into production through the years. The largest single GUI app (doing a quick check) is probably about 10 KLOC. That’s a single app. I tend to build systems from multiple, smaller applications. In my VB days, I worked on a mortgage origination system, licensed to large banks. We had about 6 main apps, each of those may have used supporting apps (DDE for IPC). The largest VB FRM file I can find, quickly, is 3 KLOC. The largest single app, probably 20 KLOC of UI total. My largest Rebol system in production? I’ll estimate 75 KLOC.

I don’t think I’d want to go much larger than 20 KLOC of R2 GUI myself, in a single app. Is that limiting? I don’t think so. It depends on what you need to build, of course, and if a LOC is equal everywhere. I like the 7GUIs project idea, because it gives us a concrete comparison between languages. I encourage others to contribute, or point out similar projects.

Regarding scalability, R2 was not designed for PitL. Red will address that in the future. If you believe that “Sure, Red looks simple for small GUIs, but it won’t scale. Other systems are more complex because they’re more powerful.”, here’s my view. Complexity only grows. If a small app is complex, a larger app will just be that much more complex. Is C++ more powerful than Lisp? No. They are powerful in different ways.

Finally, something I think makes Redbol langs less of a hassle, and more elegant, is that you don’t have to context switch your brain between languages. If you think XML is elegant, and don’t mind mixing it with your .NET language of choice, in XAML form, more power to ‘ya. If you want to use C# to do all your coding work, that’s great. If you like the mix of HTML+CSS+JS+…, I can’t tell you you’re wrong. For me, the benefits I get from a simple toolchain (no external libs or toolkits), and a single language that I can use for almost any task (with Red, I’ll say any task, though it’s still Alpha and has features pending), reduce the hassle of building software enormously. The language design itself clicks in my head and, by virtue of matching my aesthetic sense, feels elegant.