My GF learned to code in 3 months. This is what she came up with.

Not her's, but the parent comment.

Wasn't trying to be pedantic, just giving feedback. In fact I totally respect the relativity of the scale, I would just say if it was for a job interview you'd want to maybe do as you said and adjust on a larger scale.

My point was 2 months in JS != 40% knowledge of JS. If that came across as pedantic, I apologize.

Actually, I think knowing the history and theory behind a language (as appropriate) is very helpful.

Particularly, if you're using a language like Haskell or Ocaml, it helps to have at least a vague idea of what a functor actually is and where the idea comes from. (I actually only realized that functors were actually similar ideas in both languages a couple days back.)

On the other hand, if you're using a language like JavaScript, understanding the history (especially the languages that influenced it) makes understanding some of the "quirks" much simpler. When you see the influence of Scheme, the scoping suddenly makes much more sense, for example.

So, over all, I think understanding the background of a language really helps for complete mastery.

Be that as it may, what most would call a "fluent" English speaker likely only has a high level working knowledge of the actual English language

Managing memory and using low-level system functions is only advanced when the problem at hand requires it. Otherwise its yak-shaving. It would be like digging a pool with a spoon because you're too bad-ass for shovels.

You've been downvoted a decent amount, and I can see why, but I believe it is unfair because it's only due to your perspective.

At one job I ended up having a lot of work writing language bindings from C to what is commonly considered a "scripting language" (TCL), so it's easy to have to deal with memory management and low level systems knowledge in relation to a scripting language (knowing the semantics of memory management within a language drastically changes how you have to write the bindings). However, the idea is to rate your skill with that particular language. No matter what the most advanced state is of a language, a 5/5 (or whatever the scale is) means that you can accomplish the most advanced task possible in the language. That doesn't mean that someone who is, say, 5/5 in Perl, will have the same skillset and capabilities as someone who is a 5/5 in AT&T syntax assembler. However, there are a list of base assumptions of skills they do have that may align with what we need as a developer when looking at resumes.

How about PyPy? It's a Python JIT compiler written in Python.

There are thousands of other examples. Managing memory and low level system is not the difficult part, it's just tedious - algorithms and mapping a problem correctly is the difficult part.

Read Higher Order Perl, think it's usable for Python & Ruby as well..

(available as a free pdf now)

http://hop.perl.plover.com/book/

Edit:

Here's the TOC:

    1) Recursion and callbacks
    2) Dispatch tables
    3) Caching and memoization
    4) Iterators
    5) From recursion to iterators
    6) Infinite streams
    7) Higher-order functions and currying
    8) Parsing
    9) Declarative programming

> Can you give me an example of writing really really advanced code in Ruby or Python ?

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:

    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.

People downvoting: this guy is admitting to his ignorance and actively and constructively asking to be challenged on it. I don't think that's the kind of comment we want to downvote here, even if the tone makes you bristle.

"Guido van Rossum".

Since the scale is only 1-5, saying that only a few people in the world qualify as a 5 or even 4 wastes 20% or even 40% of the expressiveness of the scale, which makes it pretty useless. It's better to round in the other direction, and think of the scale as logarithmic. If most people in the world won't have any ratings in the 4-5 range, that makes it pretty useless for comparing your own proficiency in the languages you do know, which is the entire point of the exercise, not comparing yourself to the people who designed the language. The interesting thing she's trying to express is how much better she knows JavaScript than Ruby, not how good she is compared to Brendan Eich or Matz.

That sounds pretty interesting. Do you happen to have the full list of code-word's available?