I'm currently making a programming language that tries not to be a programming language.
To give some background: I'm working on a program to allow anyone to create video games. But to add custom functionality, my users need to use some kind of programming/scripting language. Since these are non-technical people, it must be as easy and simple as possible.
Therefore I'm now making a language (called Screenplay) where you don't really have to learn anything. You click 'add action' and a wizard guides you through making your action. You select the subject, then the verb (or action), and then some parameters. Translated to OO: you select the object, method and parameters.
I considered using a visual programming paradigm, but still text gives you the most freedom in expression. It's also easier to create new concepts in text than making a new image that makes sense.
In the long run I want my Screenplay language to resemble OO, where users can define their own objects with methods. It kind of looks like this (remember it's game related):
Hero walks to Professor
Professor says "Hi there, how are you?"
if Hero chooses "Fine"
Professor says "Nice to hear that."
else if Hero chooses "Not good"
Professor says "I thought so, let me show you something"
Professor walks 2 tiles to the left
Methods could be defined as:
How <actor> says "<text>"
GUI opens text dialog with "<text>" and image 'face image' of <actor>.
I want anyone who can read, but not program, to read such a program and kind of make sense out of it.
I don't think the marketing concept of non-technical programing makes sense. Its like trying to sell atonal arrhythmic music. Or randomization as an interior design strategy. You've already embedded learning in the design where the user has to understand its Subject-Verb not Verb-Subject. Also my experience with OO design is non-technical non-logical people will have truly weird arguments trying to convince you that your objects should be methods and vice versa due to lack of skill at being able to design. By analogy someone who knows how, can always convert a PDA to a CFG, its mathematically proven if you know how you can always do the transform or even write a program (compiler?) to do the transform for you in either direction. But if you don't know how it works or what any of that automata theory jargon means, well, then you just can't, thats it, game over. Likewise your end user can either program at some level, where they can convert culture and emotions and brain waves and other stuff into code, or they can't. And if they can't, well, they just can't.
I'd suggest you market it as a really simple programming language. That'll work. What you've got technically looks good an sounds like it could be useful, so, cool, but you just need to change how you're selling it. Realize that people who can't logically structure and rationally think and technically design will continue to be unable to program, of course, no matter how easy the tool is to use.
Remember most people are functionally illiterate and can't read at a high cognitive level. That probably correlates very strongly with being unable to program BTW.
(edited to add, this was the wisdom of the GUI. Plenty of people are too illiterate and non-technical to ever be able to use languages, including even English prose, as a computer UI. But if you strip out most of the functionality and change it from linguistic IQ skill points to 2-D spatial manipulation, lots more people can "use" that UI... Nobody ever got noobs to use computers via every "simpler" and dumber CLIs, that madness leads to CPM and msdos, the trick was to get lower intellectual functioning people to use computers by taking away power/complexity and abandoning language and literacy entirely by going spatial with GUIs, I'm just saying as a strategy making the tool weaker never helped people who can't use tools as a historical strategy)
Don't forget: computers have no true intelligence, and thus require humans to put things into some form of structure in order for the computer to understand it. The type of structure you can get away with using for simple tasks can often look beautiful, but beyond a certain point, you need to impose distinction and isolation so you can compartmentalize separation of concerns and so forth. This structure is the foundation of programming language design.
The major issue with all of this is that program code is built through a process of iteration: one brick on top of another. But once you hit the wall I just described, you have to face the scientifically organized structure of programming in order for the language itself to not be a mess (see PHP) or the programs written in it to be spaghetti (see BASIC and particularly GOTO).
I say this not to be a downer, just as strong encouragement to take this into account and try your best to factor this into your design. If you can make something that lets people scale really high before hitting that wall (if at all!), that would be awesome.
> You shouldn't need a manual for something simple.
That's like saying "Everyone knows how to drive a car, you just keep it pointing forward and engage the engine".
Everything needs some sort of documentation, whether it be through examples (the way love2d.org/wiki is done, for example, is both informative and useful), documentation, BNF, etc. The fact that a manual exists is not a detriment, but a success -- you have enough features and complexity worthy of documenting it (although I don't mean to imply that larger is bigger :) ).
I worked on a similar problem! (But much, much narrower and less ambitious.) It's designed for games like dating sims. It takes a spec, written mostly as dialogue, and converts it to gamemaker code. I wrote it to help some friends avoid tedious manual translation, which apparently saved them a lot of time.
The problem is that there is still a syntax that's required to know. Look at AppleScript. It uses keywords that sound like easy English but knowing how to use AppleScript still takes a lot of reading.
After reading the article about RUST, I have been thinking about how a compiler could take source code and write it back with fixes/suggestions right into the source so if you make a silly mistake, the compiler can just say "I think you meant..." and offer to fix it for you.
In your language, it would be beneficial to avoid "Syntax error!" and implement something like "Did you mean...", or have synonyms like "says", "exclaims", "talks", etc that compile to the same thing but add flexibility (or the compiler automatically re-writes to the preferred syntax)
This doesn't seem all that different from the various scripts inside RPGMaker or, for that matter, the scripting language that I remember from the custom map makers in Starcraft and Warcraft 3.
To give some background: I'm working on a program to allow anyone to create video games. But to add custom functionality, my users need to use some kind of programming/scripting language. Since these are non-technical people, it must be as easy and simple as possible.
Therefore I'm now making a language (called Screenplay) where you don't really have to learn anything. You click 'add action' and a wizard guides you through making your action. You select the subject, then the verb (or action), and then some parameters. Translated to OO: you select the object, method and parameters.
I considered using a visual programming paradigm, but still text gives you the most freedom in expression. It's also easier to create new concepts in text than making a new image that makes sense.
In the long run I want my Screenplay language to resemble OO, where users can define their own objects with methods. It kind of looks like this (remember it's game related):
Methods could be defined as: I want anyone who can read, but not program, to read such a program and kind of make sense out of it.