greggirwin

1) I'm part of Team Red. 2) You can like, dislike, embrace, or discount a language (or anything for that matter) for any reason that's important to you. 3) I'm not here to convince anyone of anything, just to provide some information and my own thoughts and opinions. 4) I'm not going to justify or argue the state of things in Red today. It is what it is. Lots of high level things are easy to talk (or complain) about, while some other really cool tech lives in the shadows, but is also important. 5) In Red we call embedded DSLs "dialects", just for clarity in what I write.

Red is more different than you may think, just by looking at it. It is designed such that things that look familiar may work very differently under the hood. That's good for making people comfortable, but also means you can't judge a book completely by its cover.

Red is a data format first. That's very Lisp-like, but Red goes further with the large number of datatypes that have a lexical form. e.g. email, url, pair, point, file, date, time, money, etc. Where Lisp* says code is data and data is code, we tend to say "Everything is data until it is evaluated." Rebol was only interpreted, but Red (not all Red however, as some things are too dynamic and require JiT, which we don't have yet) can be compiled.

Red compiles to Red/System (R/S) code. R/S is a static dialect (DSL) of Red, which compiles directly to machine code. No external compiler or C code gen. So you can write DSLs in Red, and those DSLs can be higher or lower level. We call this Metal to Meta programming. Compile a small R/S program, and you will see it's fast, and fully standalone. Compile Red in Dev mode, where the runtime isn't rebuilt, and it's also fast (after the first time). Compile in encap mode and...more to explain. Compile for release and it takes time, but gives you a standalone EXE. It's slow for a number of reasons. Just the current state of things. Compilation speed has not been a priority.

On APIs vs DSLs, a key distinction for me is that API don't have a natural way to enforce the order of operations. That's where a grammar adds value. And because Red is often self-consuming data, the ability to write grammars (`parse` rules) that are very BNF/PEG like, it makes data handling quite powerful. I also think it's easier than most other systems, but that's me, and I've been in the Redbol (Red+Rebol) world for a long time. Two related notes on that. 1) `parse` is, itself a dialect of Red. 2) You can parse not only at the character/string level, but at the value and datatype level, including literal values and typesets. Typesets are a way to express datatypes that are related. e.g. the `number!` typeset matches `[integer! float! percent!]` types. All that said, Red is a multi-paradigm language, including functional (though not pure functional), so you can absolutely build things in an OOP/lib/API manner if you prefer.

Infix came up, and the model is simple. Infix ops have a higher precedence than func calls, but there is no other operator precedence. Strictly left to right for ops. And, yes, operators are a datatype and you can make your own from most 2-arity funcs.

Func args are not enclosed in parens or brackets. This is a fundamental aspect that takes some getting used to. Once you do, at least from what I've seen through the years, it feels natural. We call this "free ranging evaluation" and it's a powerful aspect of Red. It also plays into dialect design. Red is sufficiently flexible that you could hack around this if you want, but then you're fighting the language, rather than working with it.

Red is high level and garbage collected, but it is not "safe" by some standards. Mutability is the default, values are strongly typed but variables are not, you can mix Red and Red/System pretty much however you want, and R/S is basically a C-level language. We talk about these tradeoffs a lot, and how to find a balance. Nothing comes for free.

One of the main dialects in Red, along with `parse`, is the `VID Visual Interface Dialect`. This is how you describe GUIs for Red's cross platform GUI system. You could also build a tree of faces manually, or write your own GUI dialect or API.

Another cross-platform note. Yes, we are 32-bit only at the moment. It hurts us as much as it hurts you. But Red can cross compile from and to any system it runs on. No other software or compilers needed; just a command line switch.

One of our primary goals is to "fight software complexity". That doesn't mean Red will look like C, or JS, or Python. It doesn't mean any one thing. It means a lot of things working in concert. We also hope to keep Red small and easy to set up. Today you can still just drop the EXE somewhere and go. The toolchain (interpreter+compiler) is ~1.5M and the REPLs (text mode and GUI mode, separately) are just over ~2M. We may offer more options at some point, ideas like using LLVM come up a lot. While they solve some problems, they create others. So far, the costs have been deemed unacceptable, and we don't have any showstoppers (other than time). But since Red is open source, with a permissive license...

