Lambda the Ultimate

I wasn't being very considerate, sorry. I was just so excited about my idea that I didn't even think to mention why I'm even on this site!
I googled how to publish a language and someone on StackExchange recommended this site. I visited and saw all these amazing resources to learn about creating programming languages.
So I decided this is a great place to start, and thus, here we are. I wanted my first post to be about the primary motivation for my joining the site.
Thanks all for your understanding!

It sounds like quite an ambitious project. Reading through the list, it seems unlikely that some of those ideas would be doable, but I don't say that to discourage you -- you'll just need to learn to selectively ignore some of the things that people tell you can't be done.

My suggestion would be to find an existing project that is compatible with the ideas that you have, and start your experimenting from a fork of that project. Perhaps something from LLVM, for example: https://llvm.org/

Edit: Something else to look at: https://www.antlr.org/

Thank you so much for the sources, cpurdy! I'm very curious what I'll find there.

And thank you also for the naysayer-resistance training, and I agree. I like the way you phrased that, too. I'm sure skepticism would be based on either insight or ignorance, and it will be a learning experience to develop the ability to discern between the two.
_{(I tried "reply" and nothing showed up, sorry if I doubled up this comment)}

A few thoughts. Sorry if I run on a bit (you've struck close to some of my interests, here).

As remarked, your project is ambitious. In my own experience, when tackling "big" problems, it's tricky to steer between studying too much and too little of what others have done. Too much, and you can get stuck in the same ruts of thinking they did [ NOTE: this may be an argument for not reading any of the rest of what I have to say :-) ], and also spend so much of your time trying to "catch up" with them that you're too busy to forge past them into really new territory. Too little, and you risk not only reinventing the wheel, but also repeating mistakes others have made; both ones they learned from, and ones they didn't (or learned the wrong lesson from) that someone else with a skeptical eye might see more clearly. A favorite strategy of mine, fwiw, is to bypass obstacles by changing the rules: if something can't be done, find a way of accomplishing what you're really after without having to try to do the un-doable. I've also observed that sometimes it's really hard to overcome folk-wisdom conditioning that something can't be done (it took me several years, at the start of my dissertation research, to unlearn what I'd been taught about the supposed theoretical intractability of fexprs... but I digress).

In similar spirit to your quote from Netwon:

The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. — George Bernard Shaw

Make no little plans; they have no magic to stir men's blood — Daniel Burnham

More specifically, some history that may be relevant to you (that conceivably you might not have encountered, as I've the impression it's unpopular atm). Back in the 1960s, an area of cutting-edge PL research was extensible languages. The idea as typically envisioned was, you have a "base language" that has extension mechanisms built into it, and you write code in the base language to make it more suitable for the particular sort of programming you have in mind, followed by code in the extended language. Ideally, with the right base language and extension mechanisms, you could do everything you'd ever want to do. The two main sorts of extension facilities were macros, and syntax extension. The whole extensible languages movement reached its peak around 1970, with a couple of symposia. Simula, modernly often billed as the origin of much of the OOP, was presented as an extensible language. The Lisp community was always somewhat separate from the extensibility movement, but some of the extensibility folks did acknowledge that Lisp programmers had been off on their own doing extensibility for years (as a natural consequence of treating code as data). As the extensibility movement drew together around 1970, though, they were also realizing it had failed to realize their hopes for it. Within a few years after that, the extensibility movement fizzled, and was replaced by abstraction, within which OOP later became dominant.

The trouble with macros, the dominant technology of the movement, was that while you can write one layer of macros on top of your base language, you can't easily build a second layer of macros on top of that. This seems to be because, at the point where you call a macro, all the stuff used in its expansion has to be visible too (or the macro wouldn't work), and you can't get away from having to know what the macro expands to. So the amount of stuff you have to keep track of just keeps increasing as you try to build up multiple layers. The idea in abstraction is to hide the underlying stuff, so that as you build up layer after layer you don't have to go back and study and understand all the lower layers at each step. Or, that's the theory. How else to rethink the way all these elements are put together... is left as an exercise for the student. :-)

As for syntax extension, that seems to me to have continued developing along a separate track. I did my master's thesis on Recursive Adaptive Grammars in the early 1990s, and in researching the subject worked out all this earlier history. A point sometimes remarked upon: when you look at a piece of code, you don't want to be in the position of not even knowing how to parse it. Over some years thereafter I developed a techreport exploring the consequences of that, "Well-behaved parsing of extensible-syntax languages" (pdf).

(My own PL design explorations have in the past couple of decades migrated toward interpreted PLs.)

can you tell more about the rational for these feature?
For instance "Doesn't inherit from Fortran" you say that a person should understand how ones and zeros translate to a UI on a monitor.
What does it mean to understand code? Is it knowing how to change it to get different effects? Is it knowing the full range of behavior? Is READING source code the best way to understand it? Would diagrams, graphs or interactive poking be a better (more efficient, easier, or more in depth) way of understanding?

What property are you hoping to gain by focusing on machine language specifically? Are you hoping that if you reduce it to the smallest parts that there will be no surprises left? Or is it a promise that at some level the code will be fully documented such that by fully understanding the parts you can slog through and end up fully understanding the whole.

How does this interact with the possibility of interpreting some code instead of compiling it, or with your promise of easy replacement of functions.

I am also interested in hearing more of your thoughts on what it looks like to merge community discussion and codeing. (also the community might document various idioms that each function is used in because idioms are a more fundamental element of program construction than functions are)

Wow, there's so much nutrition in these comments! I'll do my best to reciprocate the attention you're each giving this topic, and I'm again very grateful for each of your insights. This site is quite niche, so I expected that its members would have to be made up of either wise sages or passionate explorers. I'm not disappointed in that regard.

First up, I've started going my homework.
cpurdy, I've taken a preliminary look (reading through the homepage and familiarizing myself with the site tree), of both your links. It's immediately apparent why you mentioned those two projects. LLVM boasts "supporting both static and dynamic compilation," which is very interesting. ANTLR, on the other hand, claims that it is "widely used to build languages, tools, and frameworks" using advanced parsing utilities. I imagine that's going to be a nice resource to look into (assuming they publish their code, or it's a JavaScript driven web-app that I can just reverse engineer).

