Writing GUI Apps Using the Red Programming Language | Hacker News Reader

Writing GUI Apps Using the Red Programming Language

wesleyhill.co.uk

182 pointsstesch114 comments

For language enthusiasts, here are some interesting features of Red (and Rebol):

- 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.

To clarify:

- 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.

Thanks for the clarifications.

> 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?

Every word (the thing what author calls a "variable") has a binding. In short, it's a pointer to the namespace where value associated with that word resides.

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.

You can pattern match streams of values, and those values can be any lexical form that Red supports.

I'm not sure how easy it is to do DSLs. You don't see this popup in the Red or Rebol docs for a reason. It is homoiconic like Lisp, so it should be feasible. I'd love to hear some of the core devs like doc respond.

It might get hairy if DSL is non-trivial, IIRC Doc has plans to implement meta-DSL wrapper (a la Rascal) sometime after 1.0 launch to ease the process.

I hope Red puts up a couple of really simple examples on how to build DSLs. It's one of the great things Red/Rebol has to offer, but it isn't obvious how to do it.

I guess you can start with [1] and ask people in community, there may be a couple of simple examples to show.

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

I've tried asking the community before and the response wasn't good. With that being said, the links you sent were pretty nice, so thank you!

You're welcome! I actually rather interested in DSL creation myself and want to dabble my feet in this topic sometime. And I also feel that creation of dialects is rather obscure art for old-timers, and that there's a need for learning material.

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.

Sorry, I guess what I'm trying to say is I'm aware what a DSL is (like View dialect), but no clue how to start creating one other than it has something to do with blocks and Red's homoiconicity. There needs to be a specific spot on the documentation page that gives a good overview with simple examples and finally a more complicated one. In fact, I hope they do that with all the planned additions of erlang like concurrency...etc. You know what I mean?

How hard it is all depends on the DSL. I just found another article on HN and whipped one up as an example. See: https://news.ycombinator.com/item?id=16010971

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.

I don't see any reason why this would avoid the issue with every cross platform GUI toolkit: missing nuances that make apps written with it seem strange and foreign to each platform, even if superficially the appearance is correct.

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.

With the success of Electron apps (i.e. Slack), I am starting to think this level of OS/GUI Fidelity isn't all that important. As long as the application is attractive and does the job, people don't seem to care that much about it matching the OS look and feel.

I wouldn't pin the success of any app on Electron. Most would gain a lot from pivoting away.

This is a very common misconception these days, IMHO. "Because people just use best of what's available, I presume that they are actually content with what they have." Today another thread talking about web apps and the heaviness thereof, people suggest that given people use these apps/websites, they must really prefer these slow, messy and creepy things to plain, information-dense sources. This might be indeed true, but you can't conclude so just observing the status quo from outside.

