## Rope

This is my very first post on this site. Also this is my first post regarding my new PL idea: Rope

First, an introduction to me (in a hopefully non-narcissistic way):
Skip over this if you want to avoid hearing someone talk about themselves
My name is Jocob (it was a typo from Jacob; we didn't learn about it until I was 19 and by then I was a legal adult so I had the choice to keep it). I've been programming for about 5 years. First Excel macros, then C# in Unity, and from there I decided to get a career in the field. Now I'm a "DevOps Engineer" (I don't know why they prepended a paradigm onto a job title). Professionally, I work mainly with Python, HTML/JavaScript/CSS, PowerShell, Bash, and increasingly GoLang and Ruby. Personally, I like to use C# both for Windows Apps and for Unity. I'm also building a site on AWS using Django/Bootstrap/PostgreSQL.

I have no experience or education designing programming languages.

If I have seen further than others, it is by standing upon the shoulders of giants. - Isaac Newton

I get it, and I agree with it for the most part; why waste your time doing what has already been done? What progress would we make if everyone started from how to make fire and tried making it to the moon? But there is something that I don't agree with. (Not with Newton, but with a secondary application) Should we all only blaze trails where a previous trailblazer left off? My personal experience has taught me that, if you disagree, then you'll learn more and, rarely, discover something amazing. It is with that mentality that I want to introduce "Rope."

Second, an introduction to ROPE:
Skip over this if you get annoyed reading about people's naive hopes and dreams
The idea is simple: I want a "language to create languages." Here are the main features I'm aiming for:

• Doesn't inherit from Fortran: I want the language itself to help anyone understand exactly how they're instructing a machine to operate, so I want it to inherit directly from machine language. The dream is that someone without a computer science degree could understand how ones and zeros translate to a UI on a monitor if they took the time to read the source code.
• Intention over implementation: Each basic function will have an input/output criteria with a standard implementation. But if someone can propose a better, faster implementation, then that function can be replaced without impacting existing code. This would mean, ideally, that people would never need to worry about losing functionality or rewriting their code in the event of an update. They could just update, and things would work better.
• Both a Script and a Markup Language: While someone would be able to write any application they want in Rope, they would primarily use it to define a higher level language. I'd hope to eventually create ports for other major languages that would allow Rope to import and export to them. Subsequently, this would enable a "translate" feature that recreates scripts in another language. (Substituting raw Rope syntax wherever there is no translation, which would indicate to the Rope developer that the port needs to be improved.
• Prepackaged IDE, Compiler, and Interpreter: Rope would come with everything you need to write and play right out of the box. I know personally that the faster I can see the output of my code, the quicker I can learn it. The compiler would be able to produce an executable file if you write as a script, or it could produce another compiler if you write as markup. The interpreter behaves the same as the compiler, but could also read and run ported languages as long as their is a markup file exists. This would, theoretically, allow for non-interpreted languages to be used live scripts.
• Visually incarnatable: Because the core of the language would be simple, and to help make the language easier to use in other Countries, Rope would be able to be represented entirely visually.
• Built-in basic kernel: To help with being cross-platform, and because Rope aims to be able to directly bridge human and machine, Rope would have an ability to interact directly with hardware. Markups would be written to allow it to read device drivers for various platforms. Ideally this would mean that it could use *Nix drivers and Windows drivers at the same time.
• Community linked at every aspect: Each implementation, for example the "Output to Console" implementation, would have both an "intention ID" and an "implementation ID." The IDE would integrate with an online resource that allows people to discuss and collaborate on each piece of the language itself. You could, in this example, click on the "print" (or whatever it will be called) function, and see the discussion and versioning of that core function. It would allow the language to grow and be discussed much more rapidly than through mediums like GitHub, because it could be done in the middle of coding. (Though that may be distracting...) There would also be a like/dislike voting system for everything, as well as "Implementation Alternates" thought could be seamlessly swapped out during development and then automatically aggregate bench-marking from all willing participants.
• Syntax to define syntax: This is a necessary part of the "language to create languages" goal, but there's no reason why that couldn't be used within the code itself to make things easier. For example, someone could want one script with lots of commenting, and another separate script with lots of string literals. Rope would allow them to configure each script at the start to handle those syntactical preferences.

That's all I got for now. But I'm sure I'll come up with more. The lofty goal behind the "language to create languages" philosophy is that, at the start, everyone tries to make their PL perfectly suited for its purpose. But as we've seen, languages keep expanding and descendants get spawned as a result of either success or failure. So if we had to do it all over again, wouldn't we want a language that intended to have descendants. Wouldn't it have been nice to have a language that lived for its children? That's the idea I want to explore.

Oh and as a final thought. The origin of the name is this:
Recall
Observe
Prove
Express
In terms of how information is handled, it essentially means that it can pull from either memory or the outside world, process it, and then output it back into the world. The name is meant to represent every state of information handling, because that's essentially what a computer is, and be a snappy acronym as well. In regards why "create" isn't included in my theory of information handling, there's actually a philosophical reason for that. I don't think anything in human memory comes from absolute nothingness, and that creativity is probably an illusion.

## Comment viewing options

### "Why are you telling us this?"

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.

### Amibitious

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/

### Grateful

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)

### Ambition and extensibility

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

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)

### I'm speaking to sages

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.

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!

### blackbox-free

PL's, in my opinion, are a daisy-chain of black boxes. Rope, though, aims to be black-box free. I chose Fortran because it is the "Adam" for everything, the original black box.

This is exactly my motivation as well. I went a little further back than Fortran and started from Assembly. So far I have a little Assembly language (really just a very thin layer of ergonomics over machine code) that is self-hosting itself.