Live data from Hacker News

Red Programming Language: Plans for 2019

red-lang.org

111–120 of 141 posts

Re: Red Programming Language: Plans for 2019

#111
post #103

Earlier quoted context omitted.

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

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

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

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

Re: Red Programming Language: Plans for 2019

#112
post #110

Earlier quoted context omitted.

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

> 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 y…

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

Re: Red Programming Language: Plans for 2019

#113

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?

Red's author here. The answer to your question is, I think, that it is just not ready for prime-time yet:

* Language and runtime library are at version 0.6.4, so still alpha stage.

* Lack of support for mobile and web platforms (Android support is coming this year).

* Documentation is largely incomplete, still relying on Rebol docs for core parts.

* Community is very active, but still tiny, it needs to grow much bigger.

Re: Red Programming Language: Plans for 2019

#114
post #54
post #48

Earlier quoted context omitted.

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] *…

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

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

Red's author here. I have nothing to do with those websites nor their content. They are not official Red nor Rebol sites. I do not see a single quote from me there, nor from Rebol's author. Stop spreading false information please.

Re: Red Programming Language: Plans for 2019

#115
post #92
post #78

Earlier quoted context omitted.

> (Are Red/Rebol creators seriously claiming that Clojure's syntax is complex?) The huge paragraph you're responding to refers to the programming stack as a whole. In reference to Clojure, it's including the JVM.

> encumbered by mainstream language syntax and development procedures which introduce an extraordinary volume of unnecessary complexity at many levels. This clearly states about Clojure that its syntax AND it's procedure of development (another grand claim) introduce said complexity. That whole write-up is just about as incorrect as it can get: > Virtually every other well known development tool in popular use is bui…

> Never mind that Red is actually implemented in another abandoned proprietary language[0]!

Github's code breakdown by languages for red/red repo:

* Red 83.8%

* Rebol 15.7%

* C 0.2%

* Visual Basic 0.2%

* Java 0.1%

* Shell 0.0%

Only the compiler is implemented in Rebol, the rest, including the interpreter, the consoles, the GUI system and the whole runtime library are implemented in a mix of Red and Red/System. From top of my head, it's about ~25k LOC for the compiler/toolchain (in Rebol) and ~130k LOC for the REPL and runtime library (in Red and Red/System).

The use of Rebol is only for boostrapping the language. The whole Rebol code part will be dropped after 1.0, and the toolchain rewritten in pure Red.

Re: Red Programming Language: Plans for 2019

#116

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

It is "amazingly simple to get started" but also amazingly difficult to go much deeper. Some of this, imo, is because the preferred introduction to Red/Rebol is commonly the view (GUI) subsystem. Gradual documentation or other structured paths to the deeper end of Red/Rebol appears to be non-existent. I've seen Red compared to Lisp, Smalltalk, and Forth and other concise languages. But Smalltalk syntax can famously b…

> Where is the BNF?

Here [1]. Red and Smalltalk syntax look similar, but semantics are very different. They only relation to object-oriented languages Red / Rebol have is through prototype-based OOP, e.g. Self [2].

Forth doesn't have any grammar specification AFAIK - any space-separated string of ASCII tokens is a valid Forth program, but it may vary from dialect to dialect. It's more of an idea than programming language.

[1]: https://github.com/meijeru/red.specs-public/blob/master/spec...

[2]: http://www.selflanguage.org/

Re: Red Programming Language: Plans for 2019

#117
post #111

Earlier quoted context omitted.

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

> 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 p…

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.

Re: Red Programming Language: Plans for 2019

#118
post #110

Earlier quoted context omitted.

> 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 y…

> 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 trie…

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

Re: Red Programming Language: Plans for 2019

#119
post #118

Earlier quoted context omitted.

> 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 trie…

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

> 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

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.

Re: Red Programming Language: Plans for 2019

#120
post #116

Earlier quoted context omitted.

It is "amazingly simple to get started" but also amazingly difficult to go much deeper. Some of this, imo, is because the preferred introduction to Red/Rebol is commonly the view (GUI) subsystem. Gradual documentation or other structured paths to the deeper end of Red/Rebol appears to be non-existent. I've seen Red compared to Lisp, Smalltalk, and Forth and other concise languages. But Smalltalk syntax can famously b…

> Where is the BNF? Here [1]. Red and Smalltalk syntax look similar, but semantics are very different. They only relation to object-oriented languages Red / Rebol have is through prototype-based OOP, e.g. Self [2]. Forth doesn't have any grammar specification AFAIK - any space-separated string of ASCII tokens is a valid Forth program, but it may vary from dialect to dialect. It's more of an idea than programming lang…

It is good to see there IS a specification; I - and I think some others (see the Temple OS comments) - had concern Red/Rebol might actually be too ad hoc (throw things against the wall and see if they stick).

Is there means to access the lexer directly as a means to explicate how, exactly, Red is interpreting? The use of blocks in Red, and the layout in general, did remind me of Smalltalk but in Smalltalk I could at least rely on really simple syntax rules including some really useful grouping tools to break things up into more human friendly chunks (parens; semicolon; and period).

The spec says "*

As a first operation of the toolchain, the text file will be subjected to lexical analysis which will break the text up in a series of lexemes, i.e. textual representations of Red single values, interspersed with grouping tokens. The grouping tokens should occur in properly nested pairs, and are the following: ( ), [ ], #( ), #[ ]. A sequence of lexemes enclosed in matching grouping tokens represents a Red grouped value of a certain type, and this construct may again be enclosed in grouping tokens etc. Note that the token pairs " ", #" ", { }, #{ } and each delimit a single value, they are not grouping tokens...As a rule, lexemes must be separated from each other and from grouping tokens by one or more whitespace characters.*"

Anyway, I think trivial access to the lexer output, so one might SEE exactly how the Red interpreter is viewing things, would go a long way toward dispelling the "Temple OS" concern and providing that on-ramp that IMO is otherwise missing.

Any help on this front?

Post reply on HN