I think the problem Espanso is trying to solve should be addressed by GUI toolkits, like GTK, QT, etc. Otherwise, living with an authorized keylogger in our system in order to introduce unicode characters seems overkill.

Yeah, I don't have my KDE setup in front of me right now, but I feel like there is something in the keyboard settings that could emulate at least a subset of Epsanso's features. I know on macOS/iOS there is text replacements which are a simple replacement mechanism, without the ability to insert variables.

I agree, though, seems like a ripe piece of low-hanging fruit that could be better integrated and safer. Even if the lower level stuff just hands it off to a dedicated tool that handles the replacement text, at least the OS/WM should be the one watching the keys.

This feature simplifies `while` loops in computation expressions

There several iterator libraries around but generics has made easier to compose iterators into a single one.

No it doesn't. It vanished from the known Universe and now we have no idea on how it looked before.

"playground of rich Americans": certainly a fallacious reduction of Cuban history. "The America gov't instituted an embargo. Being in the tropics, the electric signs broke down": you're seriously underestimating the destructive force of communism. osmay88: thanks!.

Substitute "communism" by "centrally planed economy". China abandoned it decades ago. See https://en.wikipedia.org/wiki/Socialist_market_economy

Certainly is hard to read nested code, but returning earlier makes it harder because now our mind has to construct the execution path instead of reading it. What I usually do is writing the body in a new procedure. Dijkstra designed a language with no return statement with a very simple semantics made for proving the program behaves exactly as its specification mandates. Niklaus Wirth designed Oberon with no return statement. Currently I write Go code only using return at the end of the procedure, my code is easy to follow and I have fewer errors than before https://en.wikipedia.org/wiki/Guarded_Command_Language https://www.inf.ethz.ch/personal/wirth/ProjectOberon/index.h...

Certainly is hard to read nested code, but returning earlier makes it harder because now our mind has to construct the execution path instead of reading it. What I usually do is writing the body in a new procedure. Dijkstra designed a language with no return statement with a very simple semantics made for proving the program behaves exactly as its specification mandates. Niklaus Wirth designed Oberon with no return statement. Currently I write Go code only using return at the end of the procedure, my code is easy to follow and has fewer errors than before https://en.wikipedia.org/wiki/Guarded_Command_Language https://www.inf.ethz.ch/personal/wirth/ProjectOberon/index.h...

Golang is not comparable, as you get to leave failures not handled explicitly because its goto-fail scheme. I mean, that's a very nice feature of Go, but not comparable.

The danger with early returns is failure to handle all cleanup. This is really a failure of many programming languages. Golang gets this right. But even so, I'd rather have early returns (or early goto-fails) than ever deeper if/else ladders.

Another option that works very well is this:

    ret = thing1(...);
    if (ret == 0)
        ret = thing2(...);
    if (ret == 0)
        ret = thing3(...);
    if (ret)
        <handle failure>;
    return ret;

"A Discipline of Programming" by Edsger Dijkstra.

Two years ago I felt just like you. It is overwhelming, there is a lot of people talking about the best approach, the best technology .... Don´t hear that, I am sure there is nice stuff around there, but what makes the difference is you. Thinking about programs is a nice advice, try to see things from different points of view. A year ago I did some hacking in Common Lisp and Haskell, that certainly changed my way of thinking. Now I am more interested in making things simple, I am hacking in Go now and trying out Plan 9, is really rewarding reading real world programs that are easy to understand.

Thanks. So are you suggest learning other programming languages that would oppose my current understanding, such as scripting and procedural languages to solve problems so my understanding is more diverse? Just trying to see what your suggestion for my next move would be. Thanks again for all of your help.

Just read a book like Practical Common Lisp, Land of Lisp or Learn Haskell for the greater good, you will learn how to do some interesting programs and you vision of side effects will change. I am trying out Go now, it is really nice too, if you want to read some code check out http://github.com/lamg/md2sexp, it is really easy to understand (but it does not work yet).

Looking at your known languages my advice is: * don´t make a world of objects and patterns (the gang ...). These stuff is advanced and you should be careful, there is no magic to solve all your problems. * KISS principle * do some data driven programming

And I forgot the best of all tips: good theory leads to good programs.

Thank you so much for your help. I will start looking into your suggested references. I know my Prior knowledge is in OOP but that is because it is the main focus these days for academics. Thanks again.