# Should definitions of future computer languages incorporate IDE technologies?

## Summary:

Should definitions of future computer languages incorporate the basic functions of an IDE?
The definitions of currently popular computer languages assume only the technology of printing. For example, they provide syntax for printed expressions in one location that refer to printed expressions in other locations (e.g. "include" type syntax ). However, they don't assume that such expressions are links to anything, although an integrated development environment (IDE) may be able to make to treat expressions like links.

Writing code in languages like C++ or Java, seems (to me) to involve a lot of "boilerplate" text that is copied and pasted. Copying and pasting takes advantage of modern editing software. If it takes modern editing software to make it practical to code in a language, it also makes sense for the design specifications of future languages to assume more technology that merely the technology of printing. The definition of a future language could assume the basic functions of an IDE exist and define the language in terms of those functions.

Last edited by a moderator:

Related Programming and Computer Science News on Phys.org
PeterDonis
Mentor
2019 Award
The definition of a future language could assume the basic functions of an IDE exist and define the language in terms of those functions.
I think this would be a serious mistake. IMO, a language that needs an IDE for a programmer to be productive in it is a language that has too much boilerplate to begin with.

The way to remove boilerplate from a language is just to remove boilerplate. You don't need an IDE for that. "Hello, world!" in Python is one line: print("Hello, world!"). No IDE required. (Python gives you one with IDLE, but you don't need it to program in Python; I've never used it.)

Mark44
Mentor
You don't need an IDE for that. "Hello, world!" in Python is one line: print("Hello, world!"). No IDE required. (Python gives you one with IDLE, but you don't need it to program in Python; I've never used it.)
Nor have I.

fresh_42
Mentor
You usually have the language first and the IDE on top of it. In reality the distinction is sometimes difficult. MS might insert their own libraries as default for Visual C++, and I know an IDE which has its own commands and syntax, where a C or C++ compiler is beneath.

Mark44
Mentor
You usually have the language first and the IDE on top of it.
Right. The IDE isn't directly related to with the language -- it usually includes an editor, a debugger, and hooks to the compiler and linker, plus whatever other features it has.
In reality the distinction is sometimes difficult. MS might insert their own libraries as default for Visual C++,
In my opinion, the distinction between an IDE and a particular language is pretty clear. The tasks performed by an IDE are mostly unrelated to the particular language, possibly excepting editors that can check syntax.
MS might insert their own libraries as default for Visual C++,
Any C or C++ compiler is going to link in its own libraries, but that's really separate from the IDE. Most compilers are set up so you can run build scripts completely outside of the IDE.

fresh_42
Mentor
In my opinion, the distinction between an IDE and a particular language is pretty clear. The tasks performed by an IDE are mostly unrelated to the particular language, possibly excepting editors that can check syntax.
This depends on the definitions. If an IDE has its own syntax and commands, but generates a C source code on the lower layers to create the executable program, none of which can be seen, is it a new language? Possibly. I still think that the distinction depends on the 'author'.
Any C or C++ compiler is going to link in its own libraries, but that's really separate from the IDE. Most compilers are set up so you can run build scripts completely outside of the IDE.
Right. But do you consider the library as part of the IDE or part of the language? Or neither? Depends on whether you are a purist or not. It is easy to tell at the university, but if you actually have to program software, you might consider the library as part of the IDE, since without you really have a problem. On the other hand, it is a software package which enhances the compiler.

Mark44
Mentor
This depends on the definitions. If an IDE has its own syntax and commands, but generates a C source code on the lower layers to create the executable program, none of which can be seen, is it a new language? Possibly. I still think that the distinction depends on the 'author'.
I've not ever used an IDE that generates C (or C++) source code, and these include products from Borland and Microsoft, and another C compiler and a Fortran compiler whose names I don't remember. A C++ compiler can generate certain functions, like default constructors or destructors, but that's not something the IDE does.

Right. But do you consider the library as part of the IDE or part of the language? Or neither?
Neither. It's essentially just pre-written code that's been compiled into machine code that gets linked into a user-written program. A library adheres to the language, or else it wouldn't compile, but it's not part of the language.

fresh_42
Mentor
I've not ever used an IDE that generates C (or C++) source code, and these include products from Borland and Microsoft, and another C compiler and a Fortran compiler whose names I don't remember. A C++ compiler can generate certain functions, like default constructors or destructors, but that's not something the IDE does.
https://www.windev.com/