instead of "best", I'd say people use what's good enough. electron is good enough for most people, and some people do notice the high resource usage, but they are in the minority, as most users don't attribute sluggishness of the machine on the app that's not slow (and electron can be made to feel fast if you know what you're doing).

Electron is not "good enough for people" because people don't know about it, or, to put it better, are not supposed to know about it. It's an implementation detail.

> 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".

Take a look at this article http://www.red-lang.org/2017/07/063-macos-gui-backend.html and see the info about rule-oriented rewriting engine that actually tries to deal with such differences. It's of course not perfect (Red is still in alpha), but it's not something that's being overlooked.

You can see how Red is starting to approach this in http://www.red-lang.org/2017/07/063-macos-gui-backend.html, particularly the Cross Platform GUI Metrics section. It is a really hard problem. Technically it can be done, if you put all the onus on the user. The more we try to do for them, the harder it gets. It will always be a balance.

Ah, I see @rebolek noted that as well. He always beats me.

> After trying (and failing) to wrap “executable” ducktape around a Python script using PyInstaller on Windows

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

Iniatly I was excited by Red’s expressiveness, ease of use and cross platform capability, but was very disappointed to find it lacks a driver for PostgreSQL. This for me is critical and surprising omission, especially considering that the main developer of Red - Nenad Rakocevic - wrote a Postgres driver for Rebol??

Lack of drivers and such is due to the fact that full I/O support is not yet implemented, but planned. See:

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

In the past, when I was writing web scrapers and I wanted to put the results into a database, I was just using the command-line interface for the database via the Rebol `CALL` function. It was a couple of lines to create a `SELECT` and `INSERT` function to abstract this detail away... If you are really curious about Red, you should give this approach a try and in case it's not performant enough for you, then you can put this option on hold until Red has proper I/O support.

@badsectoracula's comment resonated with me, and obviously many others. VB was transformative. Since then, people have tried to recreate that magic. Hasn't happened. Other transformative magic has appeared but, to build on what @badsectoracula said, people miss the point when trying to recreate VB (or other magical things).

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.

I always wondered why there has been no real successor to VB. This looks promising!

The syntax of Rebol, its predecessor, was an inspiration for the Mathematica language.

According to Wikipedia, Mathematica was initially released in 1988. Rebol was first released in 1997.

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

Rebol also influenced JSON, according to some people, per links in this post (on my blog):

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

I expect something equivalent or better to come out of what is happening with WASM in next year or so.

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.

Sure, there's going to be a bloom of compilers of anything to WASM, but what's discussed here is the opposite technology: lean native applications.

The reason these post-2005 cross-platform envs have gained no traction is because so many devs won't move away from browser - or even consider alts to a browser exist. Suggesting something not SAAS, PAAS etc. right now in most enterprises won't do much for your career.

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.

Last I looked I could not find a garbage collection solution for wasm, and that seems to be a barrier to entry. I know the mono-team has had some success by porting all of Mono to Wasm but that seems a bit heavy handed just to get VB.Net or C# language to compile down to wasm.

It's not a now solution - but from the trajectory you can see where this likely ends. It may even be the case that the current WASM specification does not support everything needed for that to happen.

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.

I would use Xojo for a "successor".

As I mention in my other comment, take a look at Delphi/Lazarus for the VB heir!

Check Gambas if you're interested in a similar language/IDE concept. It's Linux only, but I thought it was pretty cool for quickly prototyping GUI applications, although I do prefer the more mature FreePascal/Lazarus combo.

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

The thing is, a real successor to VB wont be a programming language because VB's strength wasn't the programming language part (if anything, it was one of the weaker parts) but the ridiculously simple GUI designer and COM/ActiveX that allowed people to compose applications out of reusable components (be it controls or just pieces of code).

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).

Interesting comment. Lazarus and Free Pascal are good, alright. (With some issues, as any software has).

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.

Alan Cooper has written about the early history of Visual Basic and how it came to be [1]. Two things i always find interesting was that in his original prototype he didn't use a language at all, but instead used arrows between controls to connect events with methods (i remember seen something similar in an ancient version of Smalltalk for Windows 3.1 that i found in a magazine cover disk back in the 90s) and that in the original version after Microsoft started working on it, it wasn't only the controls that could be extended via DLLs, but also the language itself. Both of those didn't make the cut for VB1, but personally i find them interesting as ideas since they seem to fit well with the overall theme extensibility VB had.

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

Interesting info. I remember reading parts of this, but not about the multiple languages (from your previous comment) and other stuff, like extending the language itself. Thanks.

Wish I could give this comment +10.

Lazarus, Xojo, Gambas to name a few.

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

Delphi is still around.

Red is awesome. Why it's not hip it's a mystery to me...

It is a chicken egg problem really it is the same like Nim, Crystal etc

I feel like both of those get more attention than Red does. I've written a bit in both, but completely forgot Red existed (sample of 1, yada yada).

I've heard of both of those, but not Red. So n++, I guess.

It doesn't even have GC yet.

Like C or like Java with the GC turned off?

C has alloc and free. Red is supposed to be garbage collected, so there's no free.

