Or the QNX demo disk back in the day. OS, GUI, web browser (with javascript), full clustering support, and more, on a single 1.44MB floppy.
My personal theory why Rebol/Red didn't succeed in the mainstream is steep learning curve, it's hard to discover how to do things if you haven't already done some substantial programming work in it. While built-in help is good you need to know what you're looking for. (Delphi had better help in this matter, with examples etc.).
By the way I wonder why Pecan's post is [dead], it doesn't seem to be violating any rule.
The worst-case scenario is when you open the account in question and every single comment is grey... it hurts to see. (In that case, the account itself has been flagged. Not quite the same as reddit's shadowbanning, but only technically not the same.)
It's bittersweet that the moderation here is paid: there are AFAIK only two people (but don't quote me on that). There were some hazy plans to give some users fractionally elevated capabilities at some point, but it just hasn't happened yet.
Is that true of Red? I was playing with it the other day and it looked really promising, and I was under the impression that it’s still quite new and hasn’t reached 1.0 (my point is that it might not be at a stage where we can write it off).
According to the main page [0] the project was unveiled 6 years ago. For comparison Rust (a random example) started 7 years ago [1] but compare results for "Rust" and "Red/Rebol" on Algolia [2] (sorry no deep links). It's clear Red is niche.
I'm not writing it off. It's definitely one of most interesting languages and runtimes but it's super hard to capture people's attention nowadays when you don't have support of large companies (Go, Rust, .NET).
[0]: http://www.red-lang.org/search?updated-max=2011-03-29T15:38:...
[1]: https://en.m.wikipedia.org/wiki/Rust_(programming_language)
I am not 100% sure but I think Q is actually K plus a standard library of "Q words" so you can write K directly if you want.
I think the reason for Q is as a more familiar interface for people with SQL experience.
It's interesting because Rebol and K have almost totally opposite philosophies about how software should be structured. K emphasizes flat namespaces and leans heavily on the primitives and only a handful of functions. Rebol encourages writing DSLs to fit the language to the problem.
But despite different philosophies, they both allow incredible programmer productivity. I think a lot of this productivity comes from adherence to "Do not speculate!" and therefore not having a bunch of non-useful functionality or boilerplate for the end-user programmer to have to manage.
https://news.ycombinator.com/item?id=13797797
See also the top comment by Dang, with a link to the original thread.
Yes, I'm mad that the subject of the above URL is still, to quote the article, "dark."
That might have been more to do with how hard publishing code to the web was back then, an internal process problem, which discouraged tiny stand alone exes from being put online.
The problem is corporate policy. In the yee old days, publishing content to MSDN was not easy. Bill Gate's rant[0] on this topic gives some insight.
Grabbing small EXEs is now a lot easier. See: https://docs.microsoft.com/en-us/sysinternals/
[0]http://blog.seattlepi.com/microsoft/2008/06/24/full-text-an-...
Ignore the occasional statements in forum threads about how Forth is so powerful.
Forth is not powerful. It is ugly, stupid and mean.
Because of this, you simplify, simplify and simplify again, up to the project's specs if you can.
That's a statement of someone who doesn't understand Forth. Of course, one can write ugly code easily. Any language with raw power (Asm, C, Forth, Ada) needs a disciplined developer to get beautiful and maintainable code. Forth code can be really beautiful if the vocabulary is well thought out.
I consider Forth the best choice for tiny iOT devices, Firmware, and other essential things which can be kept simple and stupid, following the KISS principle which works very well in many cases.
Our vastly proliferated software security problems come from complexity which developed by despising the KISS principle. Many developers didn't choose the simplest way, they chose the most convenient way. Now, we realize that keeping things simple and stupid is not that bad after all.
"ugly, stupid and mean" is actually intended to the beginners or to those who want to try it. That's what most systems are out-of-the box, especially for the minimal ones (bigger systems like gForth might be a bit better).
That's their starting point. R> and R> are hideous so at one point they'll want to replace them with "pop" and "push". Stack juggling looks bad so they'll have to learn to minimize them. And they'll have to get used to RPN. There's no GC and not even heap allocation (unless ANSI-Forth added it as an extension since the last time I checked?), so they'll have to deal with the lack of memory management that are in every other high-level language. There's neither static nor dynamic type checking so they won't get any warning if they dereference a character. Instead, it will crash again and again without any stack trace.
So they'll have to deal with all this ugliness, stupidity and hostility that they won't expect "enough" because Forth fans praise it often without a warning about the fact that it takes a really long time to fully tame such a rabid language.
Why did I stick with Forth for so long? I made it progressively more beautiful for me; I learned to fight complexity and factor, which indirectly prevents mistakes; I implemented warnings in my system for mistakes that are hard to find (e.g. a redefinition) and are easy to check for.
When I encountered Forth first (6502 figForth) I felt it quite convenient. At that time there were only two other options - Basic and Assembler. Maybe that most developers today are too pampared by all the available IDEs for other languages. It's the same attitude why so many people stick with Windows instead of learning OSX or Linux, despite all the flaws of the Windows ecosystem.
> lack of memory management that are in every other high-level language
As already mentioned, I consider Forth suitable for tiny systems, iOT, Firmware etc. I would never use Forth for big software. I would not use even C++ for that. In that area Ada, Rust or Nim works much better for me.
What Joe Armstrong (who I admire) complains about is actually what I love about OO languages. And for me that's the true essence of what OO is, and how it differs from non-OO. People keep trying to frame OO in terms of mutability (completely orthogonal) or C++/Java coding practices (C++ doesn't define OO because it has objects, anymore than it defines FP because it has lambdas).
The real difference, the real paradigm shift is in data + functions vs objects. And I maintain that objects are more powerful and better idea than data + functions. The banana can't be peeled without the gorillas opposable thumbs.
I guess in my mind FP and OO are orthogonal. If I write an immutable object and I send it messages that are referentially transparent, am I not doing both? Would it help FP people if they thought of such objects as "a record of partially applied functions"? So I hope both. I'd love if there was a statically typed, high level pure OO language without all the cruft of Scala or C#. Maybe I have to wait for the next programming fashion cycle for that to happen.
> Thanks for posting your feeling on OO. In some ways I've always felt very restricted writing OO (even in Python), but learning Smalltalk is making me see it from an entirely different perspective.
I often wonder if I need to coin a better term for "OO" for what I am talking about. Alan Kays whole schtick was that objects contained both data and procedures, but by combining them they became something new, and more than just the sum of their parts. That's the powerful idea to me. But language changes, and OO in 2017 just means "Java".
It reminds me of when, e.g., a 1990s-2000s Windows user needed a small program that does one thing, and in order to get it, the download from Microsoft was an installer with hundreds of megabytes of unneeded binary files. It was not possible to download only the single program, which was no more than 1-2MB in size.
It reminds me of this quote: "The problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle." - Joe Armstrong
It reminds me of bloat, of giving users things they do not need. A problem that continues to this day.
Instead of bloated, complex UEFI, I wish something like OpenBIOS/OpenFirmware/SmartFirmware/OpenBOOT would be available for today's hardware. I have played around with fgen on i386 and read some of the history. They even provided courses on how to write drivers. Besides OLPC, why did this not catch on?
IMO, Forth is the most elegant and flexible language for initializing hardware.