Page 1 of 2

to be, or not to be, a programming language

Posted: Mon Jun 22, 2009 10:35 pm
by VolTeK
i was working on a project and a really big question hit me,

what makes a programming language, a programming language?

Re: to be, or not to be, a programming language

Posted: Mon Jun 22, 2009 10:37 pm
by JackScott
Wikipedia (EN) wrote:A programming language is a machine-readable artificial language designed to express computations that can be performed by a machine, particularly a computer. Programming languages can be used to create programs that specify the behavior of a machine, to express algorithms precisely, or as a mode of human communication.
Anything that doesn't fit that definition is not a programming language.

Or do you mean as opposed to a scripting language?

Re: to be, or not to be, a programming language

Posted: Mon Jun 22, 2009 10:39 pm
by Firestryke31
The ability to be translated into the machine code that the computer understands.

I'm sure that a form of English could be made into a computer language if someone were to write a compiler.

Edit: Blarg, too slow. Second part still works, though.

Re: to be, or not to be, a programming language

Posted: Mon Jun 22, 2009 10:40 pm
by VolTeK
well, i was working on macros for the fasm assembler, mainly for development on my operating system, and some people consider a script or include library to be a programming language, how can a bunch of macros be a programming language?


>> well all in all, does it have to be something that does not require fasm? stand alone? <<

Re: to be, or not to be, a programming language

Posted: Mon Jun 22, 2009 11:07 pm
by JackScott
You could have a programming language that compiles the language down into assembly statements. This is basically what GCC does. It takes the language, converts it to a processor-independent intermediate language, then to assembly, than calls GAS to assemble that.

Formally, assembler is a programming language, but is just not considered one in an informal sense. There's no reason why a complicated-enough set of assembler macros could not be considered a programming language. Most people would start making the distinction when the new language requires a new tool (the compiler) to compile the macros and so on, instead of using the assembler's built-in macro processing rules.

Re: to be, or not to be, a programming language

Posted: Mon Jun 22, 2009 11:18 pm
by VolTeK
You could have a programming language that compiles the language down into assembly statements. This is basically what GCC does. It takes the language, converts it to a processor-independent intermediate language, then to assembly, than calls GAS to assemble that.
thats not a bad idea, i might try that, if big problems show up in my os, i might just stick with making a script or just a developers include file of macros
Formally, assembler is a programming language, but is just not considered one in an informal sense. There's no reason why a complicated-enough set of assembler macros could not be considered a programming language. Most people would start making the distinction when the new language requires a new tool (the compiler) to compile the macros and so on, instead of using the assembler's built-in macro processing rules.
i will keep that in mind or keep that as reference just in case i forget (stupid me) or for anyone else who tries to pretend that they have their own programming language :)


anyway though,
Thanks for the responses

Re: to be, or not to be, a programming language

Posted: Tue Jun 23, 2009 1:22 am
by Solar
GhostXoPCorp wrote:well, i was working on macros for the fasm assembler, mainly for development on my operating system, and some people consider a script or include library to be a programming language, how can a bunch of macros be a programming language?
I'd say it becomes a programming language in its own right when the syntax is changed sufficiently. When someone good at assembler would stop felling like "this is Assembler with GhostXoPCorp-o-Macros", and start feeling like "this is hostXoPCorp-o-Language. Funny thing is it doesn't need a compiler on its own, only FASM and this here include library."

Re: to be, or not to be, a programming language

Posted: Tue Jun 23, 2009 10:36 am
by VolTeK
i might just stick with making a script or just a developers include file of macros
i got the point, thanks though :)

Re: to be, or not to be, a programming language

Posted: Tue Jun 23, 2009 10:50 am
by NickJohnson
Maybe you could say it's a dialect of FASM instead of a new language altogether, just like LISP has many dialects that can all be derived from one another using the macro system. I think one of the major criteria for having a new language instead of an extension or dialect is that it is no longer backwards compatible with the original language (C++ is pretty close, but not perfectly backwards compatible with C.)

Re: to be, or not to be, a programming language

Posted: Tue Jun 23, 2009 11:25 am
by Combuster
I think a dialect is the proper term when a programmer who is familiar with a dialect of a language, can easily pick up another dialect of that language and put that to good use.

Which doesn't hold for C vs C++/ObjC/D (thanks to adding object oriented programming)

Re: to be, or not to be, a programming language

Posted: Wed Jun 24, 2009 2:15 am
by Solar
Well, I don't think it's so bad an analogy.