How come Red doesn’t have a GC then? If Red doesn’t have free, does it just leak memory?

It's like there's an echo in here.

GC will come. It just hasn't been needed yet for Red to continue its own development. If you write in Red/System, the C level dialect, you have `free`.

I guess I’ll try asking this again: How come Red doesn’t have a GC? If Red doesn’t have free, does it just leak memory?

Yes. Last I checked, it just leaks memory. It doesn't have GC because it's a new language that is under heavy development. It doesn't have a lot of things that any sane language must have before 1.0. Give it time.

First version of GC (and maybe some memory-management natives) will be integrated in 0.6.4 release, meanwhile there's some bag of tricks and conventions (`/into` refinement, creating series with `make ...`, etc) you can use to avoid additional allocations (almost) entirely.

There isn't much reason to give unfinished language (0.6.3 version as of now) lots of exposure, since lack of useful features / libs / docs / etc might be a potential turn off. Usually everyone starts to jump on a hype train prior to 1.0 release.

I tried installing the Windows version of Red but Avira blocked it as a trojan (TR/Crypt.XPACK.Gen2). Any thoughts?

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

Yes, Avira, Avast (and recently Norton) give us a ton of headaches because of their bad heuristics.

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

In case someone wants to ask specific questions about Red, you can drop in gitter chat and say "Hi":

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

I really miss an awesome cross-platform GUI. Electron is awesome, but bloated.

Agreed. But Electrcn seems to be the only option these days.

Really? It seems like there are a plethora of options. See an endless list at: https://news.ycombinator.com/item?id=12376242

Unless you want to move beyond HTML and JavaScript.

Actually no. Electron is the hipster/trending one. Unfortunately it creates monstrous applications with hundred mb sized binaries and gb memory requirements.

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!

Electron is chic because it looks nice and it feels nice ...everywhere. Until it does not and then the costs of doing it in smh else are too high

Looks nice: agreed.

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 :/

A lot of people care about looks and ergonomics before performance. I am not one of them but seriously people like shiny things. Even tech users like good UI before having to use your traditional shitty gui but performant app.

They will start caring eventually. Even ordinary people got turned off of bloated-feeling Java apps on the desktop.

Not this tech user and not tech team either. I value my time and a shiny slow UI and often even a good slow UI does not help me with that. My go to tooling to 'get shit done' with my team looks awful and is extremely condensed (one of the forms is one of our 45 page apps condensed into one page) but it is far faster to work with than anything like the shiny things we ship. Both are fast but the none shiny versions are much faster (in everything) because they use less resources, no images etc, so that saves time too when you are working and quickly need to check some flow. Also on slow computers.

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.

The sad news is, we're the last 2 people on the planet to know what Delphi was.

three

four

You mean, the last 2 people in this echo chamber (outside of which there are orders of magnitude more people getting software stuff done) - there, fixed that for you.

Electron is pushed by JS devs because now they can target another platform with their toolset. The JS crowd is rather large. Sadly, Electron style apps aren't going to go away any time soon.

I hate electron apps ("Simple and light-weight SQL client" is 200MB [or more, because it filled my drive]), but understand why they are used. Creating a good UI is just so easy for JS devs. There are tons of libraries and the web compatibility is an extremely powerful point. I'm really still looking for a solution that is fairly light weight, ease-of-development focused (-> encouraging good code, many don't seem to be) and supports the web as a target.

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.

Agreed re. JavaScript, which is why I use Reason (ReasonML if you want to google it) with React and ReactNative. Ocaml but with a syntax that’s easier for my team to swallow, compiles to JS. The Bucklescript team deserves all the nice things in life for their amazing work!

It's OK if they don't go away. We just end up looking better (and having more fun doing so) in comparison. :^)

