
Red Programming Language: Plans for 2019 - rebolek
https://www.red-lang.org/2019/01/full-steam-ahead.html
======
sevensor
I still don't know what to make of this language. If anything, it sounds too
easy, making me think "what's the catch?" Is this a small programming cult or
is it Czech wizardry obscured by a language barrier? Are there no highly
visible Red projects because of shortcomings in the language and its
community, or because the language is so potent, its users so empowered, that
big libraries aren't necessary?

~~~
9214
I do not appreciate your remark about our community and Czech-speaking part of
it. This is rude and uncalled for.

Regardless of gender and nationality of community members, and despite the
fact that Red is an _alpha_ software, the following projects were created,
which may qualify as highly visible:

* neural networks [1]

* computer vision framework [2]

* dataflow engine [3]

* ports of (cross-platform) GUI widgets [4]

* projectional editor [5]

* drawing apps [6]

* operating systems (an in-house project as of now, so no link)

If you don't know what to make out of Red, I'd suggest to grab the latest
build [7] with a list of learning resources [8] and do a bit of research.
Official About page [9] also gives a good list of main features.

Big libraries indeed aren't necessary, because most of batteries are included
in a 1MB executable, and common needs are covered by core library. Full-
fledged module system is missing, but is planned for 0.8.0 release. We also
have a large Rebol ecosystem, from which various scripts and applications may
be ported, if necessary.

[1]: [http://redlcv.blogspot.com/2018/11/neural-network-with-
red-l...](http://redlcv.blogspot.com/2018/11/neural-network-with-red-
language.html)