I am not sure whether it is a compiler written in C or whether it generates C code beneath the surface (which I assume). In any case the IDE and the language cannot be clearly distinguished.

Last edited:
I think it makes sense to design a language considering the capabilities of an IDE. I suppose that is like what we have already in essence, except maybe without a capital I, as our languages are based on the keyboard, and ascii characters, and so forth. We write programs with text, and there is assumed to be some kind of text editor and interpreter or compiler. That all is essentially a development environment.

Keyboards are pretty archaic and languages we use now are pretty much designed around their limitations. I've commonly wondered why we haven't designed a specialized version of the keyboard for programming specifically, since we could expand the sets of characters/symbols, and even include keys that can generate common compound statements or snippets. If the keyboard itself was different, then we would have designed the languages differently.

In general, we have not really experimented deeply how we might interface with an "editor" or ide, or what form the language of that interface is in. What do we use in a VR or AR environment?

You could build in accessibility translations, like voice to text, but customized and standardized for coding. And print to sound.
Maybe it could build in debugging functionalities, like adding breakpoints in the language itself.

Beyond the basic interface, you can include a standardized metalanguage to interact with the ide. Well this kind of exists, in C or C++ for example, people can use #pragma to interact with the IDE or preprocessor and compiler (e.g. to disable warnings for some code block, or compile the block of code in some special way), or interact with the preprocessor in other ways using macros, template meta programming, etc.

Boiler plate code can be dealt with by copying and pasting, but also by abstraction, modularity and the DRY principle. Languages already have built in capabilities to do that. These things often are so custom and the range of possibilities are so vast that it's perhaps sometimes better to do these things programmatically.

Sublime text as an example, is programmatically customizable so that you can design your own snippets, tab completion logic, trigger arbitrary preprocessing, etc. But I never like using snippets because they usually leave too many fill in the blanks, which interrupt the flow.

Another thing we have is regular expressions, which are useful in an IDE for find and replace etc. In some ide's you can also process the text with built in refactoring tools for smarter text replacement etc.