Qt with QtQuick is awesome, and not bloated :D (as in, it's good enough to work at very decent framerates on embedded systems)

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

Qt quick is cool, but I never got it running quite perfectly. The examples struggle with the installed libraries, the android support needs a ton of work to set up, they copy the bad parts of javascript ... I like it, but it really frustrates me. There's also little blog-style content about it, which is by far my favorite way to learn.

Always glad to see Red get some more attention. I think these little lightweight apps are the way to go for sure. I like freePascal + Lazarus too, but I wish they made certain things easier. Red's syntax isn't a silver bullet, but I like how they have DSLs for so many things and native data types for things like email and web scraping that would require libraries in other languages.

>I like freePascal + Lazarus too, but I wish they made certain things easier.

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).

Hard to describe the beginner experience with FPC (nice acronym) + Lazarus and Rebol. Rebol has a lot of sites showing you how to build simple GUIs fast although some things are getting old (had trouble getting the native email functionality to work). So more beginner friendly doc would help both projects a lot. Also, I think it would help pointing out that certain things like connecting to an Oracle db are easy in C#/Java, but aren't obvious to me with FPC.

Got it, thanks. Yes, there can be such issues, with any project, but to some extent or in some cases, more with open source projects, particularly those without funding or good management - though of course closed source projects are not immune to such issues either.

Agreed!

>(had trouble getting the native email functionality to work)

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.

I was just testing out the language a year or so ago, so it wasn't super high priority to get it to work. I didn't try very hard. I think you need to configure your email + password in the Rebol tool itself and it should work. Unfortunately a lot of the pre-packaged demo scripts call out to parts of the rebol site which no longer exist, so a little bit of bitrot.

One big problem there is that protocols aren't sitting still in time. As more things change, like moving SMTP to ESMTP, Rebol needed to keep up, but didn't always. R2 was closed source, which didn't help. The protocol schemes were all written in Rebol, so you could hack them, which many of us have done over time, but that was an area where docs were lacking and sorely needed, so not many people could do it effectively.

Makes sense, thanks.

HaxeUI is another cross platform option: http://haxeui.org

How is the development experience with haxe-ui? Is it trully write once then deploy to all without any need for tweaking quirks on each of the target specifics?

It really looks like it by the website, but I haven't seen anyone use it in the wild. I'm interested as well.

The author gave a good overview of the framework at last year's Haxe summit: https://youtu.be/xU142SldYsw

what about tcl/tk for GUI? mature, fast, and ubiquitous

Also atrocious looking and alien feeling on every system.

Are you recalling the 1990s, or contemporary Tcl/Tk [0][1]?

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

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

I am using python to wrap Windows-C this week. I tried Idle again for the first time in years. Its text navigation is nasty, and caused me to go to shift editor. For example, ctrl+shift+arrows highlighting is something I do all the time and Idle's behaviour is inconsistent with Windows convention.

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.

quite frankly, the two screenshots you posted are atrocious and a good reason to show people why one wouldn't use TCL/Tk

Genuinely curious - I’d like to see a more in depth criticism and/or compare/contrast side-by-side.

* the spacing between items is entirely wrong

* 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.

Not true. It uses native themes under Windows and OS X.

http://www.tkdocs.com/images/idle_onewindow.png

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.

Can you expound on that?

tk works with multiple script languages and does have a nice looking these days, probably not fancy, but get the job done quickly and good enough for most use cases.

I've written a few minor Tk based apps in Python and if you look at Rebol (Red's ancestor) it is much much much easier to build a similar GUI. This Rebol guy has several sites where he builds dozens of small applications that are almost freaking one liners:

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

Digging the bullet point about Haiku support. Hoping someone in that community pays attention to this.

As we are citing alternative options, I've only tried the IDE once, but if I'm not wrong Eiffel is another cross platform development/environment...

I'm incredibly excited for Red's use for exploit development, as a security researcher having a tool like this can make things move along quite well.

Sarcasm?

Very serious.

Whoa! For a second I thought the meant RedCode [1]. That said, the Red language looks capable and brief. I am intrigued.

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

I have never even heard of this one. <shrug>

Reply on news.ycombinator.com