1. 21
  1.  

  2. 8

    I miss REBOL. I’m the only person I personally know who ever wrote a large amount of code in it (an application of around 3000 lines).

    REBOL desperately needed a CLOS-style object system with multiple dispatch, so that new types could be defined (it had an object system, but “object!” was just one of many types, much like Common Lisp, but with CL and multiple dispatch, it wasn’t as difficult to make types act like objects and vice-versa more-or-less transparently).

    REBOL also lacked any concise, simple explanation of its scoping rules. There was a mixture of dynamic and lexical scoping and it was often unclear which kind of scope would be used.

    And finally, REBOL had a problem with programming in the large.

    At any rate, REBOL was a beautiful language and Red looks to be solving a lot of the problems (though last I looked, types were still special enough that you couldn’t really create your own first-class types). I wish them the best of luck.

    1. 2

      I remember using REBOL a while back. The issue I often hit was accidentally modifying literals embedded in the code. Once I remembered to avoid that I liked the language. So much functionality in such a small executable.

      1. 2

        That is one of the gotchas, that pretty much all newcomers fall into. We will make sure to address that properly in the Red documentaiton. Though, the explanation that wikibook gives for that behavior is not very right, nor clear:

        This happens because the salute variable is initialised to the literal string “Dear “, which is kept in the body of the function, and becomes a subject to change.

        There is no variable in Rebol/Red (strictly speaking) and no such thing as “initialisation”. Words can refer to other values, and there is nothing special about setting a word the first time. I tried to give a more in-depth explanation about that fundamental behavior and the rationale behind it in this /r/redlang post.

        1. 1

          Python suffers the same problem, of course: literal lists or dictionaries as default arguments to methods will be modified by subsequent calls, not created anew.

        2. 1

          And finally, REBOL had a problem with programming in the large.

          Can you elaborate on this? I’m not familiar with REBOL or Red enough to see what you’re getting at, though I have ideas.

          1. 3

            Primarily, modular namespaces aren’t really a thing. Multi-file programs aren’t even really easily-doable unless you buy the SDK, which includes a C-style preprocessor with #include.

            (Note that the above applies to REBOL 2. REBOL 3 added modules, but I don’t actually know if module support actually made it in to the released product or not.)

            1. 1

              Even without the SDK in Rebol, you can use do function to include any other files at run-time. As long as you wrap your code in objects, modularity is a not an issue, though you still need to be careful not leaking words in global space (you can make a one-liner helper function for checking that). So, a finer-grained and more structured control on namespaces imported/exported symbols would be welcome, that is what Rebol3 modules offer, and what Red will expand upon.

          2. 1

            Just for the sake of curiosity, what was your Rebol application about? Was it commercial?

            I know many Rebol users who have big or very big codebases (by Rebol standards). Red uses ~20k LOC of Rebol code for its toolchain, and I have several other codebases of 1-5k LOC. Some other users have developped apps in the 50-100k LOC range, used commercially, mostly in USA.

            I agree that the ability to define your own types would be an improvement, though it seems pretty low in the list of new features people usually ask for, in the community. Rebol/Red rely on single-dispatch over the first argument (for actions), so I don’t see how multiple-dispatch could be implemented in a language with free-range arguments fetching (no end-of-arguments marker), unless we can come up with an adequate syntax for limiting the arguments range, which would fit the homoiconic requirement. Anyway, the future, more restricted, utype! approach should be good enough, and allow users to implement their own highly polymorphic types.

            About the scoping rules, you’re right that a simple, but exhaustive documentation is missing, though the key point there is that there is no real scoping in Rebol/Red, only an illusion of it which we call definitional scoping, all words are bound at run-time, and the bindings can be changed dynamically at any time.

            For PITL, see my other comment below.

            1. 1

              The app was an integration with a Point-of-Sale system that ran on Windows. I briefly worked for a startup doing mobile payments (boy, that was a mistake). The app provided a nice UI on the POS for our payment network, and interfaced with the POS to settle payments.

              1. 1

                Thank you for sharing. I did build a POS using Rebol (using both native and web GUI) for a customer in France, 10 years ago, and I know of another big one built in the USA. It’s interesting to see that a number of commercial usages of Rebol ended up in that domain.

            2. 1

              While I won’t agree that Rebol (or Red) desperately need it, you can find some very nice experiments of CL features done by MaximV, at https://gist.github.com/maximvl. On objects, I found things got easier when I stopped trying to do OOP as I had done in other languages.

              When I found Rebol, I thought it needed some things as well, because I came from other languages and thought it should have things I was used to using. I did fill some of those gaps, but soon found that thinking in Rebol, and not trying to make it something else, worked better for me. It does mean we have to change our thinking. I would often rather change my tools. :^)

              The SO link Doc posted, and his short explanation, is about the best we have on scoping.The hard part, the really hard part, is that the “there is no scope” concept is tricky, because we want to hold on to our scoping mentality. And because Red simulates scoping so well, it’s easy to think it’s there.

              On PitL, I’m with you.Even without the SDK, you can use Ladislav Mecir’s INCLUDE system, or Max Adloch’s SLiM. Both work well. I’ve built moderately sized apps in R2. For larger system work, breaking things up into communicating processes works really well. There are significant apps and systems out there, so it can work. Saphirion AG has their NLPP app, Atronix their industrial control system, Prolific.com has a huge amount of Rebol on the back end. I just RAWKed (Rebol AWK) a few project dirs here. The numbers are hard to get, because of duplication in built/assembled %.r files, data files, generated code, etc. Using my best guess, I probably have 300KLOC of Rebol that has been used in production. To get back on topic, there are PitL features I want in Red, and will push for them myself.

            3. 3

              I love the fact that more programming languages are evolving the ability to build first class GUI environments without resorting to bindings to C++ libraries like QT and GTK.

              I’m still pulling for Toga - if they could get their documentation story together and improve ease of adoption a bit I think they’d have a real powerhouse there.

              1. 2

                I hadn’t seen Toga before. Someone should do a Toga version for https://github.com/eugenkiss/7guis/wiki.