An article was recently published that looks at evaluating First Programming Languages (FPL) the language to use for an introductory course of programming.
An existing issue is that formally assessing a programming language isn't really defined, with a lot of evidence being anecdotal. The proposed evaluation framework looks at technical and environmental feature sets. "The technical feature set covers the language theoretical aspects, whereas, the environmental feature set helps evaluating the external factors." These feature sets are covered in table 2 of the article (link to PDF) and consist of the following:
The article explains each of these points in details, and gives each of the languages being evaluated a rating based on this explanation, followed by a detailed explanation of how the scores of each rating can be compared this includes allowing an evaluator to weigh certain criteria they deem important against the others. As this is for choosing a language to teach someone to program with, different places will have different reasons and goals, so would want to weight things differently.
As the default weight settings do not conform to the original popularity index of the languages, so there should be a different weighting criterion. However, it is very hard to come up with a generic and correct weighting criterion. Therefore, the scoring function should be customizable and the user should be able to tune the weight of each feature based on her preferences. As an example, consider the fact that Ada holds 3rd position in overall scoring, but is not being considered among highly used FPLs as of now.
I learned to program the hard way... First on paper in pseudo-code for an algorithmics class then several years later I picked up an HP-11c calculator and an HP67 desktop calculator attached to a digital height gauge from there I went to IBM PC basic and then IBM Compiled Basic then HP Technical Basic and Borland Pascal with some extended work on talking to peripherals on an IEEE-488 buss card and sending and receiving through a serial port to a punch tape... then later we added other smatterings of that and this... new basic and pascal variants and touches of various "dynamic" languages, TclTK, Lua, Python, Perl. Of these Tcl is the easiest to learn and actually produce running scripts. I also used Euphoria and IBasic [before it imploded]. Both were fairly fast and easy... I've also used a smattering of C, Fortan, Perl, Java... but not enough to be considered a programmer in those languages... the usual amount of use that a General Specialist such as myself uses. So take what follows for what you find it worth...
Java [IMHO] is not on my list of recommended languages. First because it is not a "freely, available language"... Second it is from Oracle... Thirdly did I mention it is from Oracle... It was supposed to be the center of Sun's network computer initiative [the 90s version of mobile]. It did not work out until Google took it and built their own Runtime. The fact that Java has consistent and constant security issues has led me to block it in all of the browsers I use [Chrome and FireFox]. As for C#? C# is the MS answer to Java... No. Just say no again. If it isn't an open standard then you never know when the provider will "pull an Oracle" and want to be paid for your work.
C isn't bad except it has a generally "non-human readable" syntax. I understand the historic reason but just because the back end then was a PDP-10 doesn't mean your code needs to still look like unreadable gobbledygook. C is fast and has a small footprint but maybe not as fast and as small as Forth. [Yes I dabbled with that too... still have a copy of the Forth book around somewhere].
One question is: Why wasn't Lua considered? It is not much different than Python... other than it was not developed in North America or Europe...
As far as I am concerned OO languages are overrated. Originally they were "sold" as the basis of reusable code. Didn't happen. That it was easier to code. It wasn't. That it was better than sliced bread. I've discovered I have gluten intolerance. Yes I know there are those of you who are professional code wrights and will spout your favorite... for a dabbler like me BASIC, Tcl, Pascal suits me.
Oh there are other languages that were not even mentioned for pushing algorithmics... Can you say Logo or Smalltalk derivatives like Squeak. The point here is [in my useless opinion] that it almost seems that programming language designers intentionally make their task more difficult. Programs are for solving problems... not for creating syntax that is not clearly understandable.
My ideal language would have:
1) A syntax something like Pascal,2) Have prepackaged functions for graphics and communication like CA-Realizer which had a slick set of functions which could do Log-Log graphs easily or communications without any sweat or serious amount of coding. As far as I am concerned Tk like windowing makes for faster delivery. OO windowing just seems to add a level of obscurity that isn't needed except by those obsessed with having access to all of the code of their windowing API. Additional complexity in a windowing library is a sign that the designer wasn't really interested in easier programming.3) Was cross platform4) Was native compilable [JIT is not as fast as native] but can run as a dynamic language. [Tcl, Python, Perl, lua do not compile to native... I've often wondered why. If you are going to spen the time to write a run-time environment why not just build a complete cross compiler?]5) Was open source software6) Had a sweet disposition for rapid debugging and development.
I don't think there is currently a language that actually fits that bill. If there was an open source 64 bit CA-Realizer clone for RAD I'd be really happy... but it seems that compiler writers have fallen in love with complexity just because that is the way they think. If the point of programming is to solve problems then why create a language that of itself is problematic [buffer overflows, no boundary checks, explicit security, difficult syntax constructs, as well as countless others].
The point of TFA is "Use Brand X because Larry the O says so". As a counterpoint -- One can also say "3 billion flies can't be wrong, eat manure..." Both are filled with the same "savory" flavor.
Computer languages do not need to be complex to be usable. We have long since passed the point where a compiler does not have sufficient hardware resources to interpret a program in "human readable" code. Why do we continue to write code in non-user-friendly languages? Why do we continue to believe that shaving nanoseconds off execution time on a single processor when hardware has moved on from the heady days of Fortan and C in 10K of core memory.
A general Specialist's Rule of thumb when evaluating a tool for a specific purpose: "If it was ugly going in, it will look worse coming out." A language should be elegant and fluent. It should be easily communicated and understood. Most modern languages are a serious FAIL in this regards... but then again consider the source. ;)
Have a look at Modula 3. It conpiles to machine code, will cross-compile to machine code for another machine, is serious about run-time checks and garbage collection and similar security, and has object-oriented stuff that you don't need to use if you don't want to. It has a syntax like Pascal.
And if the security gets in your way, it you can explicitly declare that you'll use unsafe language features and start pointer-punning and explicit storage allocation and freeing to your heart's content.
It's one of the few languages where, once you get the program through the compiler, it's reasonably likely that the program will actually do something like running.
Oh. And nowadays there's a new code generator for it that compiles to very portable C.
Look it up on the wikipedia and follow links from there.
Don't' confuse it with Modula 2. That's a completely different language.