Happy Reducing!

Those are the same project.

They generate the same type of syntax diagram, but are otherwise...quite different. If you read the product page it should hit the high points.

Thanks @9214. I must have blocked it from my memory.

So you're changing your argument now, that's fine.

Let's see. Java? Python? Ruby? JS? PHP? Any .NET lang?

Go is on the rise, yes. As is Rust. But D? Nim? Do you really consider those major languages?

Enough silly arguments though. We think it's special to offer options, because one size does not fit all, but we hope a common syntax can fit most. So you have the option to 1) use an external runtime, which makes all your EXEs tiny (say they run in a common system, even against a custom Red runtime you build); 2) compile to native code and get a single, no dependencies, EXE; 3) "encap" your code with the compiled runtime so you can leverage all dynamic features of Red, some of which can't be compiled; 4) compile the runtime so it can be accessed from other languages and environments. 5) Write in pure Red/System, which is basically like writing in C. Maximum control, no high level features. Tiny EXEs, no runtime, fast compilation.

- https://www.red-lang.org/2017/03/062-libred-and-macros.html (please note the Excel+Red Pong demo)

That's what we're trying to find out. :^) In many ways it is a guinea pig, and something we wanted for ourselves. Very niche, to be sure, but if you've ever had to write grammars, the alternatives are EMACS/VIM + YACC/Bison or XText if you're in the Java world and can be locked in and handle the weight.

It's funny to me what a tough sell it is, but that's true for all new dev tools. While the main purpose is to help anyone, whatever grammar they choose (ABNF, EBNF, etc.), it all compiles down to Red `parse` internally, so if you use Red, your parser is already done. If you use the native `parse` rules to begin with, you can even include actions. Testing in it is cool too. But really it's to try and get people to see that documenting your design (meaning you have a design to begin with), is valuable.

Did you notice a) that the ticket is closed, and b) it was a bad ticket to begin with? See this comment in there: https://github.com/red/red/issues/3412#issuecomment-39595136...

Yes, if you rebuild the runtime when you compile, it's slow. If you use dev mode, because you're not changing anything in the runtime, it's fast.

Something like that, yes. Red has macros as well, with a key difference being that at compile time, for all macros, there is no runtime context to bind to. Sometimes this helps, sometimes it's a limitation. For example, interpolation at runtime can be tricky, but isn't as flexible if done with macros.

64-bit is high on our list, but also a huge task, so needs a large block of time where other things won't get done. We have some big features we're pushing on now, and will update our roadmap accordingly.

Automated builds are the way to go. We're revamping our release process to avoid stale-binary syndrome. If you don't follow us on Gitter, where you'll see active chat every day, you can look at https://progress.red-lang.org/ to see what's been done. Or just look at github graphs of commits.

We absolutely lost some focus with the blockchain aspect, and are rolling with all the punches as best we can. Sustainability is key, so we're also working on commercial products to that end. Got our first one out last year, and the next one is in the planning stages.

Our first product is https://www.redlake-tech.com/products/diagrammar-for-windows..., and all features are enabled for free. The only limitation is that exported images are watermarked. We also sponsor licenses for other FOSS projects.

Of course we have to define "new". And consider that it was new when that was written. :^)

It shares syntax with Rebol, 95% of it anyway, but many other "new" languages share syntax with older languages. In any case, there are many new things about it, including being a from-scratch implementation.

- Native GUI system (non-native in development for those who want to go that way) driven by a GUI DSL, with full reactivity built in. - Reactivity and ownership features are built into the core object datatype, so they can be used for more than GUIs. - System level DSL. Red/System is a C level language, but is a dialect of Red. It compiles directly to machine code, not ASM or C. Cross compilation is built in as well. Again, no external tools needed. - Android is out of date, but it also requires no JDK or other IDE.

So there are at least some things that make it new-ish.

I've done this quite a bit in Rebol and more recently in Red. The reason these languages work well for this is that you can dynamically build the GUI layout in their DSL for that, which is easy and concise. But you can also build the tree of faces directly (as the DSL does internally), if you need more control.

