Has anyone here (particularly Forth folks like @Jeremy Penner) heard of sourceless programming? I came across the term in https://news.ycombinator.com/item?id=20550656, and the best description I can find for it is in some of the slides of https://docs.google.com/presentation/d/1wL2eqf7eHGEybsK0C4MUB4ibP1z6voyhgYfUSNhuBQA/edit

This looks very intriguing. About to crash now, but will definitely share here if I unearth something.

I don't have time to read this yet, but this is what I found: https://www.google.com/amp/s/trollheaven.wordpress.com/2018/12/28/can-do-forth-this-an-introduction-into-sourceless-programming/amp/

According to the following secondary source, Chuck Moore invented sourceless programming as a simpler alternative to Forth, but later realized that it had been a mistake. https://news.ycombinator.com/item?id=2574271 Here's a primary source: "A few years ago I gave up on Forth, it was too complicated. It was about the time of the work of the standard committee and I wanted something simple. I abandoned source and used a decompiler to view the object code. It did not really work." http://www.ultratechnology.com/color4th.html

Still a fascinating mistake to make 🙂

this looks like an ok historical account except for the horrendous formatting and contrast: https://flagxor.com/article/source-code

From @Dan Cook's link:

Suppose the idea is to drop anything and start from scratch. Forth will be your friend in such a situation. Forth forces the programmer to invent everything.. And even [if] a library is available. a real Forth developer will ignore it and writes his own library which is simpler.

I said something similar a couple of years ago (https://plforums.org/practice/minimal-features-required-for-an-extensible-language#post_65):

Forth doesn't seem to be a write-once language/stack. But it does feel like a solipsistic stack, with everyone working in their own little private universe.

The tension we're both seeing is between two incompatible ways of programming: 1. Rely on code from lots of strangers. 2. Rely on nobody. My synthesis: ignore both 😄 There's a third way, and it's the way that I think we should all pursue. Call it the Amish way: 3. Rely on code from a small number of very carefully curated people.

The article I shared implies that "sourceless" means to not use any pre-existing code or runtime or anything. But it sounds like Charles Moore used that to refer to working with FORTH code directly in its machine executable form, with no intermediate representation in between writing and running. ... I have a guess as to what he might have been up to with that, but I'll have to come back to this later.

You're right, the term only shows up in the title, and I don't think the author is aware of the other connotation. @Garth Goldwater's link is the winner so far.

Garth's article actually also covered what I was guessing, which is that by making the "source" code and execution code be the same thing (e.g. perhaps by picking a storage representation that works as both), you then have "one source of truth". That idea is actually an integral part of my project(s) / vision. The point is to allow software to be inspected and modified in place by its users, so that one can control their own environment. It's also to allow a program to contain it's own editor and language, so that programming consists both of sculpting the program and the sculpting sculpting experience. I don't have an exact destination in mind, but the point is to make it possible and easy to experiment in that space by also sculpting the exploration as it happens :) ... Also, I'm beginning to see that I'm not the only one with some form of that idea. Anyone else doing something that's "sourceless" in some sense (or by some stretch)?

FORTH programs win the smallest source file contest every time. LISP comes in second. The beauty of FORTH is that it used an implied push-down stack without needing parentheses. However, like postscript. prefix languages are a bitch to read, and require the reader to memorize the number of parameters used. Thus FORTH (and LISP also) programs become "write-only" documents, where even the original author shortly thereafter cannot remember how they work. It doesn't matter how productive a language is, if the work cannot be shared with a team member, the business community will discourage its use. I am looking forward to the clinical trials with my language where we measure mean time to repair for small bugs. That is the acid test...

@Edward de Jong / Beads Project Do you think a different visual formatting on the Forth code could alleviate the need to memorize the bracket stack?

No question in my mind that visual aids could greatly alleviate FORTH's main drawbacks to readability. FORTH is so old people don't imagine it has value, but its better than APL, because the dictionary is expandable. Frankly postscript is also similar to FORTH in using a prefix notation that requires the reader to know how many operands are absorbed. Postscript is very powerful (and dominates document interchange to this day), but it sure isn't easy to read.