[2]: [https://github.com/ldci/redCV](https://github.com/ldci/redCV)

[3]: [https://gitter.im/red/red/gui-
branch?at=5c018edb8fa4333e391b...](https://gitter.im/red/red/gui-
branch?at=5c018edb8fa4333e391b867a)

[4]: [https://gitter.im/red/red/gui-
branch?at=5c03fdbabe66d8252666...](https://gitter.im/red/red/gui-
branch?at=5c03fdbabe66d825266600ac)

[5]: [https://gitlab.com/rebolek/values](https://gitlab.com/rebolek/values)

[6]: [https://github.com/toomasv/drawing](https://github.com/toomasv/drawing),
[https://github.com/honix/Redraw](https://github.com/honix/Redraw)

[7]: [https://www.red-lang.org/p/download.html](https://www.red-
lang.org/p/download.html)

[8]: [https://github.com/red/red/wiki/[LINKS]-Learning-
resources](https://github.com/red/red/wiki/\[LINKS\]-Learning-resources)

[9]: [https://www.red-lang.org/p/about.html](https://www.red-
lang.org/p/about.html)

~~~
hjek
> > If anything, it sounds too easy, making me think "what's the catch?

> This is rude and uncalled for.

I think she/he raise a fair point about how the Red language is advertised,
and it's actually a rather friendly to assume that it's due to language
barrier.

Many posts about Red/Rebol are unequivocal praise with very few details or any
acknowledgements of short-comings or limitations of the languages.

Just to dig up some random ones:

Here's a speed comparison between Rebol and Python[0]: Rebol is faster (
_surprise!_ ), but the post doesn't contain or link to any of the code used
for the comparison

Here's some grand self-praise from the _Why Rebol /Red_[1] on why it's _just
better than all other languages_ :

> You may be familiar with Clojure, Python, Ruby, Lua, frameworks like Ruby on
> Rails, or any of the multitude of Javascript frameworks which are purpose-
> built to "ease" particular types of development work. Such
> languages/tools/environments are certainly productive compared to
> traditional tools like plain old C++, Java, etc., but they are absolute
> behemoths when compared to Rebol. Virtually every other well known
> development tool in popular use is built upon bloated layers of existing
> technology, and encumbered by mainstream language syntax and development
> procedures which introduce an extraordinary volume of unnecessary complexity
> at many levels. Most developers have just never experienced the sort of self
> dependent architecture, lightweight tooling, bare language and data
> structure syntax, composability, and reduced code volume, which Rebol
> prioritizes as its most important purposes.

(Are Red/Rebol creators seriously claiming that Clojure's syntax is complex?)

Of course there are sometimes programs about which you could make grand
claims, like when SQLite claims to be "35% Faster Than The Filesystem"[2], yet
they also clearly describe its limitations[3].

Edit: Even in this thread we get this kind of praise:

> Isn't Red a great language to teach children? I just tried Red and it's
> amazingly simple to get started.[4]

About a year ago I _did_ try out Red and Rebol, and I couldn't get any of the
examples to work, or figure out what the syntax meant, because there's just so
many _cool examples of how few lines it takes to do X_ but very little
explanation. It made me feel a bit inadequate, because if this language is
_soooo easy to use_ , and yet I somehow fail to grok it, then I'm just not
smart enough, right?

Here's one of the examples linked to in _Why Rebol and Red_ , with hardcoded
IP, no comments and all:

    
    
        REBOL [title: "Live Camera Video Stream"]
        for i 2 27 1 [append b:[] rejoin [http://207.251.86.238/cctv i ".jpg"]]
        view w: layout [
          i: image 320x240  text-list 320x200 data b [forever [
            set-face i load value wait 1 if not viewed? w [unview break]
          ]]
        ]
    

It's great that someone found that so _easy_ to write, but it looks like one-
off write-only shell script, and is _certainly_ not useful for "teaching
children".

I know it might seem a bit harsh that I'm suggesting that Rebol/Red is being
promoted in a somewhat dishonest way, but I'm mentioning this so that you
could hopefully improve, not to make you upset.

Edit: More over-the-top praise.[5][6][7][8]

[0]: [http://blog.hostilefork.com/rebol-vs-python-
performance/](http://blog.hostilefork.com/rebol-vs-python-performance/)

[1]:
[http://redprogramming.com/Why%20Rebol%20and%20Red.html](http://redprogramming.com/Why%20Rebol%20and%20Red.html)

[2]:
[https://www.sqlite.org/fasterthanfs.html](https://www.sqlite.org/fasterthanfs.html)

[3]:
[https://www.sqlite.org/whentouse.html](https://www.sqlite.org/whentouse.html)
(See the section _Situations Where A Client /Server RDBMS May Work Better_)

[4]:
[https://news.ycombinator.com/item?id=18844770](https://news.ycombinator.com/item?id=18844770)

[5]:
[https://news.ycombinator.com/item?id=18844002](https://news.ycombinator.com/item?id=18844002)

[6]:
[https://news.ycombinator.com/item?id=18844185](https://news.ycombinator.com/item?id=18844185)

[7]:
[https://news.ycombinator.com/item?id=18844746](https://news.ycombinator.com/item?id=18844746)

[8]:
[https://news.ycombinator.com/item?id=18845102](https://news.ycombinator.com/item?id=18845102)

~~~
dmitriid
One of the reasons is that the Red community is very small and entrenched.
They know everything that comes out of the language, and _to them_ everything
is easy and understandable.

They will fight you to the death if you even try to say that "english-like
syntax with no parantheses" is the opposite of readable or understandable when
you don't know the system.

Go into any of Red's source files and you will end up looking at dozens to
hundreds of lines of code with no comments and which often look like this:

    
    
        return old-gradient-pen DC cmds start tail cmd sym catch?
        OS-draw-brush-pattern DC size crop-1 crop-2 word as red-block! cmd sym = fill-pen
        _read opfd hash alg-digest-size type
    

etc. These are obviously impossible to look up and find.

The whole development is haphazard as well. Everything hinges on two may be
three people who know Red internals wihch frantically move from subsystem to
subsystem developing features and patching wholes.

Patching wholes are usually like this:

\- issue is raised on GitHub

\- it's acknowledge

\- a fix is written (with zero comments even for the complex issues) and
merged

\- the issue is closed with a "tested" label [1]

About 0.001% of "tested" issues contain any tests. The majority of fixes are
apparently only fixed and manually tested against the reported issue.

etc. etc.

[https://github.com/red/red/issues?q=is%3Aissue+is%3Aclosed+l...](https://github.com/red/red/issues?q=is%3Aissue+is%3Aclosed+label%3Astatus.tested)

~~~
9214
I don't recall anyone fighting to the death over someones syntactic
preferences. Code written by experienced users (and Red codebase in
particular) is a hard nut to crack, that's true.

Regarding development: I'd appreciate if you elaborate over your critique.
Concrete suggestions on how development and testing processes can be improved
are always welcomed.

~~~
dmitriid
> Regarding development: I'd appreciate if you elaborate over your critique.

There's nothing to elaborate, really. If you list all "status.tested" issues,
how many are tested?

Let's take the top few as of today.

1\. Malignant output from react/link,
[https://github.com/red/red/issues/3713](https://github.com/red/red/issues/3713)

fix:
[https://github.com/red/red/commit/644be4b1e3bfcf70a5f9f5e006...](https://github.com/red/red/commit/644be4b1e3bfcf70a5f9f5e0066fdd2cc964cd73)

One-line fix, sure. Where's the test?

2\. new-line flags are not cleared on subsequent calls,
[https://github.com/red/red/issues/3707](https://github.com/red/red/issues/3707)

Fix:
[https://github.com/red/red/commit/b7ee2846b58a1328d57002b3ed...](https://github.com/red/red/commit/b7ee2846b58a1328d57002b3ed2d076d65ca4b7e)

Severl line-fix. Where's the test?

3\. stack overflow on limited append/insert,
[https://github.com/red/red/issues/3705](https://github.com/red/red/issues/3705)

The fix contains a single test even though the issue provided three different
failure modes:
[https://github.com/red/red/commit/bd41d35ee5a73cd5779647b503...](https://github.com/red/red/commit/bd41d35ee5a73cd5779647b50376b0d757c9e8a0)

And so on and so forth. I remember seeing a "status.tested" which added easily
a hundred lines of new code with zero tests.

Funnily enough I see you've added a "test.written" label, which really
shouldn't be there because that's what "status.tested" is for.

\----

But forget issues and tests for the moment.

Out of 44 contributors to Red, only two have anything significant to
contribute: the people who actually develop Red.

Of all the issues reported almost none contain code to fix the issue. Almost
all issues are fixed by the same two people who develop Red.

Perhaps it's due to the fact that about zero percent of Red code is
documented? Or that "Code written by experienced users (and Red codebase in
particular) is a hard nut to crack"? Which is kinda ironic, considering how
the authors and proponents gush about Red's simplicity.

Go back to the first issue in the list above. It's a one-line fix. So, surely,
it could be fixed by someone else but the author of the language?

Too bad the file where the issue is fixed is this:
[https://github.com/red/red/blob/644be4b1e3bfcf70a5f9f5e0066f...](https://github.com/red/red/blob/644be4b1e3bfcf70a5f9f5e0066fdd2cc964cd73/environment/reactivity.red)

336 lines of no significant comments other than trivia for the author himself.

"New line flags not cleared" whose fix is just a few lines? Oh, it's in a
3000-line file with no comments,
[https://github.com/red/red/blob/b7ee2846b58a1328d57002b3ed2d...](https://github.com/red/red/blob/b7ee2846b58a1328d57002b3ed2d076d65ca4b7e/runtime/natives.reds)

And so on and so forth.

And since very very few of those lines are covered by any tests (even for
issues reported and fixed), how is anyone except the two authors can ever fix
those issues or contribute?

If "Code written by experienced users (and Red codebase in particular) is a
hard nut to crack", how can you expect people to believe in it's "simplicity
and fun"? \----

~~~
9214
Bus factor - fair enough. Lack of tests - have you counted them? [1]

2/3 of issues you showed are purely formatting concerns, so I'm not sure what
needs to be tested there. "test.written" refers to test being written in a
testing framework, "status.tested" means that the described bug was tested in
multiple development environments and confirmed. So your remark is slightly
off the base.

Small number of dedicated contributors: historically, Rebol (the ancestor of
Red) was developed by Rebol Tech company in a closed manner. So, IMO there
developed a particular community mindset, where everyone just lets the Boss do
the job and watches the action from the tribunes.

Another reason, like I said elsewhere, is the fact that Rebol never became
mainstream, hence there isn't much contributors ready to provide the code of
acceptable quality.

Lack of comments and such: in the early days, Red planned to be minimal and
bootstrapped early, so the whole codebase was written in a throw-away fashion,
with no comments or afterthoughts. As the project growed and roadmap changed
its curves, community started raising demands (macOS View backend, new
datatypes, supporting other platforms, the list goes on), so the "quick
bootsrap" plan was ditched, but the code remained. This is a stumble block for
other contributors, which, alas, will be moved away only after 1.0 is reached.

"Simplicity and fun" is completely off the point though, but I get what you
say, even with a snarky tone. "Simplicity" here refers to the use of embedded
DSLs, in which it is generally easy to express ideas suitable for a particular
domain, and to "self-contained small toolchain" goal of the project. So,
_expressing_ ideas and _developing_ them is rather simple, once you got the
hang of the language.

 _Reading_ Red code requires a prior knowledge of function's arity and
evaluation rules; ambitious projects require knowledge of multiple dialects
and thorough understanding of core concepts; dynamic pieces (i.e.
metaprogramming) can be challenging, unless you're coming from Lisp or Forth
camp.

Runtime is written in Red/System dialect, which requires C-level skills to
write. Red and Red/System share the same syntax, but require a huge mental
leap to switch the context (Lisp vs. C dichotomy) - another 2 cents to your
"lack of contributors".

I'm not a fan of "Red is simple and for everyone" sales pitch either - it's
misleading at best, sets the wrong expectations and usually comes from people
who barely clocked 1 hour in REPL tinkering with available View examples.

Hope that answers your concerns, more or less. If you want to alleviate them
more quickly - drop by our community chat and start contributing piece by
piece ;) Cheers.

[1]:
[https://github.com/red/red/tree/master/tests](https://github.com/red/red/tree/master/tests)

~~~
dmitriid
> 2/3 of issues you showed are purely formatting concerns

This is a bald-faced lie, and one can see that by following the links I
provided.

A "formatting concern" is changing indentation or splitting a long declaration
over several lines.

The issues I've shown, and the majority of others, are actual bugs that are
fixed by altering code.

> "test.written" refers to test being written in a testing framework,
> "status.tested" means that the described bug was tested in multiple
> development environments and confirmed. So your remark is slightly off the
> base.

It's entirely on point. Code for the fix is written, the issue is closed. The
commit is merged into master branch. No tests are added in the commit that
fixes the issue.

When are exactly tests for these changes "written in a testing framework", if
ever?

I could count the tests until I'm blue in the face, but the fact remains: next
to no tests are written for issues that are marked as fixed, and closed. And
if you view the commit history, well, it's mostly fixes, and some superfluous
tests remove. No commits show any tests added (I know such commits appear
sometimes, for larger features).

> hence there isn't much contributors ready to provide the code of acceptable
> quality.

I don't even know how to comment on this

> This is a stumble block for other contributors, which, alas, will be moved
> away only after 1.0 is reached.

So, not in any foreseeable future. Original plan to release 1.0 was last year
AFAIR. Then that shifted to release 0.6.5 AFAIR which is still not released.

So:

\- contributors aren't willing to provide code of acceptable quality for any
foreseeable future

\- there won't be any acceptable quality, or even such an important thing as
comments, for any foreseeable future

\- there will rarely be any tests for any of the issues found and fixed for
any foreseeable future

See why my skepticism about Red is not unfounded?

> Reading Red code requires a prior knowledge of function's arity and
> evaluation rules; ambitious projects require knowledge of multiple dialects
> and thorough understanding of core concepts; dynamic pieces (i.e.
> metaprogramming) can be challenging, unless you're coming from Lisp or Forth
> camp.

Do not confuse Red with Lisp. Lisp (and even its expanded dialects such as
Clojure) have clearly pretty much defined rules on how to read code.

No "previous experience" with Red will let you parse the "simplicity" of

    
    
       OS-draw-brush-pattern DC size crop-1 crop-2 word as red-block! cmd sym = fill-pen
    

> another 2 cents to your "lack of contributors".

It's not "2 cents". It's yet another weak attempt at finding excuses instead
of facing criticism face on.

There's a reason I gave Elixir as an example. You could view it as a one-man
show, as one contributor, the author, has an overwhelming input into the
project compared to all other contributors.

However, it doesn't prevent him from:

\- writing acceptable code

\- writing tests for the fixes he provides to issues

\- writing comments in code

What this result in? Well, even the issue I referenced: it was reported _and
fixed_ , _and documented_ not by the author, but by a different contributor. A
miracle, by Red standards.

> Hope that answers your concerns, more or less.

Nope, it doesn't. It's a string of excuses, and see the concerns about the
foreseeable future above.

> [1]:
> [https://github.com/red/red/tree/master/tests](https://github.com/red/red/tree/master/tests)

Which of the tests contain the test for the "Malignant output from
react/link"?

Or, and I swear to God, I found this by pure accident trying to be snarky and
digging up some old issue: your own reported issue,
[https://github.com/red/red/issues/3211](https://github.com/red/red/issues/3211)

It was fixed, with no tests, and don't tell me it was "formatting concerns".
So, which of the red/tests contain the test "being written in a testing
framework"?

~~~
9214
> This is a bald-faced lie, and one can see that by following the links I
> provided.

You call me a liar now? Tone down a bit, would you? By "formatting" I meant
formatting output of error messages (changing size of the buffer down to 80)
and data (ensuring that newline markers are preserved), not the source code
cleansing.

> I don't even know how to comment on this

Then don't.

> Original plan to release 1.0 was last year AFAIR. Then that shifted to
> release 0.6.5 AFAIR which is still not released.

Not entirely correct. This [1] article gives a context to what 1.0 was "then"
and "now", and also explain why roadmap was adjusted.

> See why my skepticism about Red is not unfounded?

By all means, be skeptical, I'm not trying to convert you or whatnot. You've
raised important points, so I tried to elaborate and explain why things are
the way they are, so you can judge by yourself.

> Do not confuse Red with Lisp.

Well, I don't. As I said, reading code requires knowledge of funciton's arity,
and your example only proves that. And you seemingly ignored what I said about
"simplicity". Moreso, your example is Red/System, not Red, pulled out of Draw
backend. I can similarly crop a random snippet out of the guts of Elixir and
make googly eyes.

> It's yet another weak attempt at finding excuses instead of facing criticism
> face on.

Again, tone down. I asked you to elaborate exactly to face the criticism, and
provided some context, so you can make a fair judgement. Things turned out
that way for reasons - I gave you my IMHO on them - you see these reasons as
"excuses". Fine, point taken.

> see the concerns about the foreseeable future above

Time will tell.

[1]: [https://www.red-lang.org/2018/01/overview-of-red-
development...](https://www.red-lang.org/2018/01/overview-of-red-development-
history.html)

~~~
dmitriid
> You call me a liar now? Tone down a bit, would you? By "formatting" I meant
> formatting output of error messages (changing size of the buffer down to 80)
> and data (ensuring that newline markers are preserved), not the source code
> cleansing.

1\. Once again, this is provably false.

2\. Once again, this is no jsutification for the fact that nearly all bugfixes
contain no tests.

> You've raised important points, so I tried to elaborate and explain why
> things are the way they are, so you can judge by yourself.

I have, and my initial an subsequent posts remains just as valid.

> Time will tell.

It has already told. At best, Red sees one minor version increment per year.
At best. It's more of a one patch version increment per year.

So, going back to this statement: "hence there isn't much contributors ready
to provide the code of acceptable quality.... [lack of comments as] a stumble
block for other contributors, which, alas, will be moved away only after 1.0
is reached." This means that we will not see this for any foreseeable future.

Somehow this is viewed as a normal course of events even though it isn't.

Well, to each his/her own, I guess ¯\\_(ツ)_/¯

BTW, have you ever seen any tests to your own bug reports, or have you written
any tests for the bug reports where you provided a fix?

~~~
9214
> this is provably false

If it's provably false, then take your time to actually prove it before
calling someone a liar.

> my initial an subsequent posts remains just as valid.

They remained as biased as the were. You waved away project's history and keep
imposing "high" standards pulled from other projects, without respecting their
retrospective history and goals.

> At best, Red sees one minor version increment per year. At best. It's more
> of a one patch version increment per year.

Absolute nonsense. Read the changelogs, roadmap and Github releases before
making such claims.

> Somehow this is viewed as a normal course of events even though it isn't.

Again, in retrospective, this is an expected course, and no one will adhere to
your idealistic, unencumbered by reality version of how things should be done.
Want an overnight improvement - start contributing.

> Well, to each his/her own, I guess

I guess. Feedback filtered out of your messages is appreciated, and taken into
account. Thanks for taking your time to respond. In the meantime, I'm marking
this as the end of discussion.

~~~
dmitriid
> If it's provably false, then take your time to actually prove it before
> calling someone a liar.

1\. It was _your_ claim that it was "just formatting changes". Which they are
not

2\. This doesn't explain why 99% of bug fixes contain no tests

> If it's provably false, then take your time to actually prove it before
> calling someone a liar.

Testing and comments in code are not high standards. They are basic
development hygiene.

> Absolute nonsense. Read the changelogs, roadmap and Github releases before
> making such claims.

I've read them, that's why I'm making such claims.

Releases:
[https://github.com/red/red/releases](https://github.com/red/red/releases)

Barely above one patch increment a year for the past three years:

\- Nov 2018, 0.6.4

\- Jul 2018, 0.6.3

\- Mar 2017, 0.6.2

\- Jun 2016, 0.6.1

\- Mar 2016, 0.6.0

Minor versions incremented from 0.1. to 0.6 in 7 years, and increments have
slowed down.

So, we are expected to believe that 7 years from now when it maybe reaches
1.0.0 the devs will suddenly go through all the code, add comments and tests,
and start caring?

> no one will adhere to your idealistic, unencumbered by reality version of
> how things should be done.

Me: when you fix issues, you should really add tests to those fixes. At least
strive to have more than ~0 tests in your fixes. Add documentation to critical
parts of your system.

You: "your idealistic, unencumbered by reality version"

:-\

That's why I'm extremely sceptical. What is considered the norm pretty much
everywhere is viewed as "unencumbered by reality" in Red world.

> Feedback filtered out of your messages is appreciated, and taken into
> account.

I very much doubt it was taken into account.

~~~
greggirwin
Dimitri, you've obviously looked into Red in some depth, which is appreciated.
And your comments and criticisms have been heard. It's easy for
miscommunication to occur in chat like this, so we can probably close this
particular thread of conversation, as I don't think it's productive anymore.
As much as I now want to chime in to defend our position, it wouldn't help.
You make valid points, but comparisons with other projects are hard.

If you don't like Red, or how the project is being managed or progressing,
that's fine. Sharing what you've learned is also great, as long as others can
form their own opinions from facts presented (again, hard to present deep info
in chat). All we ask is that you try to be fair, and think about how harmful
negative press can be to a project. When you've put a huge amount of time and
effort into something you believe in deeply, it's easy to get defensive when
someone criticizes it (in ways that may seem unfair).

How things are said is important, as well as balancing pros and cons. In re-
reading the chat, I admit that I got defensive, which is why I didn't respond
initially.

In conclusion, can we do better? Yes, of course. Is much of the code written
by a very small core, who knows the system well, and isn't writing it with the
expectation that others will read and learn from it? Yes. Can we do better on
testing? Yes. Do we already have more than 30'000 tests? Yes. Are those core
devs pretty darned amazing, considering what they've built (insert feature
list here :^)? You bet they are.

Red isn't for everyone. Our approach won't be to everyone's liking. But we
hope people will be fair, wish us luck, and maybe even applaud us for trying
to build something that will make their lives better. At the very least, we
hope they won't talk us down unfairly.

------
stesch
I'm I shallow if I stopped caring about this project after they started with
all this crypto currency stuff?

~~~
greggirwin
If you read the old blog entries about why it was done, do you still feel that
way?

~~~
stesch
I followed the project up until then.

~~~
greggirwin
Understood, so you know there was a reason for branching out into the
blockchain space, as there's a real need for better langs there, and less
competition, which leads to more visibility in an area that his hot
technology. For the project to survive, we'll have to try a lot of things.

------
emmanueloga_
Things I find exciting about Red:

* Small

* Lisp like

* Cross compiler "done right" [1]

* Red/System is a cool concept (a language dialect for low-level/systems programming).

Things I find discouraging:

* Bus factor = 2 (IMHO) [2]

* Apparently, it took it 8 years to get simple (in words of author) G.C. [3]

* Docs and example code are not great, lack of existing apps (chicken & egg problem).

1:
[https://github.com/red/red/blob/master/usage.txt#L68-L81](https://github.com/red/red/blob/master/usage.txt#L68-L81)

2:
[https://github.com/red/red/graphs/contributors](https://github.com/red/red/graphs/contributors)

3:
[https://github.com/red/red/tree/v0.6.4](https://github.com/red/red/tree/v0.6.4)

~~~
dockimbel
> * Apparently, it took it 8 years to get simple (in words of author) G.C. [3]

Apparently you didn't look close enough at the history and are making up fake
information.

Preliminary work on GC started in 2017 for a month, then resumed in 2018 for
about 3-4 months. So in total, about 4-5 months, mostly spent on adjusting the
runtime library and tracking notoriously hard to catch GC-related issues.

~~~
emmanueloga_
Hey there, I did not intend to imply it took that long in actual development
time, more in the sense that the g.c. feature did not exist in He language for
that long, for different reasons (evidently it wasn’t a priority).

A dynamic language without g.c. sounds dangerous to use. I’m just surprised it
wasn’t a priority for so long.

------
greggirwin
There are a lot of topics here now, which is great, and the opening question
about what to make of Red is a good one. The problem in answering it is the
same problem we have when pitching it to people: it's hard to sum up.

Is there a catch? Yes. More than one actually. One is that, because we are
building things from the ground up, we don't get things for free that other
languages do. For example, JVM-based langs get a lot for free, but at a cost.
Another catch, and a big one, is that Red is fundamentally different in some
design aspects, both superficial (syntax) and deep (all is data, words and
bindings, etc.). Those two things deter a lot of people. We get that. If you
want to keep doing things mostly the way you always have, Red is not for you.
If you just want lots of familiar libs and features, you may have to wait for
them, or help build them. This makes us a self-selecting community. We don't
want to be a cult, but we also won't compromise certain things with the hope
of it making us more popular. There are few easy choices here.

For those who find Red, and give it a shot, not all will like it, and not all
who like it will understand it or use it effectively. We also accept that. For
those who have the courage to try something new (I mean, really try it), and
who take the time to understand it (the process of which brings its own
benefits, no matter what language you use), and who reach the moment where it
clicks in their head, there is no going back.

Whether you support and commend features, or criticize them fairly, they are
features. To have meaningful discourse about Red, we need to go deeper. Much
deeper. If you only want to compare Red to other tools, on their terms, we'll
often lose. But if you look at what Red can do, that they can't, and Red's
fundamental goals, it becomes clear that comparisons don't mean much. That's
true for any 2 languages. It can help, provide context, etc., but ultimately
you have to evaluate a language or tool on its own merits, just as you have to
evaluate yourself and see your own worth and value without comparison to
others.

If you think the state of software development is just fine, and a few tweaks
are all we need, Red probably isn't for you. But if you have nagging doubts
about why things are so hard, so big, so complex, when it seems like they
should be easy, small, and simple...maybe you'll be curious and brave enough
to take the Red pill. Most, we know, just want the big juicy steak.

We can talk more, explain more, if people want. Gitter is our most active
channel, but we can try to respond here as well. We're glad to hear what
people like, and accept fair criticism.

~~~
hjek
> One is that, because we are building things from the ground up, we don't get
> things for free that other languages do. For example, JVM-based langs get a
> lot for free, but at a cost.

Red is implemented in Rebol2. That also comes at a cost due to Rebol2 not
being free/libre and being abandoned.

~~~
greggirwin
But that was a very important choice. Do you understand why?

~~~
hjek
> But that was a very important choice. Do you understand why?

I'm sure you have your reasons for doing so, and I'm glad that it's working
well for you.

I'm not having a go at you for making Red run on Rebol. But _I am_ having a go
at you for having a go at Clojure for running on the JVM, while claiming that
Red is built "from the ground up".

All this posting about how Red is better than all other languages, and that
people, who use those other ones, are stuck in their ways or not smart enough,
and defensively lashing out at people who point out limitations of Red, it
just comes across as megalomaniacal. Being implemented in Rebol2 apparently
also "has a cost" for Red, namely that Rebol2 is abandoned, and that there's
no 64-bit support, and that a otherwise free/libre programming language has
non-free dependencies, and you might be in a pickle if you want to include
newer versions of libraries that are presumably statically compiled into the
Rebol2 binary blob, especially your SSL library... but apparently, from what I
read about Rebol[0], it's only the "pro" version of Rebol that has SSL-
support, so what about Red?

Do _you_ understand those issues? It's too hand-wavy to say that I'm not
looking at Red "on its own terms", especially because those terms include
being a "good fit for any task!"[1]

[0]:
[https://www.freax.be/2017/03/19/rebol/](https://www.freax.be/2017/03/19/rebol/)

[1]:
[https://en.wikipedia.org/wiki/Red_(programming_language)](https://en.wikipedia.org/wiki/Red_\(programming_language\))

~~~
9214
Can you back up your acqusations with palpable evidence? Neither Red author,
nor any of official project representatives "made a go" on Clojure or any
other language and its community, as far as I'm concerned.

As for "defensive lashing" \- you should make a distinction between informed,
well-posed critique and arrogant, unbacked ranting. Everyone accepts the
former and does not tolerate the latter - the team is no exception. And, again
- either provide an evidence for what you say or back off your claims. Calling
project megalomaniacal for fighting FUD is completely off base, and every
criticism raised in this thread was handled politely. Heck, I can pull out any
blog post from one of Clojure community members and start claiming that it
represents opinions of Hickey. Would that be OK? I guess not.

Even if there is a cost in using Rebol2 as bootsrapping language, it will be
gone with 1.0 release. And right now Rebol source code takes roughly a quarter
of whole codebase (compilers and linkers for Red and Red/System) - the rest is
pure Red and its dialects. So your whole paragraph is completely irrelevant
and misleading: lack of 64-bit support has nothing to do with Rebol2, bold
"non-free dependency" claim does not have any weight to it (since when
bootstrapping language is a dependency?) and "SSL library" passage tells me
that you don't have an idea of what you're talking about.

And use _official_ resources (Red and Rebol websites) as references, would
you? Wiki page is an extremely weak testimony to whatever you have to say.

No project is ideal, but Red's terms are completely different from what you
try to impose here. I do not say that we don't have holes in the housing - we
do, and we have all what is necessary to close them.

~~~
hjek
> And use official resources (Red and Rebol websites) as references, would
> you? Wiki page is an extremely weak testimony to whatever you have to say.

That's my mistake. The quote about Clojure I provided were from
`redprogramming.com` which is linked to from the official website and from
your Github, so it looked official to me.

The comparison with Python is from a blog of one of the Rebol developers. Not
sure whether that qualifies as _official_.

If the Wikipedia article about Red is wrong, it might be a good idea to
correct it..?

> Even if there is a cost in using Rebol2 as bootsrapping language, it will be
> gone with 1.0 release. [...] (since when bootstrapping language is a
> dependency?)

That's cool, and I wasn't aware of that. I just assumed Red was to Rebol what
Hy is to Python and Clojure to Java, but that's great that that is a non-
issue!

~~~
9214
> `redprogramming.com` which is linked to from the official website

Official page links to learning resources provided by community, to compensate
for TBD state of official documentation. We can't, however, control other
people's opinions, or dictate them how to express themselves.

People can unintentionally say provocative things in a burst of excitement, I
hope you understand that. And there are reasons to be excited about Red and
Rebol.

> The comparison with Python is from a blog of one of the Rebol developers.
> Not sure whether that qualifies as official.

As I said, we can't control other people, and are not responsible for other's
bold claims. I too do not think that this benchmark was fair and objective. As
for the wiki page - we'll note that. I'm just saying that any other person can
go there and apply his/her edits, without project's consent.

> I just assumed Red was to Rebol what Hy is to Python and Clojure to Java,
> but that's great that that is a non-issue!

It's good that this confusion is resolved. Hy and Clojure are hosted languages
by nature, but Red is entirely self-contained (although you might think that
it depends on Red/System dialect).

------
austincheney
The Red Language has always described itself as _functional imperative_. I
used to point out to people that functional programming can be imperative and
nobody (I do mean nobody I spoke to about this) would believe me on this. Then
I would point out to people Red Language as an example and they would scratch
their heads in confusion.

Even the Wikipedia article gets this wrong:
[https://en.wikipedia.org/wiki/Functional_programming](https://en.wikipedia.org/wiki/Functional_programming)

Functional imperative is the idea of using functions to define the shape of an
application, which is to say the nesting of functions defines both the stacked
structure and the resulting control flow opposed to describing units of logic
or any sort of reflection.

[https://en.wikipedia.org/wiki/Function_model#Functional_deco...](https://en.wikipedia.org/wiki/Function_model#Functional_decomposition)

~~~
bjz_
> I used to point out to people that functional programming can be imperative
> and nobody (I do mean nobody I spoke to about this) would believe me on
> this.

Interesting. Monadic Haskell can be quite imperative if you want it to be, as
can SML or OCaml. Scheme and Lisp have imperative parts too.

~~~
grenadier21
Haskell's IO is literally the idea of sequencing commands reified, though, so
the comparison is a bit apples-to-oranges.

------
vanderZwan
I was so worried when they announced their cryptocurrency plans that Red
wouldn't survive when the cryptocurrency hype bubble would inevitably pop.
Glad to see that they managed.

~~~
dvfjsdhgfv
I was worried about it too. I hope they simply forget about the whole ICO
thing and just move forward.

~~~
9214
Unlike the majority of startups in crypto space, the team is actually
dedicated to bring the value to this ecosystem.

Ethereum roller-coaster forced a constant change of plans, but, as far as I
know, no one ditched gived promises and just moved forward.

------
galfarragem
Isn't Red a great language to teach children? I just tried Red and it's
_amazingly_ simple to get started.

~~~
9214
Although Logo is said to be an ancestor to Rebol (which in turn is an ancestor
to Red), there's more it than an apparent "childish" simplicity on the
surface.

[http://www.rebol.com/article/0103.html](http://www.rebol.com/article/0103.html)

Language that hits the sweet spot between Forth and Lisp might be a good fit
for some kids, but its scope is way outside of mere scripting and toying, and
demands a respective approach - something that only grown-up engineers can
fully appreciate. YMMW.

~~~
vanderZwan
> _its scope is way outside of mere scripting and toying, and demands a
> respective approach_

Maybe I misunderstand where you are coming from, but to me this appears
similar to saying that using acrylic paint demands a respective approach
because the great paintings of the last century were made with it.

To which I would say: no, not really. Acrylic paint only demands a respective
approach in the sense that it may be toxic and you don't want kids to finger
paint or risk swallowing it. But people can paint whatever they want with it.

Similarly, Red demands a respective approach because it's powerful enough to
shoot yourself in the foot (oops, some kid deleted half of the files on the
SSD by accident). Maybe that is what you meant with "scope", but it's not what
I made out of it upon first reading.

Besides, the solution for that is simple enough: make a child-safe dialect.

~~~
9214
My point is that Rebol and Red are extremely good chameleons - they hide all
their power behind the approachable facade, and make a false impression of "oh
it's just X, nothing serious". I saw a fair share of people who, based on that
first impression, dismiss Red as a quirky alternative to Python, or a GUI-
building kit, or a pretentious academical toy, you name it.

But that doesn't mean that these languages child-safe _by default_ , and
indeed, foot-shooting starts as soon as you begin to harness that power -
that's where the real fun is, which IMO kids can't appreciate fully. As you
said, it's anything but a finger paint.

But if it clicks in kid's brain from the get-go and grows over him, then the
world is ought to see some great paintings ;)

~~~
vanderZwan
Ah, so we were more or less on the same page from the beginning.

BTW, is there a child-safe dialect for Red? How easy or hard would it be to
create an environment like Processing or p5.js, without the foot-shooting
risks?

[https://processing.org/](https://processing.org/)

[http://p5js.org/](http://p5js.org/)

~~~
9214
That kinda a broad question.

Easy - you can create a live-coding IDE in 20 lines or so, Draw and View a
pretty capable for interactive Processing-like demos, bottlenecks can be
rewritten in R/S.

Hard - hit the academical papers and define what can be considered a "child-
safe programming environment". Then implement a separate toolchain for that.

~~~
vanderZwan
I was thinking more along the lines of

[Somewhere between Easy and Hard?] - _make the dialect operate in a safe
sandbox that can 't destroy your computer_

... plus optionally convenience functions fitting for the creative problem
domain like how Processing removes a lot of Java boilerplate, and p5 does
similar things for using the various JS APIs. One can just look at the APIs of
Processing, p5 and OpenFrameworks to get an idea of what works there, though.

~~~
9214
Safe sandbox: Rebol had Protect and Secure dialects [1, 2], which are planned
to be implemented in Red. Language is very dynamic though, so there's a
certain limit on what kind of safety can be enforced at runtime.

Creative problem domain: that's what Red is all about in my point of view -
slapping domain-specific languages one on top of another to pin down the exact
problem space. Draw for 2d vector drawing, View for GUIs, Parse for, well,
parsing and metaprogramming, et cetera. The crux is usage of same data format
and common notation at every abstraction layer, be it low-level programming or
high-level scripting.

I don't think that Red can handle large-scale projects the way language
workbenches do (yet), but it can be used for moderately small embedded DSLs.

Does that answer your question?

[1]:
[http://www.rebol.com/docs/words/wsecure.html](http://www.rebol.com/docs/words/wsecure.html)

[2]: [http://www.rebol.com/docs/words/wprotect-
system.html](http://www.rebol.com/docs/words/wprotect-system.html)

~~~
vanderZwan
Yes, thank you!

------
Gys
A great feature of Red is their cross platform GUI support. I see Android is
also supported. Does anyone know what the status of iphone (iOS) support is ?

~~~
dvfjsdhgfv
I wouldn't call its GUI really cross-platform yet. Linux GUI definitely isn't
production ready. Android is somewhat usable. iOS is not working.

Nevertheless, I keep my fingers crossed. My estimate is in 2-3 years you will
be able to start writing small cross-platform GUI apps in RED and not worry
about trifle problems.

~~~
9214
One major stumble block in GTK backend development is a monstrocious string-
oriented API for setting widget properties. There's a more low-level one, but
it's depricated.

FYI, development of backend happens as we speak [1].

[1]: [https://gitter.im/red/GTK](https://gitter.im/red/GTK)

------
neuro
After seeing the first demos from Rebol View many years ago, nothing comes
close yet.

~~~
hu3
At least once a year I'm tempted to play with Rebol. Its concepts scratches
many itches of mine.

Do you have any suggestion on what I could write to showcase idiomatic Rebol?
Networking? GUI? Command-line?

~~~
neuro
Take a look at these, source code is easy to follow

[http://www.rebol.com/pre-view.html](http://www.rebol.com/pre-view.html)

------
echelon
A language with a GC does not seem appropriate for a "full-stack" language
with which one would write operating systems, drivers, or game engines. I
don't know why any language without full manual memory management would ever
posit itself as being appropriate for these domains. It's naive at best.

~~~
vardump
I write kernel drivers and firmware code mainly in C and a little bit of
assembler.

I agree with you pretty much.

That said, it's healthy to have some people exploring alternative paths. Maybe
some of that exploration will be fruitful, way or another.

Especially firmware development is somewhat ossified to C. C is universally
supported and a lot of people in this trade don't even see need for a change,
despite vastly increased system complexity and exposure over open networks.
It's not enough for the things to just to work — they need to work securely,
otherwise ultimately our infrastructure is at risk.

C can work with 16 bytes to 16 TB+ (or a lot more) of RAM. It can span from a
4-bit single core microcontrollers to massive RDMA supercomputing clusters. C
contender does not need to cover all of that, but should keep that enormous
range in mind.

The contender should also be able to interface with C library and linking
interfaces. Otherwise it's hard to compose working systems. No matter how
amazing the new language is, you can't build everything from scratch.

So far I've placed my biggest hopes in Rust. But we'll see how the things
evolve. One should keep an open mind. I wish good luck for the Red folks.

By the way, you often can't allocate or free memory in firmware or kernel
drivers either. Like in a kernel IRQ handler or on an embedded device with
hard realtime and stability requirements. In that kind of case GC or manual
allocation would not make much difference at all — you'd only allocate at
initialization or at teardown.

~~~
cmiller1
>That said, it's healthy to have some people exploring alternative paths.
Maybe some of that exploration will be fruitful, way or another.

Exactly. Perhaps it is not appropriate to write production ready drivers and
operating systems that people will use today in a GC language; but in the
future that could change and change will only happen if people take the time
to experiment.