C++ adds quite something to the C language proper (and yes, it changes some things too, but I'll ignore them for the sake of the point). But if you can do C, you can do (the C subset of) C++, too. You don't have to use the things C++ adds, and (almost) everything that was there in C is there in C++, too.

Same for GhostXoPCorp's macro set. It adds to FASM, but everything FASM can do is still there. Anyone who can do FASM can do GhostXoPCorp Macro Language, just without the macros. (No more pointless than doing only the C subset of C++.)

Re: to be, or not to be, a programming language

Posted: Wed Jun 24, 2009 5:08 pm
by Coty
Firestryke31 wrote:I'm sure that a form of English could be made into a computer language if someone were to write a compiler.
then it would be to easy and some of us may not get jobs as easy cuz every one could do it >_<

Lol, think of this,

Code: Select all

move the number 129 into the AX thingy, then
make the value ax ax into some weird thing, then
just clear the screen because I feel like it.
That would be messed up, I could barely help my self keep from righting the Cls in assembly >_<

Re: to be, or not to be, a programming language

Posted: Wed Jun 24, 2009 10:25 pm
by earlz
It could be possible.. The compiler itself would have to learn, and there would still be a "standard library"

Code: Select all

moving memory:
To move memory, copy source memory to target memory. Increment both of those, and repeat until executed as many times as needed.
....
to refresh the screen:
move the memory from video buffer to address 0xb8000 80*25*2 times.
There is a reason an english compiler will never be created though. It would not be useful, as it is extremely verbose, about like an extreme version of COBOL. English is also not precise enough to describe a program without being ambiguous or making assumptions..

Re: to be, or not to be, a programming language

Posted: Wed Jun 24, 2009 10:30 pm
by pcmattman
The problem is that English varies across countries (spelling and use of words, slang, etc...) and is far too ambiguous for use in programming. Tone and context can change the meaning of words, not to mention the fact that there are so many different ways to say the same idea.

The only way to make an English programming language would be to enforce a strict subset of the language. At which point you get something a lot like BASIC ;)

Re: to be, or not to be, a programming language

Posted: Thu Jun 25, 2009 7:59 am
by Solar
You don't have to go all the way to a plain English parser. It doesn't take much to make a script / shell interface more intuitive.

AmigaDOS:

copy src to dest all
Copy ALL from SRC to DEST
COPY TO=dest ALL FROM=src.txt

All three commands to the same. Case insensitive, non-abbreviated both in command and in options, with optional "from" and "to" keywords so there's not only "one true way" of writing the command, and you don't have to remember which way around the parameters need to be put. (From - to is intuitive, but then the whole C standard library has it the other way 'round...)

And if the OS provides such an easy way to parse those options... Using an actual coding example from the Amiga Guru Book, slightly simplified and commented (and please remember that this API predated the first edition of "The C++ Programming Language" by about a year, so don't complain about C-style strings and memory handling):

Code: Select all

int main()
{
    // This will be used to iterate through "from" files vector
    char const * const * p;
    // Handle for handling memory used by function
    struct RDArgs *rda;
    // One array element per template element
    LONG vec[3] = {};
    // Third parameter to ReadArgs() can be a struct RDArgs 
    // holding e.g. additional help text to be displayed on 'copy ?'
    if ( ( rda = ReadArgs( "From/M,To/A,All/S", vec, NULL ) ) != NULL )
    {
        // 'From/M' - 'From' is the keyword, '/M' means "multi",
        // i.e. return type is an array of char pointers.
        // Because 'From/M' was the first element in the template,
        // the pointer to that array is the first element in the return vector.
        // Array of char pointers ends with a NULL element.
        if ( ( p = ( char const * const *)vec[0] ) != NULL )
        {
            for ( ; *p != NULL; ++p )
            {
                printf( "File  = %s\n", *p );
            }
        }
        // 'To/A' - 'To' is the keyword, '/A' means it is compulsory
        // to provide this option. No multi, so return type is a pointer
        // to a C string. Second template entry, second array element.
        printf( "To    = %s\n", (char const *)vec[1] );
        // 'All/S' - 'All' is the keyword, '/S' means it is a switch.
        // Return type is a boolean.
        printf( "All   = %s\n", vec[2] ? "TRUE" : "FALSE" );
        // ReadArgs() had to store the parsed tokens somewhere, so
        // we have to release them.
        FreeArgs( rda );
    }
    else
    {
        printf( "Error while parsing options.\n" );
    }
    return 0;
}