https://gitter.im/red/red/help is a good place to ask for ideas and examples.

Full disclosure, I'm on the Red team so my biases are pretty strong. ;^)

One of our team summed it up very nicely: Pragmatically, this design notion comes from Red being a data format first (code is data and data can be used as code). To mimick scoping at data level, context has to be implicit. As a consequence, any block of code e.g. [take the spoon] can be passed around, evaluated on demand in any place, used in user-defined custom loops, without losing the original meaning even if all it's words `take`, `the` and `spoon` were defined differently in those loops or other functions.

Rebol's designer called this "definitional scoping". What it means is that where a word (variable) exists is important. The "where" part leads to https://github.com/red/red/wiki/%5BDOC%5D-Why-you-have-to-co... and is one of the big things that messes with your head when you come to Red from other langs. :^) For many people this stays invisible forever and things just work. But it doesn't take much for people to step off the ledge and into deep water, because things look so easy and it seems like you should be able to just pass blocks around and have everything work magically. It's internally consistent in how it works, but that's hard to see without tooling we have yet to build.

Rebol2 was closed source, and is no longer maintained. Red has a non-restrictive license.

I hadn't seen docopt before, but am curious why you think it's such a bad design.

https://libraries.io/ ?

Another way to look at it is that you need a reason for people to use your language, not features. C didn't have tooling to start, JS didn't have an ecosystem, VSCode is only a few years old, so there is the short view, and the long view. It's nice if you live long enough to see your work appreciated, and perhaps even benefit from it. Think true artist versus imitator. Engineers would say "Design for what people think they want, based on what they've seen before, or design for what people need, but they don't know it yet."

Familiarity helps, which is why so many langs follow historical syntactic and semantic rules; and what makes it hard on languages that are either different themselves, or target a niche domain. This includes languages whose paradigm is harder for mere mortals (the vast majority of us) to grasp.

There is also luck and timing. Backing from a big company doesn't hurt, but those langs (Swift and Go) were designed for their owners needs, not everybody else's.

There is a great irony here, which is that many lessons from the past have been forgotten, and ideas which would have help us as developers, and therefore the world, aren't widely used.

Clio doesn't look like my particular cup of tea, but they're trying to solve important problems, and I support them in that.

Our main chat is at https://gitter.im/red/red

Nice to see Rebol and Red mentioned!

Here's a Red version of the calculator: https://github.com/red/code/blob/master/Showcase/calculator.... You can see the syntax is very close. We strive for compatibility with Rebol, but are also changing things that we feel could be improved.

A small twist on the UI can use a `panel`, which supports a divider option to make grid layout easier. e.g., for 4 items across, you can do this:

  view [
     style b: button 50x50 bold
     panel 4 [
          b "1"  b "2"  b "3"  b "+"
          b "4"  b "5"  b "6"  b "-"
          b "7"  b "8"  b "9"  b "*"
          b "0"  b "."  b "/"  b "=" 
     ] 
  ]

Red is fully open source, and can be compiled. Most code anyway. You can write code that is too dynamic to compile until we go JIT. Red is bootstrapped in Rebol, but will be self hosted next year. It is also its own, entire, toolchain. Red compiles to Red/System, a low (C) level dialect/EDSL, which compiles directly to machine code. You can mix and match the two in apps as well.

We're still alpha, and have a lot of work ahead: https://www.red-lang.org/

If you liked Rebol, check us out, and help create the future.

For me, the power of the Redbol approach lies in the rich set of datatypes, so you can create dialects at the block/value level, leveraging the syntax without having to tokenize at the string level. It's no small thing to be able to create languages that natively understand values like email addresses, URLs, IP addresses, files as distinct from strings, and more.

I'd like more info on that as well (as part of Team Red). And, for comparison, what language(s) you feel are best for that, and what features lead to that.

First, thanks to Paul Biggar and the Dark team, for fighting complexity.

Whether or not we agree with Dark's approach doesn't invalidate it in any way. It may mean we don't understand it. There are plenty of companies selling non-FOSS tools and making others successful with them. FOSS does not mean a secure future by any means. The fact that they know they have to prioritize making it a sustainable business is a good sign.

