0
$\begingroup$

If all programming languages more or less compile down to the same machine code. Have there been attempts at, or is there a "field" around the concept of even more modular programming languages, where it can be built-up based on exactly what is needed? If arrays aren't handled, the language to simplify writing a program that is then compiled into machine code won't need to know what an array is. And, same with loops of different sorts, many languages have both for, and while.

I'm not a computer scientist. As a novice, there are so many different "language", but they're all mostly the same thing, and it seems like there might be a better way to organize the benefits each language gives relative to how much they actually overlap. I just watched Bjarne Stroustrup explain that C++ made managing complex data types easier, and that C should be seen as a subset of C++, but it seems like another way of doing it is to have an even more modular approach, treating the more complex abilities C++ has as modular add-ons, programs that can be imported. Since this is what is being done anyway except in a "one-size-fits-all" way. Basically, to not have a "one-size-fits-all" programming language, but construct what is needed depending on need.

If anyone understands what I'm fishing for, feel free to reply. It also seems such a language would make it easier for noobs to understand "programming languages", even if they could also have the choice to import more one-size-fits-all configuration.

$\endgroup$
2
  • $\begingroup$ Your question is indeed confuse. Imports are the compiler's concern, they don't make the language more complex. Also note that when a program is compiled, it only includes the features that it uses. F.i. if it does not use arrays, there will be no array-related code generated. $\endgroup$
    – user16034
    Jul 26, 2022 at 11:00
  • $\begingroup$ If you want a simple, yet very powerful procedural language, get "A Method of Programming" by Edsger Wybe Dijkstra and W. H. J. Feijen. $\endgroup$
    – user16034
    Jul 26, 2022 at 11:03

5 Answers 5

3
$\begingroup$

The syntactic features of computer languages only exist for the benefit of human understanding; they are abstractions that are helpful for us to conceptualize what is happening in the programs. The programs themselves are agnostic to these syntactic features and the fact that the source language uses them is not necessarily reflected in the final code. The resultant machine code doesn't care whether you used a for-loop or a while-loop; the same CPU operations may be used for both. And what is an array? For us it is a complex data-structure with many rules that we must follow in order to make it work correctly, but in the computer it is just a series of adjacent data.

To be able to add or remove syntactic features on-the-fly would make programming languages much more complex allow for more opportunity for ambiguity. Since the resultant programs aren't really changed by presence of these features, it probably isn't beneficial to have to deal with the extra complexity of allowing syntactic features to be be added or removed.

Some features that are not syntactic do have a big affect on the performance of the resultant programs. For example, the memory allocation and cleanup system used might differ from language-to-language. Some other features include runtime safety checks, like bounds-checks on arrays. A notable feature that has a significant affect on the performance of resultant code is whether the language compiles to native machine code or must be interpreted by another program in order to run.

$\endgroup$
1
$\begingroup$

Yes, there are minimalistic programming languages where many of the things considered "primitives" in other programming languages are built up from even simpler things.

For example, most programming languages have if-then-else, repeat-until, etc. built in.

However, assembly language, as well as a few minimalistic implementations of Forth and Lisp do not have these control structures built-in -- instead, they are built up from simpler (to the machine) primitives.

Yossi Kreinin, in "My history with Forth & stack machines", describes an implementation of Forth that doesn't even have comments built in!

Karl Lunt has a macro package that you can #INCLUDE from another PIC assembly-language file to support FOR-NEXT, SELECT-CASE, REPEAT-UNTIL, REPEAT-ALWAYS, etc. It would be pretty easy to split that up into a bunch of files, each of which implemented only one control structure, and then you could #INCLUDE only the control structures you actually use.

Assembly language even lets you custom-design new calling conventions.

People designing new instruction sets sometimes wonder about what's the minimal set of instructions that's really "necessary" -- how many different primitive instructions are necessary for a minimal instruction set computer that can do all the stuff that any other CPU can do in a "reasonable" number of primitive instructions?

Alas, trying to "simplify" the number of primitive operations to an extreme often leads to a "Turing Tarpit". Making the base language simpler by supporting very few things (so that everything else must be built up from those things) often leads to more complexity elsewhere. (See: "law of conservation of complexity", aka "Waterbed Theory").

$\endgroup$
0
$\begingroup$

Not that I know of. There's no clear value to doing that, that I can see.

Once you have a compiler that can handle all language constructs, there is no need to construct new compilers that handle only a subset of constructs. There is value to programmers of having a single language to learn, rather than many variants. And most large programs are likely to use most language constructs somewhere or other.

There is lots of work on contructing domain-specific languages (DSLs), including using functional languages like Haskell to help with that.

$\endgroup$
0
0
$\begingroup$

The problem with the idea of a modular or a-la-carte programming language (if I understand the question correctly) is that the main challenge of designing programming languages in the first place is integrating a wide variety of features and requirements without undue verbosity or a wild proliferation of syntactical or conceptual complexity.

It's always possible in principle to write everything from scratch in assembly language, but the volume of code that would ensue to express any given operation is itself the problem.

If a language is not already designed to provide a feature, it's very unlikely to be able to provide it without either being verbose or changing what seem to be fundamental principles.

Another thing about languages is that they are most useful when shared, and when shareable and communicable. Highly individual languages may multiply the effort of the designer, but they also require extreme design effort from the sole user. Shared languages have a community who can be engaged in design together, who can study and solve different problems with it, and devise the patterns and idioms for particular applications.

$\endgroup$
0
$\begingroup$

You could argue that something like Swift kind of fits into this category - because the language is actually quite small, but with a massive standard library. Not even +, -, *, / are part of the language - the fact that they are binary or sometimes unary operators, left associative, with certain priorities is defined in the standard library (which is enough for parsing) and their implementation for many types is defined elsewhere in the standard library (so you can add int + int, or float + float). The basic types like integers, floating point, character, are all defined in the standard library.

And there are aspects of the language that allow you to write code that looks as if you had extended the language.

Not that you can do much of anything without pulling in most of the standard library.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.