(Inspired by ProgrammingIsNotFun)

"Restricted programming language" is my term for a language whose designers omit features because they're "too complex" or because some programmers have used them to write bad code.

JavaLanguage is a restricted ProgrammingLanguage. The designers chose to omit OperatorOverloading because they felt that overloading made the compiler and code too complex, and because it's possible for programmers to "abuse" it by, for example, using += to perform a stack push. CeeSharp supports overloaded operators, which will probably make it more popular than Java. (But, to be fair, Java's restrictions aren't ''that bad,'' mainly because Java gives you other features in return, such as garbage collection and generics.)

I once used a restricted language which was only used in-house by a DataProcessing company. The designers purposely left recursion out, because they were worried about programmers accidentally causing InfiniteRecursion''''''s. All variables were global, because LocalVariables which appear and disappear as the program runs were thought to be over the heads of some of those looking at the program. This led to major headaches when writing code. (By contrast, in my style of ForthLanguage programming, all variables are global, and I tend to avoid RECURSE. ''(Sounds like a job for LOCALS| or a similar Forth construct.)'' But at least if I accidentally create a new Forth variable with the same name as an old one, it's created separately, so I can't clobber the old one by mistake. HyperStaticGlobalEnvironment.)

CobolLanguage is probably the ultimate restricted language. I say "probably" because I've been fortunate enough to be able to avoid COBOL.

* Not even close. They didn't intend to leave features out, although by the standards of the 21st century there's a lot missing. But back when it was introduced, it was quite powerful. There were things it was better at than FortranLanguage, which was the primary alternative for many people, if they had any choice at all.

Obviously not every language can have every feature. BjarneStroustrup made the conscious decision to leave serialization out of CeePlusPlus because he was afraid it would incur a space overhead on every object, including objects that didn't use serialization. SchemeLanguage is deliberately confined to a small number of special forms because the designers want to avoid the "bloatedness" of CommonLisp. (Instead, they added a macro facility so you can define your own special forms. See DefineSyntax. ''This sounds like Common Lisp has no such macro facilities, which isn't true.'') ForthLanguage is constrained in various ways so that it can be easy to implement. Nevertheless, these languages are targeted for programmers, and do not deny features to programmers on the ground that programmers, or others looking at the program code, would be too stupid to understand those features. However, this is, I think, the difference between ''restrictions'' and mere ''limitations'': limitations are motivated by the nature of the problems that the language designer is trying to solve; restrictions are set out in advance of designing the language, usually in order to prevent programmers from doing things.

When I get saddled with such a ProgrammingLanguage I often end up doing what looks like GoldPlating: my classical ComputerScience education has caused me to see certain problems in terms of recursion or the use of LocalVariables, and I can't unsee it, so I find myself doing by hand what I think the language implementation ought to have done. I find myself implementing stacks and storing all my values there. I find myself implementing ContinuationPassingStyle. I find myself writing Forth-like code outside of ForthLanguage. In JavaLanguage, I find myself copying and pasting code because there are no templates, and using a class and an interface would incur too much overhead [CopyAndPasteProgramming]. ComplexityHasToGoSomewhere. The code that gets written is very nearly unmaintainable to other people, ''unless'' the maintainer knows or figures out what has been done to produce this contorted code and can follow the process back and forth. Is it too much to hope that some maintainer will have an "AhHa" moment with my old code, that suddenly it will become clear to them, and they will start writing all their code like that? I suppose it would be a suitable revenge.

----
Just to make it clear, it is not a feature of the language or the lack thereof that makes the language "restricted." It's the motivation of the language designers when they chose to include or omit a feature.

A restricted programming language is any language whose designers thought that ''programmers would be too stupid'' to do X, or refrain from doing Y, and that therefore the language should force them to do X and to refrain from doing Y.

----
Some people say that what makes a language high-level is what it allows you to do, e.g., higher-level languages allow you to represent more abstract concepts directly in the code.

Other people say that what makes a language high-level is what it prohibits you from doing, e.g., if a language allows you to use pointers or do bitwise xor or use SSE instructions then it is not high level, no matter what abstractions it supports.

I think the former view is good, while the latter is bad. It is praiseworthy to write a language where one does not ''have'' to use pointers (or bitwise xor). It is not praiseworthy to write a language where one is not ''allowed'' to use them. (The most common reason to use low-level features is to interoperate with code written in low-level languages. For example, CeeSharpLanguage supports "unsafe" code, in part so that, if you cannot use the dot-Net framework to accomplish your goal, you can interoperate with the Windows API, which is a C API.)

I would say that language implementors who are out to deny access to features are creating RestrictedProgrammingLanguage''''''s.

I suppose an exception has to be made for languages where the program may have been written by untrustworthy people on the other end of the Internet. However, even in those cases, it is possible (albeit slow) to support "pointers" which are trapped inside a virtual machine. (Somebody once wrote a virtual machine in Java which can be used to execute C code, inside Java.)
----
I found the ultimate in restricted languages.  Take JavaLanguage and remove primitive types, arrays, the ability to define classes and methods, and then use it for a web templating language by wrapping every statement in CaseSensitive XML [ExtensibleMarkupLanguage] tags.  Some other features (like some equivalent statements crashing, but not the others) are merely bugs, but most of the language is an exercise in trying to make it "easy" and "enterprise-level."

  <ISPECT>String userLang = getUserPreferredLocale(theUser)</ISPECT>
  <ISPECT>if (userLang==null)
    <ISPECT>String userLang = i18n.getDefaultLocale()</ISPECT>
  </ISPECT>
''Egads -- it looks like BasicLanguage is actually better than something else!''

Sorry, you still have a long way to go before you get to the usability level of XsltLanguage.

----
See BondageAndDisciplineLanguage.
----
CategoryProgrammingLanguage