Also, you may have to reevaluate your definition of a scripting language. I will try to guess as to what it could mean to you currently:
A script language is interpreted, a non-script language is compiled
First we have to define interpreted as it could mean many things itself. The most restrained vision of interpreted is a language that would take one line (or enough to form an understandable command), eval() it (which means parsing the line, executing it and changing some internal state) and then proceed to the next one. There's a second case, there are languages that parse the whole content into an tree (precisely an AST) and proceed at evaluating it. A compiled language will have to first parse the code into an AST, then proceed in transforming each node of the tree into a set of smaller instructions, then encoded as bytes. The resulting bytes are called bytecodes and they can be either native or executed on a virtual machine (which translates them to native bytecode). Fewer and fewer languages falls in the first case; PHP3-, older JavaScript, Perl 5 and Ruby 1.8 (MRI) in the second one; PHP4+, Perl 6, Python, Ruby 1.9 (YARV), modern JavaScript, Java, C# in the last one with a VM; C, C++, D, Go and Objective-C in the last one as native code.
A script language has limited tools, a non-script language has a sizable standard library
Take for example (ba)sh: it is really a glue language that controls flow and calls external programs. Those are called shells. As convenience and for performance, shells often include in their own code implementations of previously or current external programs (e.g test, aliased to [) or allow to control or use features specific to the shell. Those are called builtins.
Now you can compare the size of the C/C++ sdtlib and e.g Python, Ruby or Java. The latter ones are an order of magnitude bigger than standard C and C++.
A script language has no external library facilities, a non-script language has third party library facilities
The only thing resembling library features of bash are sourcing an external file and executing external program (which is native enough to extend the language itself since command-calling is first-class in shell languages). On the contrary python has extremely advanced library facilities called modules and packages, which create namespaces that you can selectively import. Ruby is simpler and arguably less advanced as it relies on a 'require' and a 'load' function that will trigger loading and interpretation of a file, while namespacing lies in the hand of the developer who manually nests classes and modules. This is similar to the 'source' feature of bash, but also of the #include preprocessor directive of C, which is not even really part of the compiler and literally stitches the content of a file into another. Usually this #import is done to include so-called header files that describe prototypes of function lying in a library. What's interesting there is that the library feature is actually not even part of the language, but of the infrastructure surrounding the compiler, and precisely the linker. Indeed compiling to native code results in object files which are totally independent of the actual language and totally dependent of ABI calling conventions (which is really unrelated to the language). This way you can link objects having been built from fortran or C, or C++, or whatever. So it turns out C #include is actually closer to bash 'source' in that regard, with the onus of library management being not on the compiler but on the linker.
A script language has no types, a non-script language has types
Bash actually has types, precisely strings and arrays and it's up to each program to parse the strings into somethign meaningful. Now what you may be distinguishing there is weak typing vs strong typing. Let's take PHP, which when given "3"+2 spits 5 (or "5" I can't recall). Try that in C and you will get an error/warning/core dump (ironically '3'+2 in C would give both a warning and '5' because of ASCII and char really being bytes). Yet try that in python and ruby and you will get an error (an exception precisely). PHP is weak-typed and Python, C and Ruby are strong-typed.
Now maybe that's because we're not declaring types and not having function/method signatures that makes it a scripting language. Really what's at play here is static vs dynamic typing. Python and Ruby are dynamically typed, while C is statically typed. But Objective-C is dynamically typed too.
A script language is used to write scripts
Maybe you encountered #!/bin/sh in scripts, and also #!/usr/bin/python and concluded 'Ha! They're scripting languages!'. Amusingly enough, it's quite easy to build a thin wrapper to gcc that will make it possible to start a file with #!/usr/bin/c and subsequently write code in C. Does that make C a scripting language? Maybe, but that makes it equally easy to make any language a scripting language.
A script language is not written in itself, a non-script language is written in itself.
This is called self-hosting. You could argue that C is written in C, while Bash, Python and Ruby are written in C. Well too bad, as D is written in C, C# is written in C and C++, Java is written in C, and even g++, the C++ compiler is written in C. (for each one of course, part of their standard library is written in their own language). At the same time, Python has PyPy which is able to produce native code straight from Python code, and various other languages are self-hosted. Now you could argue that we're using C because of performance, but that's not even true, since PyPy regularly outperforms CPython. In fact we're only often using C because there has been a tremendous amount of work thrown into C compilers (notably regarding conversion of code to each native platform) so it's merely by convenience that we reuse them.
A script language has no memory management, a non-script language is low-level
So, C and C++ have memory management, while Python does not. So much for Java and C#, which would become scripting language by that criteria. Also, as for low-level Python can use things like mmap and has ctypes which allows you to tap into system devices (via e.g /dev) and native functions (which, as mentioned above may or may not have been written in C, since at that point they're just native code respecting a convention allowing them to be called. If anything such code could have been generated by PyPy) like malloc and free, so you can go low-level in Python if you wish.
So I think we have made quite a round-up of things, and hopefully enouch to demonstrate that well, while Python and Ruby are effectively able to be used (and quite efficiently so) to write scripts, they are clearly just not only "scripting languages", but full-blown, extremely advanced and potent programming languages.
Great roundup. Its nice to see all this points. One big difference between scripting and non-scripting languages is that, in scripting languages you can modify the structure of the program at runtime, while in compiled languages you are stuck once you compile it. C++ does have metaprogramming through the use of templates and those programs look immensely complicated, but it can't introduce new data types and logic at runtime. I kinda dislike C++ from beyond templates as the code looks super ugly.
The ability to modify the program at runtime (and elegantly) is a huge advantage over compiled ones and allows you to express new category of solutions.
Programs that change itself is in my opinion pretty advanced.
So it seems, Python and Ruby allows the programmer to free the mind from the low-level housekeeping and focus 100% on logical thinking and give incredible expressiveness. I would buy that.
I wonder how often an above average python/ruby programmer use its metaprogramming / reflection capabitlies?
I once had a professor teaching a course on elegance in software design proclaim "Python is not a real language". The course is taught in Java. I cringed.
I will take your comment at face value and will answer accordingly.
First, here's a direct answer to your question: take a look at [0], and you will se an example use of metaprogramming.
In this file ModelBase is a metaclass, which is used to create new classes at runtime.
[0] https://github.com/django/django/blob/master/django/db/model...
Also, you may have to reevaluate your definition of a scripting language. I will try to guess as to what it could mean to you currently:
First we have to define interpreted as it could mean many things itself. The most restrained vision of interpreted is a language that would take one line (or enough to form an understandable command), eval() it (which means parsing the line, executing it and changing some internal state) and then proceed to the next one. There's a second case, there are languages that parse the whole content into an tree (precisely an AST) and proceed at evaluating it. A compiled language will have to first parse the code into an AST, then proceed in transforming each node of the tree into a set of smaller instructions, then encoded as bytes. The resulting bytes are called bytecodes and they can be either native or executed on a virtual machine (which translates them to native bytecode). Fewer and fewer languages falls in the first case; PHP3-, older JavaScript, Perl 5 and Ruby 1.8 (MRI) in the second one; PHP4+, Perl 6, Python, Ruby 1.9 (YARV), modern JavaScript, Java, C# in the last one with a VM; C, C++, D, Go and Objective-C in the last one as native code. Take for example (ba)sh: it is really a glue language that controls flow and calls external programs. Those are called shells. As convenience and for performance, shells often include in their own code implementations of previously or current external programs (e.g test, aliased to [) or allow to control or use features specific to the shell. Those are called builtins.Now you can compare the size of the C/C++ sdtlib and e.g Python, Ruby or Java. The latter ones are an order of magnitude bigger than standard C and C++.
The only thing resembling library features of bash are sourcing an external file and executing external program (which is native enough to extend the language itself since command-calling is first-class in shell languages). On the contrary python has extremely advanced library facilities called modules and packages, which create namespaces that you can selectively import. Ruby is simpler and arguably less advanced as it relies on a 'require' and a 'load' function that will trigger loading and interpretation of a file, while namespacing lies in the hand of the developer who manually nests classes and modules. This is similar to the 'source' feature of bash, but also of the #include preprocessor directive of C, which is not even really part of the compiler and literally stitches the content of a file into another. Usually this #import is done to include so-called header files that describe prototypes of function lying in a library. What's interesting there is that the library feature is actually not even part of the language, but of the infrastructure surrounding the compiler, and precisely the linker. Indeed compiling to native code results in object files which are totally independent of the actual language and totally dependent of ABI calling conventions (which is really unrelated to the language). This way you can link objects having been built from fortran or C, or C++, or whatever. So it turns out C #include is actually closer to bash 'source' in that regard, with the onus of library management being not on the compiler but on the linker. Bash actually has types, precisely strings and arrays and it's up to each program to parse the strings into somethign meaningful. Now what you may be distinguishing there is weak typing vs strong typing. Let's take PHP, which when given "3"+2 spits 5 (or "5" I can't recall). Try that in C and you will get an error/warning/core dump (ironically '3'+2 in C would give both a warning and '5' because of ASCII and char really being bytes). Yet try that in python and ruby and you will get an error (an exception precisely). PHP is weak-typed and Python, C and Ruby are strong-typed.Now maybe that's because we're not declaring types and not having function/method signatures that makes it a scripting language. Really what's at play here is static vs dynamic typing. Python and Ruby are dynamically typed, while C is statically typed. But Objective-C is dynamically typed too.
Maybe you encountered #!/bin/sh in scripts, and also #!/usr/bin/python and concluded 'Ha! They're scripting languages!'. Amusingly enough, it's quite easy to build a thin wrapper to gcc that will make it possible to start a file with #!/usr/bin/c and subsequently write code in C. Does that make C a scripting language? Maybe, but that makes it equally easy to make any language a scripting language. This is called self-hosting. You could argue that C is written in C, while Bash, Python and Ruby are written in C. Well too bad, as D is written in C, C# is written in C and C++, Java is written in C, and even g++, the C++ compiler is written in C. (for each one of course, part of their standard library is written in their own language). At the same time, Python has PyPy which is able to produce native code straight from Python code, and various other languages are self-hosted. Now you could argue that we're using C because of performance, but that's not even true, since PyPy regularly outperforms CPython. In fact we're only often using C because there has been a tremendous amount of work thrown into C compilers (notably regarding conversion of code to each native platform) so it's merely by convenience that we reuse them. So, C and C++ have memory management, while Python does not. So much for Java and C#, which would become scripting language by that criteria. Also, as for low-level Python can use things like mmap and has ctypes which allows you to tap into system devices (via e.g /dev) and native functions (which, as mentioned above may or may not have been written in C, since at that point they're just native code respecting a convention allowing them to be called. If anything such code could have been generated by PyPy) like malloc and free, so you can go low-level in Python if you wish.So I think we have made quite a round-up of things, and hopefully enouch to demonstrate that well, while Python and Ruby are effectively able to be used (and quite efficiently so) to write scripts, they are clearly just not only "scripting languages", but full-blown, extremely advanced and potent programming languages.