Secondly, what a quote!
(Short section, but I wanted to highlight how much I enjoyed that quote by George Bernard Shaw. I was reading it and could feel my heart reacting with "But I want to adapt the world to myself; what's wrong with being unreasonable?" And then I got to the end of the quote and my sentiments instantly revised to "This guy gets it...")

Third: what a respectful and encouraging way of presenting skepticism.
John Shutt, that's such an applicable history lesson! You certainly aren't bluffing when you say that this topic aligns with your interests. I do get the "don't reinvent the wheel" talk a lot, looking back through my life, and I don't disagree with it in principle. But I'm glad to see what you wrote about reconditioning yourself away from the assumption of impossibility.
Also, that advice about trying to explore solutions without attempting the un-doable, isn't something I'm well-practiced in, but I still like it. I'm trying to find the middle-ground between taking on a monumental and thought-to-be-impossible endeavor with passionate optimism, and still not getting so mired in the dead ends that I lose out on the joy of seeing my idea take shape. Adopting a soft-skill like what you describe seems like a good start to navigating through that valley.

4th: Extensible Languages, huh?
As a lifelong nerd, that story spoke to me. It has an "ancient and forgotten civilization" feel to it. To think that there was an entire movement around this concept, and that it was forfeited due to fundamental issues with the technology... Honestly it's getting me more excited than it should. (Logically that should be a discouraging story: 'People tried it, and failed.') It's exciting to me for two reasons:

1. If hundreds of people felt it was worth putting decades of work into the idea, but the ultimate result was for the most part a failure, then figuring it out would be an amazing accomplishment! I remember hearing that people claimed the 4-minute mile was a biological impossibility for humans. I also heard that people claimed building an airplane was a mathematical impossibility. Obviously the claims were wrong, but what the skeptics DID contribute was defining a frontier. In this day and age there are precious few frontiers left to conquer, so... I'm very thrilled to hear about that story.
2. If they put that much work in it, then there are probably a lot of "ruins" to explore and "ancient documents" to decode. I'm also excited by the prospect of exploring the ghosts of the past, and stealing their relics for my own journey.

I'm looking forward to getting into your material to learn more! Thank you for the links and the fascinating story!

5th: Yes I can tell more!
Anders Horn, hi! I'll never shy away from the incentives behind my agenda.

