Hacker News Reader

This is what I like about Rebol & Red...pity Rebol didn't catch on more. The full Rebol download is a single executable (no real install) and can build GUIs, and so much more in a very small amount of code.

I'm always amazed when I see things like Red, with a 1MB executable with an interpreter, compiler, GUI, networking libraries, parsing libraries, and more all built in.

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.

I've heard of the QNX OS...that seems magical.

Not to mention Red can cross compile for multiple OSes and the parse dialect that is basically generalized, readable regular expressions.

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.

Open it (click the duration), and click vouch. Arc has some (necessarily-)undocumented flagging code, and it frequently backfires.

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.

Thanks a lot for this tip! Actually I'm amazed on how little workforce is necessary to keep this place running. I'm browsing with showdead on and rarely see the flagging backfires like this one.

> didn’t succeed in the mainstream

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

Yea, sorry bout that. Red isn't 1.0 yet and I have very high hopes for it. I meant just Rebol (ancestor of Red) in my earlier post and corrected it.

> it’s still quite new and hasn’t reached 1.0

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)

[2]: https://hn.algolia.com/

Hmm, you're right. I didn't realise it was 6 years old!

Kdb (the weird line-noise functional programming language) is similar. The trial version is a 200KB binary.

Isn't Kdb the database you can program in Q now, but also has K the PL too? I program in J, which is similar. I don't consider it line noise, but I get the drift.

[edit] yes, KDB+ is the database product. Q is one interpreter that interops with it. K is another.

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.

The author of Kdb is Arthur Whitney. He is another extreme programmer who has had a huge influence on fintech and made boat loads of cash I would presume.

Just want to say that it's awesome to see Rebol/Red and K mentioned in a comment thread about Chuck Moore.

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.

Agreed. Very different, yet similar philosophies if you squint hard enough. Aaron Hsu did an AMA on here and put it on YouTube showing his GPU compiler for APL code written in APL. The entire thing is maybe 5-10 pages of one-liners and looks darn elegant to me. During his lengthy talk on HN he shows you don't need zillions of abstractions if you can keep all the code in a few screens. He uses Notepad (not Notepad++ even) as an editor too. To me, in a way that makes sense as having to use a gargantuan IDE to manage your gargantuan code base seems wrong on some level. Forth users just take that sentiment one step further and only even include the primitives in their language that they need.

Relevant hn link:

https://news.ycombinator.com/item?id=13797797

See also the top comment by Dang, with a link to the original thread.

Yes; see the 5th-last paragraph of http://archive.vector.org.uk/art10501320 for a concrete answer to this. (Getting to said paragraph by way of all the paragraphs before it is, of course, highly recommended.)

Yes, I'm mad that the subject of the above URL is still, to quote the article, "dark."

He also helped in the development of J with Roger Hui and Ken Iverson, the creator of APL, by writing a one page interpreter for J over an afternoon or two. I am always drawn to prototyping and writing solutions in J. I am not a web developer, but for mathematics and statistics, it is amazing. I've always wondered how similar and different K and J are on a deep level, but I have always stuck with J.

Norman Thompson has a J book I'm reading and it is mind melting.

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

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.

i don't buy it. dpkg was released in 1994, and that was designed to tame the nest of people passing around small executables on the internet.

> i don't buy it. dpkg was released in 1994, and that was designed to tame the nest of people passing around small executables on the internet.

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

I knew which rant that was going to be before I even clicked on the link. Great memo. Really refreshing Software companies need leadership who actually dogfood the software they make and who care enough to rant when quality, usability, performance, etc. has gone to shit. Too many seem to simply have their noses in their competitors' feature checklists, so their E-mails are all "Company X has Feature Y. Why can't we have Feature Y??"

designed to facilitate, rather

It has always been possible. Sysinternals was doing it 20 years ago. The catch is you had to build with Win32 and not the framework du jour.

wxWidgets has very low overhead. I think I have done some stuff that's also 1-2MB and much easier to code than plain Win32.

"Do not speculate" or YAGNI is really difficult to do past a certain point. You have to vanquish your own FUD one piece at a time. Nobody really does that unless they are really forced to.

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.

> Forth is not powerful. It is ugly, stupid and mean.

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.

Forth is an amplifier. Bad programmers will write very bad programs, good programmers will write very good programs.

I've written a standalone Forth system that could boot from a floppy and recompile itself. I've ported the core interpreter to C so I could use libraries. I've rewritten it using various threading techniques. Up to that point it was just toy systems because i never did something useful with those. Then I rewrote a Forth interpreter than would play really nice with C. That thing right now is around 30k/3KSLOC. This time I wrote various utilities I needed for my job using it. One of them is a log server that runs 24/7 that provides web interface, and I consider making it send emails... So I think I do understand Forth a little bit.

Doesn't your latter post contradict your previous post? If Forth is not powerful how did you manage to do such things with Forth, and why did you stay so long with Forth despite its "ugliness" and "meanness"?

"powerful" too often means "it does things I don't really need or that I don't even understand; but hey, I might use them someday" - or at least that's how it sounds to me.

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

> "ugly, stupid and mean" is actually intended to the beginners or to those who want to try it.

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.

> 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

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'd love to see if in 50 years we're closer to Smalltalk, Haskell, or something completely different. I'd love to say something radically different, but I have a feeling static types will continue to increase in popularity. No real evidence, just a gut feeling. 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'd love to see if in 50 years we're closer to Smalltalk, Haskell, or something completely different.

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

For me your last sentence is not an argument why OO is "more powerfull and better". The banana can be peeled very well by anyone or anything with an opposable thumb (a function). No need to limit yourself to a gorilla (an object).