In general, we want to better manage complexity. The issue is that complexity is not a unitary thing. On the one hand you have something like Shannon entropy, how verbose the code needs to be, and on the other hand you have complexity in terms of the simplicity of organization and parameterization. And there is a tradeoff ; you make a simple but verbose and low level language and you don't need a long instruction manual (i.e. C, which doesn't takes long to learn) or you have complex features exposing more generalization and organizational complexity and you need a long instruction manual (i.e. C++, especially metaprogramming, and "concepts", which takes a long time and thousands of page of information to fully understand. So there is a Pareto optimization to do here when designing a language so that complexity is manageable and the code is understandable and maintainable.

The development environment is definitely a part of complexity management, so it makes sense to at least consider it when making these tradeoffs. For example, Java with Eclipse has the hotkey to show documentation feature, and I guess you can expect that all of the Java libraries have documentation. And there is some kind of standardization to the way it's documented so that users can easily navigate the documentation on demand. This is enormously helpful for ameliorating the burden of second kind of complexity (long instruction manual). You also have similar features in other IDEs and somewhat standard tools like doxygen. These are examples of embedded metalanguages that talk to the IDE I guess.

In general, it's these higher order IDE features which tend to make those higher level more abstracted and generic language features more usable.

I mentioned the DRY principle. Which means don't repeat yourself. E.g. try to eliminate redundancy and unnecessary verbosity. This is achieved through higher level features, for example with generics. But the issue is you commonly will have many slightly different versions if the same thing. So generalizing in programming language constructs can be complex (lots of degrees of freedoms for an abstract object, long instruction manual). But IDEs can he capable of detecting code reusability and exposing those degrees of freedom interactively in an easier way. Or different ways of doing it manually, through abstraction layers embedded in an ide could be possible. So I imagine new possibilities for dealing with DRYness if the language and the IDE talk to eachother.

Multilevel languages, using DSLs at different layers, are also possible (e.g. like html css and javascript), except where some layer handles talking with the IDE specifically.

Last edited:
You usually have the language first and the IDE on top of it.
Yes, however:

The title for the OP has been edited by a moderator to suggest the question concerns the current state of affairs. However, as the summary indicates, the topic of the OP is whether future languages should be designed only assuming the technology of printing - or should they be designed assuming more advanced technology, such as that provided by IDEs.

fresh_42
Mentor
Yes, however:

The title for the OP has been edited by a moderator to suggest the question concerns the current state of affairs. However, as the summary indicates, the topic of the OP is whether future languages should be designed only assuming the technology of printing - or should they be designed assuming more advanced technology, such as that provided by IDEs.
This was my fault, since the original sentence with 'have' instead of 'do' wasn't a sentence, and the word future did not occur. Feel free to give me a clear alternative for the title and I will change it.

berkeman
berkeman
Mentor
Yes, however:

The title for the OP has been edited by a moderator to suggest the question concerns the current state of affairs. However, as the summary indicates, the topic of the OP is whether future languages should be designed only assuming the technology of printing - or should they be designed assuming more advanced technology, such as that provided by IDEs.
Apologies. I was not able to parse your original title 'Have computer language definitions dependent on an IDE?' so I tried to fix it up. As fresh says, we can help to fix your title so it says what you intended and is grammatically correct.

Mark44
Mentor
I am not sure whether it is a compiler written in C or whether it generates C code beneath the surface (which I assume). In any case the IDE and the language cannot be clearly distinguished.
Looking at the link you gave, WinDev doesn't generate C code -- their WLanguage seems to be a combination of Visual Basic and SQL. The compiler is probably written in C#, based on mention of .NET assemblies in the PDF of the link.

WinDev seems to be something of a database manager, which in the context of programming languages is off in its own niche, separate from more general programming languages like C, C++, C#, Java, Fortran, and others. For these languages, there is a clear distinction between the language and whatever IDE happens to be in use with them.

fresh_42
Mentor
Looking at the link you gave, WinDev doesn't generate C code -- their WLanguage seems to be a combination of Visual Basic and SQL. The compiler is probably written in C#, based on mention of .NET assemblies in the PDF of the link.

WinDev seems to be something of a database manager, which in the context of programming languages is off in its own niche, separate from more general programming languages like C, C++, C#, Java, Fortran, and others. For these languages, there is a clear distinction between the language and whatever IDE happens to be in use with them.
It started as a DB manager, but it is more. It is an IDE which allows you to build frontend and backend features at the same time. They have a test IDE for free. I think it is a perfect example of what the OP meant in post #10. If it were only a language, one could produce code in a simple text editor, change the extension and feed the compiler. This is not possible. If it was a pure IDE, then you should be able to use another one, which is also impossible. Hence it is a product where the criteria for distinction do not apply anymore. It is an all in one package, and the compiled code is created somewhere in the lower layers without having access to.

Here is an easy example:
Code:
EDT_text="Hello World!"
Wait(200,waitTimer)
EDT_text=""
This code is attached via the frontend design in the IDE to a click button. It inserts "Hello World!" into a text field for two seconds and empties the field again.

It is impossible to edit the code without the IDE, i.e. the location where the trigger for execution is defined, and the output is an exe file. And it is impossible to compile the code outside the IDE. So where does the compiler end and the IDE begins? I think the only distinction which can be made is, whether this is a proprietary software product, or whether it already matches what the OP had in mind.

Last edited:
I was not able to parse your original title 'Have computer language definitions dependent on an IDE?'
I found it difficult to condense my thought into a short title, so I wrote "Have...." instead of the slightly clearer "Should we have....".

A better title is "Should definitions of future computer languages incorporate IDE technologies?"

fresh_42
Mentor
I found it difficult to condense my thought into a short title, so I wrote "Have...." instead of the slightly clearer "Should we have....".

A better title is "Should definitions of future computer languages incorporate IDE technologies?"
"Should future computer languages incorporate IDE technologies?" Definition of is already confusing. And "should" versus "will" is another problematic wording. Should for whom and why?

Definition vs incorporation is an important distinction. Current computer languages define syntax for features that tell the linker or interpreter that processing a given document of computer code requires referencing other documents (e.g. "#include", and "import" type statements).

How much the definition of a language enforces a given behavior on linkers and interpreters varies from language to language. For example, how linkers search for related files can be configured in various ways - and the use of "symbolic links" in file systems offers more versatility and confusion.

I'd say the computer languages incorporate issues related to file systems if we count a particular linker or interpreter as part of the language, but I would not say that the definition of a (current) computer language completely specifies the behavior of a linker or interpreter.

Mark44
Mentor
Definition vs incorporation is an important distinction. Current computer languages define syntax for features that tell the linker or interpreter that processing a given document of computer code requires referencing other documents (e.g. "#include", and "import" type statements).
"Translator" is a better choice than "interpreter," as the latter implies languages such as Python or others that translate and run one line at a time.
Processing #include files (in C or C++ programs) is not handled by the compiler per se. Instead, #include files and other preprocessor directives are handled by a separate component of the compiler called the preprocessor.
Import statements would be handled by a linker, not the translator.
How much the definition of a language enforces a given behavior on linkers and interpreters varies from language to language. For example, how linkers search for related files can be configured in various ways - and the use of "symbolic links" in file systems offers more versatility and confusion.
I don't believe how a language is defined has any relation to how a translator (compiler or interpreter) or linker work, other than the very minor detail of where to look for #include files or libraries that are imported. This is pretty much unrelated to how the language is defined.

I'm not sure what you're talking about with your mention of symbolic links. The compiler sets up a symbol table that lists the names and memory locations or offsets within memory. The linker (AKA link editor) uses the symbol table to "fix up" the references in the code to items in the symbol table for identifiers such as printf or other library functions.
I'd say the computer languages incorporate issues related to file systems if we count a particular linker or interpreter as part of the language,
But we don't count these tools as part of the language any more than we would count a profiler of spell checker as part of the language.
Stephen Tashi said:
but I would not say that the definition of a (current) computer language completely specifies the behavior of a linker or interpreter.
Right. And I would add that the linker isn't involved at all. Of course, the compiler has to be built with "understanding" of the particular language, but the linker just brings in library code to the right places and carries out some other housekeeping details for the type of binary that is being built; i.e., an executable (.exe), a static library (.lib), or a dynamic library (.dll).

In terms of Linux, the command "ln -s"

Mark44
Mentor
In terms of Linux, the command "ln -s"
But this has nothing to do with compilers and linkers. This is an operating system command. What does this have to do with programming languages?

But this has nothing to do with compilers and linkers. This is an operating system command. What does this have to do with programming languages?
Compilers and linkers try to navigate file systems. Anything that affects the structure of file systems can affect them.

Mark44
Mentor
Compilers and linkers try to navigate file systems. Anything that affects the structure of file systems can affect them.
But so what? I still don't see how any of that is relevant to the programming language itself.

I'm not sure what is the definition of definition in this context. A language has a syntax, a grammar, and semantics. I'm not sure if it makes sense to consider an IDE in these categories.

But there may also be a standard, which I think is more broad. I think the OP's ideas are more relevant to this aspect of the language.

The standard includes constraints that the vender, which implements the language, need to adhere to in order to meet the standard. In general, these constraints and required features make it possible for the language to be cross platform. If a person writes standard code, then their code should work correctly no matter which standard conforming implementation is used.

In general, the standard may have something to say about different parts of the toolchain, including a preprocessor, compiler, or linker. Sometimes there are even third party standards on top of the main standard, such as OpenMP, which most vendors may also try to comply with.

I think it's reasonable (depending on context) for a standard (the standard or a third party standard) to make rules and constraints that IDEs need to conform to. I can understand why many coders wouldn't like the sound of it, but I can imagine some arguments to be made about how consistency across IDEs could be useful.

fresh_42
pbuk
Gold Member
I can think of a few examples where IDEs have been built around existing languages that have then developed such that they could be considered as an inseparable whole:
• Delphi (previously Turbo Pascal, now disappeared*) - Pascal
• C# - C
• Android SDK - Java/Kotlin
• Cocoa - Objective C/Swift

The last two provide interesting examples where Android SDK/Cocoa started out based on existing languages (Java/Objective C) and then new languages were developed specifically for these platforms (Kotlin/Swift). This is perhaps closest to what the OP had in mind, however in each case these frameworks/SDKs (software development kits) go beyond simple IDEs and are tied to particular hardware and GUI implementations.

I wonder @Stephen Tashi what "basic functions of an IDE" do you think would be useful to include in the specification of a computer language?

* Edit - I didn't realise Delphi is still around, see https://www.embarcadero.com/products

Last edited:
fresh_42
Mentor
I don't see the difference between "definitions of future computer languages incorporate IDE technologies" and what is simply a proprietary all-in-one system.

jim mcnamara and pbuk