Your Ideal Programming Language
Author
If you could create a programming language, from simply your mind; instantly, what kind of features would it have? If you could simply imagine a programming language and it was automatically created there and then and instantaneously become the standard. No longer forced with working with languages you disliked.
I'm just curious to see what everyone's ideal language would be.
Ideal languages aren't implementable on modern computers.
Also, there's already a discussion on this very page about this.
Also, there's already a discussion on this very page about this.
That link isn't the only thread. There have been hundreds of them over the past many years.
Simple searches for best and ideal languages pulled up over 1500 threads on the subject.
They all boil down to this: In order to determine the ideal language in a situation, you must define 'ideal' for a well defined purpose, operating environment and running constraints, code and program lifetime, and the humans who will develop and maintain it.
Even if there was an "Ideal" perfect language for a given situation, that same language could be absolutely horrible for another situation. For example, the ideal programming language for somebody involved with intense database work and endless queries is going to want something different than those desiring a SIMD parallel language, which will be different still from those desiring n-way parallel asynchronous task management, which will again be different for those working on highly constrained embedded processors.
There are countless programming languages in existence. Creating a programming language is a typical requirement for college curriculum. There are even automated compiler creators, such as YACC ("Yet Another Compiler Compiler"). During my professional career I have had to create several languages for different situations. It is a trivial, somewhat mind-numbing task.
It is typically best to just choose the most readily available common language which you are comfortable with and which most closely meets your needs.
As far as me personally, the preferred language in a given situation may be any of C#, C++, cg, Java, Perl, Python, lua, php, SQL, shell scripts, nant scripts, or possibly a few dozen assembly languages I have picked up over the years, to name a few.
Simple searches for best and ideal languages pulled up over 1500 threads on the subject.
They all boil down to this: In order to determine the ideal language in a situation, you must define 'ideal' for a well defined purpose, operating environment and running constraints, code and program lifetime, and the humans who will develop and maintain it.
Even if there was an "Ideal" perfect language for a given situation, that same language could be absolutely horrible for another situation. For example, the ideal programming language for somebody involved with intense database work and endless queries is going to want something different than those desiring a SIMD parallel language, which will be different still from those desiring n-way parallel asynchronous task management, which will again be different for those working on highly constrained embedded processors.
There are countless programming languages in existence. Creating a programming language is a typical requirement for college curriculum. There are even automated compiler creators, such as YACC ("Yet Another Compiler Compiler"). During my professional career I have had to create several languages for different situations. It is a trivial, somewhat mind-numbing task.
It is typically best to just choose the most readily available common language which you are comfortable with and which most closely meets your needs.
As far as me personally, the preferred language in a given situation may be any of C#, C++, cg, Java, Perl, Python, lua, php, SQL, shell scripts, nant scripts, or possibly a few dozen assembly languages I have picked up over the years, to name a few.
Quote:Original post by frobTrust frob on this - I started a similar thread a year or two back, it went 10 pages and became fairly heated.
They all boil down to this: In order to determine the ideal language in a situation, you must define 'ideal' for a well defined purpose, operating environment and running constraints, code and program lifetime, and the humans who will develop and maintain it.
Quote:As far as me personally, the preferred language in a given situation may be any of C#, C++, cg, Java, Perl, Python, lua, php, SQL, shell scripts, nant scripts, or possibly a few dozen assembly languages I have picked up over the years, to name a few.And the list only grows longer over time: there was a point when I thought that everything should be written in C++, these days I shudder at the very idea of trying to shoehorn every task into a single language.
The ideal is essentialy a language which is focused entirely on managing and calling code written in other languages.
If you don't like that answer, then maybe you asked the wrong question.
If you don't like that answer, then maybe you asked the wrong question.
English like language to express basic logic with a dictionary of synonyms and modules pre programmed for most common fields that are split beetween implementation and expressivity metadata (metadata wich the compiler parse to know how you can call the functionality of the module)
using GameEngine;
Module Monster
{
[default=Name,required=true]
Monster:Entity
{
monster()
{
Life defaults to 10;
}
[Param Name]
string Name;
[Param Life]
int Life;
}
}
caller code:
using BaseLib;
using GameEngine;
using Monster;
Module Game
{
main()
{
run game with Monster Timmy has 12 Health and Monster Teddy;
}
}
In main we call run (defined in GameEngine as a method with a verb attribute) Game (where the run method is located) with (defined in base library to add to a default collection of the preceding item) Monster (instanciates monster class named Timmy wich is the default param) has (keyword to assign to variable of the object in scope , not needed for name wich is the default param) and monster teddy (has life 10 since this is the default).
Since the compiler has a dictionary you will get this warning (warning : ambigous reference "Health not implemented" defaulting to most likely candidate "Life")
using GameEngine;
Module Monster
{
[default=Name,required=true]
Monster:Entity
{
monster()
{
Life defaults to 10;
}
[Param Name]
string Name;
[Param Life]
int Life;
}
}
caller code:
using BaseLib;
using GameEngine;
using Monster;
Module Game
{
main()
{
run game with Monster Timmy has 12 Health and Monster Teddy;
}
}
In main we call run (defined in GameEngine as a method with a verb attribute) Game (where the run method is located) with (defined in base library to add to a default collection of the preceding item) Monster (instanciates monster class named Timmy wich is the default param) has (keyword to assign to variable of the object in scope , not needed for name wich is the default param) and monster teddy (has life 10 since this is the default).
Since the compiler has a dictionary you will get this warning (warning : ambigous reference "Health not implemented" defaulting to most likely candidate "Life")
I can just list the desired feature list of a language I've been working on for the past year:
- Code is stored in data-flow format
- Code is easy to inspect and modify. Lots of facilities for metaprogramming, to help overcome the limitations of data-flow format.
- Support for live debugging. Code can be modified while an app runs.
- Like most data-flow based languages, there is a graphical code editor with lots of boxes and arrows and stuff. However, there's also a text syntax, and text is the primary representation. (I don't like the idea of the visual interface being the only interface).
- Syntax is preserved. I should be able to write some code, run the program, have that code be modified programatically, and then be able to save it back as source code text. The parts I wrote by hand should look exactly the same, and the parts I didn't write should still look OK. Saving to source code can work as a kind of persistence (although, not the most efficient one).
- Has ability to send "feedback". For any expression, I should be able to say what I *want* the result to be, and the runtime will go backwards through the data-flow chain, and figure out what it needs to change to make that happen. The user will specify which values are allowed to change. In situations where the runtime can't figure out how to satisfy feedback, it must let the user know.
- Ability to add arbitrary compile-time invariants to expressions, like "this never goes below 2" or "this pointer is never null". If the runtime can't figure out whether an invariant holds, it can ask the user to write an explicit guard.
- Code is stored in data-flow format
- Code is easy to inspect and modify. Lots of facilities for metaprogramming, to help overcome the limitations of data-flow format.
- Support for live debugging. Code can be modified while an app runs.
- Like most data-flow based languages, there is a graphical code editor with lots of boxes and arrows and stuff. However, there's also a text syntax, and text is the primary representation. (I don't like the idea of the visual interface being the only interface).
- Syntax is preserved. I should be able to write some code, run the program, have that code be modified programatically, and then be able to save it back as source code text. The parts I wrote by hand should look exactly the same, and the parts I didn't write should still look OK. Saving to source code can work as a kind of persistence (although, not the most efficient one).
- Has ability to send "feedback". For any expression, I should be able to say what I *want* the result to be, and the runtime will go backwards through the data-flow chain, and figure out what it needs to change to make that happen. The user will specify which values are allowed to change. In situations where the runtime can't figure out how to satisfy feedback, it must let the user know.
- Ability to add arbitrary compile-time invariants to expressions, like "this never goes below 2" or "this pointer is never null". If the runtime can't figure out whether an invariant holds, it can ask the user to write an explicit guard.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