I wrote an evaluator that benefits from FORTH-like definitions, but otherwise is very much like lisp / scheme. Essentially, there are no built-in commands, and everything is looked up in the current context object, which is a dictionary. All the evaluator functions are defined in a "root" context (a new context is created for each call, with a reference to it's "parent" context), so everything down comes from (or is accessible via) dictionary entries

Edward: I'm skeptical of the claim that Forth is write-only. Like Perl, you need to pay special attention to stay readable. Unlike Perl, you don't have lots of people writing Forth code without intrinsic motivation. So it tends not to be a huge issue. Certainly, experienced Forth programmers don't forget code they've themselves written in the past. IF businesses were to start hiring people to program Forth, this would become a problem. (Akin to bioinformatics projects using Perl in the oughts.) But they don't, so it doesn't. If you said "Forth programs could become write-only" I'd have no objection 😄 @Prathyush: Visual formatting is a novel idea, but I don't think it addresses the real problem with Forth: there's no type system. Not even at run time. This means that interfacing with someone else's code is hard. If you get a type wrong somewhere on the stack, the error may not show up until much, much later.

Sorry Kartik, but you are talking to a guy who was around when FORTH was hot and new. It was a favorite language of the embedded system people (this is Apple II era we are talking), and in those highly memory constrained days, FORTH had an incredible advantage with its microscopic runtime and executable sizes. There was even a word processor written in FORTH that BYTE magazine reviewed highly. But like all write-only languages, it's star dimmed once teams started to try and use it. A single programmer can use any language, but for teams you have to have transferability; and the number of facts one has to memorize to understand a large FORTH program makes it a big challenge. Forth is not only compact but lightning fast. It is among the fastest languages ever made, because when you use the stack like that you are always in cache. Not all programmers have a photographic memory. I used APL back in the day, and a month later i couldn't read my own code. APL is very dense, and it requires a very strong memory. LISP, APL, FORTH, are all powerful languages, and will always stimulate interest, but when you apply the test of handing a large program with some bugs to fix or improvements to make, to a new programmer they fail that "mean time to repair by non-author" test so badly that management is tempted to scrap the codebase and start over. We haven't seen much testing by academics on this critical measurement of a language, and once i get the funding i will perform this test on a variety of languages, and improving this measurement is the main focus of my language research. In their spec sheets disk drives quote a mean time before failure time, for software the mean time to repair is the number that matters for languages, and yet no chart is available showing the measured mean time to repair for transfer of a program. Since software lasts decades, at the end of 25 years, the total money spent on repairs and improvements dwarfs any initial cost, hence the massive resistance in our industry to what are otherwise clearly higher leverage languages who possess a high MTTR score. When one is an indie developer, which i have been much of my career, you have the freedom to pick the highest leverage, most pleasing to your own taste language; in my case i used Modula2 for 20 years to great results. I got a ton of crap from others about it, because it had only a tiny swiss/german following. But a 2:1 advantage over C which is what Modula-2 has, was definitely worth using.

@Dan Cook did you publish this anywhere? would love to take a look at it

I was the lead programmer on a huge C project called WordStar 2000, the sequel to one of the greatest programs ever written. Wordstar was written in Assembly language, hundreds of thousands of lines of code, and ran in an astonishing 0.6 megabytes of memory. However nobody could understand or add function to the original code base but the genius author Rob Barnaby. So a team of 12 was assembled. We use the Microsoft C compiler for the project, and after a year of R&D we shipped pretty good product. But it was painful having 12 people on a team; people would change the parameters to functions, and there were lots of pointer-related problems; indirecting through a garbage pointer in C basically randomly overwrites memory, causing super hard to fix bugs. So after that project was over I started a company to make a desktop publishing product similar to InDesign (except running on DOS), and i switched to modula-2. It was immediately apparent that the superior logical design of Modula-2 solved most of C's weaknesses. I went on after that DTP project to make Flying Colors (still runs on Windows after 25 years!) and the Discus labeling program. All written in modula2 which is cross platform with Mac and Windows. In comparing my final product with the many competitors, it is clear that Modula-2 generates executables about half the size of C (not because of compiler tricks but because you get a higher degree of sharing). The ability to separately compile components is superior to C/C++ even today. Modula2 received a self-inflicted wound when its designer Prof. Wirth created the sequel Oberon, which was not compatible with Modula2 because among other things, for some inexplicable reason, removed enumerated types, making it impossible for his user base to transition gracefully into Oberon. Oberon competed against the OOP paradigm, but without any commercial entity pushing it, C++ and Java took over, and all of Wirth's work is now ignored. He is a really elegant programmer with that Swiss minimalism touch. His book on Algorithms + Data structures = Programs is still a solid book. He is in his 80's now, he is one of the only small teams to make a whole machine + OS from scratch.

Amazing! what would you say are the principally defining features that made it so productive compared to other languages? ie, if i were to look at the docs for some design pearls, what should i focus on?

@Edward de Jong / Beads Project , what's your opinion of Rebol / Red?

In reply to Garth, Modula2 had the following beneficial properties: 1) one of the simplest languages ever devised. 100 page manual covers the whole thing. Only one way to do most things, so it falls into regular patterns easily. 2) it concentrated on having very powerful composable yet readable data structure type defns. so you could define an array of pointers that point to a record with a field handler which is a function that returns a string, with a syntax that is lightyears clearer than C. you could compose complex types out of simpler ones. And when you are running the program, the debugger knows how to present your data. So clean and clear, it makes C look like the near-assembler mess that it is. 3) only Modula2 and Beads to my knowledge compile definition files that are separate from the implementation files; this means that as long as you don't change the interface to a module, you are free to change the code in that module and the calling programs won't be affected. In small scale programs, C header files (.h) don't hurt you much, but when you have 100k lines of code, compiling the C header files is a huge time waster, and much less isolation. Modula2 had a few fancy things like opaque types, where you can define a pointer but don't let people see what is inside. A minor trick but clever. 4) the big win was the massive quantity of runtime checks; every array bounds in both directions is checked, all pointers are validated before use, etc. You can turn off the runtime checks for your golden master version, but during development the extra 30% overhead in code size and perhaps 10% runtime speed loss is a small price to pay for catching errors right at the source. Integer overflows, conversion errors, it does every check you wish C had. It also had the ability to pass records as a constant very efficiently. But keep in mind that Modula-2 was intended for systems programming, and had no drawing functions in the language; on windows you had to use GDI with its clumsy function calls to create windows, select brushes into contexts, etc., so everyone using Modula2 had to build their graphics library routines. Modula2 forces you to be very accurate and precise about the type of things, but it also protects you very strongly. JS and Python are opposite philosophies, very little definition power in those languages. On big projects a tight language is so much more enjoyable, as you are fighting ripple effects more and more the larger the project is, and the sloppy languages make a big project like nailing jello to a tree.