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.
Aren't all the tech features listed good in "a language" and simultaneously bad in "a first language"?
Doesn't need to be high level because the programming tasks are not going to be high level. You'll be implementing the concept of a loop, recursion, the idea of GIGO and input sanitization... no need for high level there.
Doesn't need to be orthogonal, after all you're going to be stuck with non-orthogonal languages in the real world occasionally, and no better time to learn than with a professor rather than google. And see above, noob is going to be solving real complicated problems like "implement a bubble sort" or "use an array" so having some limits is, in itself educational.
Can't enforce good habits WRT LISP macros or OO polymorphism if you're still trying to figure out hello_world.cpp. So irrelevant. Not irrelevant in industry, but irrelevant in training. And encouraging the learner to trip over themseleves in a mid-semester sized project is an Excellent learning experience. If you get them to crash and burn in about 3 pages, thats awesome for education. You want to fail early to build good habits for good inherent reasons, not raise them to go all cargo cult on what may be good habits or may just be a fad and they won't understand the difference.
Security. Uh, what, you're having CS101 students implement your SSL library or babbys first AES implementation? That is just so wrong on so many levels. Nothing from that class should ever be on the internet in any form. Again, another awesome feature for a vocational training language or an on the job language, but probably awful for CS curriculum. Even for vocational training, how exactly do you explain the features required to prevent buffer overflow / stack smashing to a bunch of noobs who don't know what a stack is or why they'd want one or what an buffer is for that matter? Just going to confuse them. And looking at it the other way, go Socratic on them and let them build buffer overflow victims and teach them how not to. Again, experience and rational thinking troubleshooting always beats cargo cult tradition. A good educational language should be easy to write vulnerable code and just a little harder to do it right.
Don't let your language get in the way of your learning. But don't use baby talk language all your life either. Don't be the "All I was trained on was hammers; but don't work so gud on deck screws." guy.
I agree more or less with everything, except may be the "level". It depends on how we define "low-level", of course, but I am used to think of it as dressed-up Assembly: impossible to interpret, memory micro-management, and complete absence of non-functional paradigms. As much as I adore C, I don't think it would be a great FPL even for CS majors, and a pretty terrible choice for everyone else. At least a CS major will learn something about the way a computer actually computes, but everyone else will probably just shake their head in disgust.
There's an old saying about you can write Fortran in any language. Now a days they probably say PHP. But the point is something like assembly would make someone who refuses to learn functions subroutines modularization unit testing libraries include files, crash and burn real fast, which is awesome for learning. Better to crash and burn at three pages in school than thirty on the job.
I was thinking low level as in a noob who may never take a data structures class might get thru a 101 intro class better without a long discussion of call-by-value vs call-by-reference. Or a noob who might never take a data structure class because thats just not how he rolls, doesn't need a language that can do more than ints/floats. Or no idea what a lambda is, no need for language features like macros or ability to create domain specific languages. If you're working on "what is a flow chart" or "what is the basic concept of procedural programming" then a language with polymorphism is unnecessary.
Security. Uh, what, you're having CS101 students implement your SSL library or babbys first AES implementation? That is just so wrong on so many levels.
That's not what they meant by security in this context. It was defined in the paper:
"In order to evaluate a language for its strength in security we propose the following parameters: i) language should avoid dangling references; ii) there should not be any memory leakage; (iii) control over array index out of bound; (iv) pointers arithmetic; (v) prevent stack and heap overflows. "
The idea being that not having to teach memory allocation and clean up means they can focus on the actual programming bits (and learn memory allocation with another language later on if required).