• Why not Fortran? PL's, in my opinion, are a daisy-chain of black boxes. Which is fine! What front-end dev wants to know about sockets and TCP/IP? Rope, though, aims to be black-box free. I chose Fortran because it is the "Adam" for everything, the original black box.
• What is understanding? Here's an example of a Commodore 64 cheat sheet for Ponk. Obviously it's not everything because it doesn't include any hardware info, but it does map effect to binary (technically not "binary," but close). So, what I'm imagining is that Rope could handle the mapping between every layer. It could handle binary to hex, hex to memory allocation and hardware interfacing, then from there to abstract concepts like arithmetic, which would then collect together for things like conditionals and looping, and so on and so forth. You wouldn't need to look at each *.rope file if you didn't want to, but if you wanted to drill down all the way from something as high-level as a UI icon's response to a mouse click, all the way down to what hardware was being sent what array of binary on what USB port, then you could. And along the way, each file would have comments, and each mapping would have examples (where possible). And the goal would be that, if you can read Rope, and it's made with Rope, then you can untangle it all the way down to the tiniest strands.
• Is source code the best way? Good point, and probably not in all cases. One thing I'm really hoping to do is have the IDE thoroughly connected to the Rope community. (Working on a name that isn't anything close to "Ropist") In a similar way that GIT allows you to create README files with visual content based on their URL, I'd like the IDE to be able to render things based on a link to the community page. It'll require online access naturally, but it would allow people to comment the code and upload images that the rest of the world would be able to see.
• What do you gain from machine language? Just going back to the black box point from before, I don't want any part of the language to be off-limits. The downside of course would be that it's impossible to protect your intellectual property (though I guess you could just "Rope in" another language and compile it as binary when you're ready to distribute), as well as security. (But at least with the no-black-box rule any virus made in Rope would be easy to reverse engineer and counter) I like what you said about "slog through and end up understanding the whole." That's pretty much hitting the nail on the head, but I do hope to structure it in a way that limits the sensation of "slogging."
• Interpreting vs Compiling? I could be way off base, but I've read that interpreted languages are still compiled, they're just compiled live so that the developer doesn't need to build their project and run it separately. (I'm sure there's a lot more to it than that, but...) Because the language would be built with the aim of building any language with any paradigm, then interpreting would be a vital feature. When configuring a compiler, a Ropemaker should be able to set it up to translate human-readable script into behavior without creating a binary executable file, and they should also be able to configure it to actively watch that script file and revise the process on a detected change.
• Community Integration? While I do like doing everything myself, I have to face the reality that I can't build something of this scale on my own. Community support is the only possible way this language would get off the ground. But more than that, I want it to operate sort of like a Wiki page. Another reason behind the no-black-boxes rule, is that each and every piece of the operation of Rope would be, not just human-readable but human-debatable. Take for example the simple if command found in so many languages. On a very low level, how is it implemented? (I actually don't know, please don't judge me) So let's say I make an if command, and it sucks. It gets the job done, but it takes 10 operations to complete. I'd like for some genius out there to be able to drill down to my if implementation and challenge it. The IDE would give him three things. First, the IDE would give him full access to how if actually works. Second, the IDE would allow him to publish an alternative implementation. Everyone else would be able to browse through a library of implementation alternatives for the if command itself, and his new implementation would show up on that list as soon as he publishes it. Third, the IDE would be able to collect benchmark data on that implementation all around the world. (People can turn it off if they want) That benchmark data would show up on the online implementation library as a part of its score. Additionally, people could comment and vote on their favorites as well. The composite score would eventually determine a winner, and that winner would ascend to the "Official Implementation" spot. I figure that, as long as interface is clean and the community is kind, then over time the language itself would get better and better. And it wouldn't be like a public project where people fork and propose; rather, it would be such an integral part of the language that even the laziest and the shiest of indie developers would feel comfortable contributing. I believe that because when you contribute to some huge project, especially one coordinated by a major enterprise, it's easy to feel intimidated. But if you're just making a suggestion tucked away in a tiny little corner of the project, and you can do it without even having to turn your head over to your other monitor's web browser, then it's a lot more likely you'll click that "Contribute" button.
• Idioms too? I agree. I want everything in the language to be controlled by the community (I may regret this later if the community decides to completely change something I wanted...). One complication I haven't quite hashed out yet would be conflicts and redundancies. For example, if someone makes a GoTo implementation, and another makes a Jump implementation, then what happens? I don't want to limit what people can do, so... I'll have to think about that one. I'd like to come up with some system that could eventually merge aliased aspects after enough vetting, but I need legacy support so existing code doesn't stop working. I suppose I could have a warning pop up when you log into the IDE that says something like "You're using an obsolete alias of Jump: GoTo, may I update your code for you? That might work...

Sorry if I got a bit ramble-y, but I appreciate your giving me the opportunity to talk more about it!

Kartik Agaram, you know, that's a really good point! I based the Fortran comment on PL genealogy charts, but I didn't think to look up what Fortran was actually founded on. I just... assumed that... nope, can't think of an excuse. Also I'm glad you posted your project link. This page is becoming my reference guide for all the research material I need to delve into. I'm going to need to host something somewhere that starts to compound all this, though. Github probably is the most sensible choice...