Using any tool, and depending on it commercially, is a risk. You weigh that against who is behind it, the path forward if it goes away, etc. It's easier if you can keep building even when the company goes away. If you rely on their servers, there is always more risk. Is there more risk to a project like Dark than FB's Parse? Nobody can say, without inside information.

What you have to look at, when selecting any tool (ignore the fact that there's a language component here, or that we're devs), is the benefit and the risk. If you have a stack that works for you, and you don't think there's a problem with how you're doing things, don't change. It's really that simple. But there is a revival of RAD, called Low Code, that says there are a lot of businesses out there with needs that aren't being properly met with our "modern" dev processes. If you can get a working product out, and it runs for a couple years, that's a win if you couldn't do it any other way. If you only use Dark to prove a concept, rewrite it after that if you're scared it will go away. Once you have a working product, though, good luck convincing the business it should be rewritten without strong justification.

But we can step back even further and ask: Do you think the state of software development is great? Just OK? Don't see any issues? Do you think that complexity is killing us and things we call solutions really aren't? Or are you somewhere in between?

In watching the videos, there are some things that aren't to my taste. But they note that this is not the final product. If you watch Paul's video, can you deny there is some deep thinking behind it, smart people who have already done a lot while being forced to make real-world compromises.

Yes, it's a business, but they're doing it to make our lives easier too. Shouldn't we cheer them on and wish them the best of luck?

That's what I'm doing.

Logo's intention was not to make it easy to get graphics on the screen. Turtle Geometry is a mathematics made for learning. And it is only one part of the bigger picture of problem solving, using a computer both to solve problems, and to learn about how to solve them.

Doesn't look like IBM Logo, from a glance at the manual on my shelf. IBM Logo did have a `startup` feature, which Rebol and Red (pending security design issues) use, so you can pre-load things into your environment.

I replied to a few comments, and will post my own now.

For those questioning the FOSS-ness of Scarf. Start with Wikipedia, then read a few more things for background.

Scarf itself is BSD3 licensed. You can do whatever you want with it. Even fork it and remove all the things it was designed to do.

There is nothing not-FOSS about this project. The goal (and I'm not affiliated with it in any way, nor do I know the author) is to support FOSS developers. If you're a FOSS developer, you want that, right? And if you're not, do you know how at risk you are because FOSS devs are not compensated consistently and well? That's the message we need to get out. Projects like Scarf are important, and this is a new space, because we need to raise awarenes about this issue and solve it.

Will there be bad actors? You bet. Are there already bad actors? You bet. It's not about creating a perfect solution, but creating a better solution than what we have now. Which means creating any solution at all for this particular problem at this point in history.

For every project that acknowledges and addresses this problem, I applaud you. We need stepping stones.

Ignore Scarf's success for a moment, and focus on it's goal. Do you think FOSS developers should be compensated for their work? If so, how do we make that happen?

Open Source and SaaS are not mutually exclusive. If a SaaS product is also FOSS, it just means that more than one vendor could provide the same exact service. You're paying them for their services and physical resources. Every cloud/hosting provider does this, offering Linux, Apache, etc. And, yes, they can even charge you for the software.

There is no need to bypass Scarf to align completely with FOSS principles. If Scarf is not encrypting the source, adding new license constraints, or hiding it in any way, when it adds its wrapper.

> If the developer intends to open-source his software then in-app purchases defeat the entire purpose?

Free and Open Source and making money are separate issues. This is the Free as in Beer, versus Free as in Freedom bit. FOSS is not like Beer. It is free of constraints in what a user can do with it, including changing it if it is also Open Source.

Indeed, Rebol was groundbreaking in so many ways. Hard for some to understand, but for those whose brains have receptors for it there is nothing quite like it. Working in other langs can be hard once you're used to Rebol, because some things seem so obvious that you can't see why other langs don't do it.

I'm part of Team Red, working on Rebol's successor (https://www.red-lang.org/). We have a number of old Rebolers, but also a lot of new faces, and we're having a great time carrying the torch forward. We still have a lot of work to do, but by the end of the year we should have feature parity with R2, not to mention all the new features Red has, like a compiler, reactive system, Android support, and native GUIs.