Lambda the Ultimate

I guess I'd be remiss if I didn't point out that the subject of the first PL has come up a number of times on LtU. Unfortunately, I can't seem to locate most of the discussions - the discussion on the HtDP text is the best place to start. And CS 61A from Brian Harvey is a nice intro course that should serve as a comparison.

The purpose of this essay is to contemplate what is the best introductory programming language to teach for beginning programmers, or for them to teach themselves.

Perl makes little sense in answer to the first question, though it can be fine for the second. In a classroom setting, a structured approach is necessary. In a basement setting, a PL which can give positive feedback and a sense of empowerment is more important.

My path to programming was what you describe precisely. I started out teaching myself perl from the camel book until I was fairly comfortable and confident in my ability to make the computer do something. I worked for a year in my spare time on what for me was a really big project, though was actually just a simple web content management system. At a certain point, I felt I wasn't really getting any better at coding, just writing more code so I sought out more formal information. I eventually found SICP and the associated video lectures online. I probably learned more from that book than the previous 2 years of coding in perl.

In my mind the self-taught progammer really needs some combination of a well supported (in both the library and available books sense) language and a separate more formal language to fully understand the subject. I'm not convinced perl is the best choice for the former, because although it has great libraries and a number of really good beginner oriented books, it didn't really make sense to me until I started learning about unix.

The main problem with scheme as an only language for a self-directed course, is that you won't grow until you hit something big enough that it exposes the flaws in your process. It's very easy to get a web hosting package that includes perl or php support or get involved with that sort of development. I think it's much harder to find an opportunity to use scheme in a beginners' context.

I think setting matters a lot, though. In the Visual Effects industry, the best first language seems to be python at the moment since a number of high end software packages such as Maya and Houdini, along with a slew of not so large packages are all embedding python into their interface. That combines an immediate context to use the language with an instant feed back loop in which to practice. Of course ten years ago I guess I would have been saying the same thing about TCL...

Having taught an introductory computer science course using Scheme for the past three years, I have to agree with what Chris said above. Some of the comments in Shlomi's essay hold for MIT Scheme and SICP but not for PLT Scheme and HtDP. Personally, I would refuse to teach an introductory course using Perl on human rights grounds, but to each their own -- I hope we are entering an era where many different approaches can flourish. --PR

I couldn't have said it better myself. I've taught out of SICP for the past six years, and while it does have its issues, I think the meta-approach of teaching Scheme as a way of understanding the big ideas of programming is far better in the long run than teaching a language with the view that this will be the main language you'll use to program in for a long time to come (not that the author of the article said that in so many words, but the implication is there). At Caltech we follow this up with a course teaching a number of languages (C, C++, Java, Ocaml, Haskell, Python, pick any one you want) where the students can put their knowledge into practice. It seems to work well. Having said that, I would be happier if there was more practical programming done in Scheme, which is an unjustly underrated language. Essentially all of the criticisms of Scheme in the original article don't apply to the DrScheme/MzScheme environment.

It's been said of PL/I that there was a great little language in there somewhere, and probably several of them. The same has been said of Ada, and is largely true of Perl.

People who come to Perl from C often program it like C, while Lisp people treat it as a Lisp dialect and people from other backgrounds do likewise. If it can be used to emulate all those styles, then it could be used to teach all of those styles if wielded carefully.

There are certainly drawbacks to Perl as a first language. I'm just not sure the size of the language is one of them.

One could easily teach a subset of Perl. If someone learned the parts of Perl with the prettiest syntax and the features most commonly supported in other languages, it wouldn't have to be so daunting. People teaching Lisp usually don't jump right into CLOS, for example. I certainly wasn't taught the Turbo Vision libraries at first in Pascal or the parallelism and exception handling at first in Ada.

The positives of a subset of Perl are that one could teach a completely procedural class with it, a completely functional class with it, or a completely OO class with it. The styles are not enforced in Perl, which for an introductory class could be a drawback. However, the ability to teach multiple styles one after another in the same language could be a boon.

Perl also has a huge repository of useful libraries which is freely available, easily searched, and easily installed. The advantages of getting programs running with the help of existing code is one thing which should be taught fairly early.

Perl is Perl. One problem with teaching circumscribed languages is that the students then find them lacking in power and tend to extend them in mutually incompatible ways instead of learning new languages. Perl is powerful, and is defined by a freely available open source implementation.

Perl has an established community. It's not good form to ask others to do one's homework and is frowned upon by the community. People are often willing to help, though. Not every language has a place where the authors of the manuals and of the language itself congregate and answer questions from beginners and old hands alike. Perl has several, and that's an advantage for the student.

Perl has several learning books, a language reference book, best practices manual, an OO title, an algorithms title, and a couple of advanced topics books, books on specific domains in the language, and more. All of the typical support literature used to teach a language from novice to expert are available.

There's a lot to be said for using Perl as a teaching language. Perhaps a first language, and perhaps not. Of course, as with any tool designed more for power than safety, there are serious drawbacks to consider. This is particularly true for the novice. However, the use of chisels, saws, rifles, lawnmowers, sledgehammers, knives, and stove tops are often taught very early in their respective disciplines. Bodily injury and death are certainly more important to avoid than programming errors in a batch payroll application for a fictional widget company (one of my first assignments).

I don't believe that having lots of syntax available means that someone cannot be taught a subset of that syntax. No early elementary school student I know speaks or reads in the type of English we are using here. However, they learn the language more as they use it. Mastery of vocabulary and grammar outside one's daily usage is not expected of a small child or of an adult just learning a foreign language. Likewise, if a programming language has a subset which can be used to write useful programs, there's nothing wrong with teaching that first and moving on to more ways to say things later.

My knock is not against Perl as either a first or nth PL. Mostly I just don't think it a good choice for a PL for an introductory course in Comp Sci (though the quality of the first course hinges much more on the quality of the teacher rather than the particular PL used). I don't think of Java, C# or C/C++ as appropriate first languages either - though they are the PL of choice in many a CS department.

No matter which language you use, either you're going to use a subset (like Scheme) or the language is going to be minimal in specification (like Pascal). So, yes, theoretically you could start with a kernel in Perl for the language and then append new constructs onto it as needed when advancing through the curricula. Not knowing Perl well enough, I don't know how successful one could be in chopping it up in manner that represents a logical progression of computation models.

If we restrict ourselves to defining a PL for a first course in Comp Sci, one has to ask what message (concepts) one is trying to convey. Although there are wealth of materials available for learning Perl, I'm not sure that the material is intended as an introductory course to computer science. Material intended to teach a language is much different than material intended to teach a whole field of study.

Material intended to teach a language is much different than material intended to teach a whole field of study.

This is perhaps the best statement of why to choose one language over another I have seen. As it happens, it's not about the language at all, but about the text.

There are a handful of programs using Perl as an introductory language. I did not attend one. While Perl itself may not be as suitable as Scheme as a first language, I have no doubt that it is more suitable than the Basic which I was first taught. It may be more suitable than Ada, which is the initial language encountered where I started college.

To quote Zvi Lamm*, an ideological choice is made when:

(1) It is vital to act.
(2) There is more than one way to act.
(3) It is impossible to decide rationally or empirically between the options.
(4) One must therefore choose between the possible courses of action without having all the data needed for decision.

(from Ideologies and Educational Thought, used without permission)

It is impossible for the novice programmer himself to decide rationally or empirically due to lack of data which language would be best to learn first. The instructor or institution must therefore weigh the costs and benefits. However, each person who has experience with multiple languages already has opinions of them. I know of no metric for measuring the progress of students under disparate initial languages comparatively.

I also know of little research into the results of differing orders of presenting concepts in Computer Science or even "just" programming. If these measurements existed, we may find that the most important concepts for a student to understand are not necessarily the best to present first. False models are often usefully replaced by more accurate models in many fields. Likewise, it may turn out that a language which is less regular in syntax is actually easier to digest for a beginner. Context, after all, is very important in natural languages.

Perhaps at this point, the quality of the material and the talent of the instructor are the most important factors? Of course, the talent of the instructor in a classroom style of education is always a large part of a successful program. Perhaps, though, the material is more important than the language used in the course?

Would it be acceptable to use pretty much any language which supports a concept to teach it, if the instructor and the supporting materials present it properly? Or is there something special about the syntax of Scheme (or Pascal, Ada, Modula, Python, Lisp, Haskell, IO...) which makes it genuinely easier to teach or easier to learn?

The types of languages with which one feels most comfortable are in large part determined by the path followed to programming. Let's not kid ourselves here. Most people do not take on a major in Computer Science to become Computer Scientists. They take it to become software developers. Is it so bad to question whether different ends are best served by the same means? If a linguist is interested in computational linguistics, there's a very real possibility that certain theory will come in handy while much else will be largely be little used. If a social scientist wants to develop software to track statistics, the math and indeed the performance needed are much less than a real-time control for a vehicle.

Should an introductory class, which is what most will take for a minor or as an elective, actually be so much about Computer Science as about good development of software? Teaching a student to express thoughts clearly (in code and documentation), to reuse code when it is advantageous, to think through code logically, how to find proper algorithms, and to debug a program may be far more important early topics than recursion, data structures, and how to implement or design new algorithms.

If the goal is to instruct students the bounds of good style, a language which supports only an elegant style of representation may not be ideal. If the goal is to teach someone to use the power of a language when it is available, using a verbose tautological language may be actively contrary to that goal. If the goal is to get students to think about the possibility of alternative implementations, then a completely orthogonal language is surely contrary to the goal.

An electrical engineer will likely believe that an "elegant" language is one written entirely with NAND instructions. A mathematician will likely look for mathematical representation and functional purity. A logician may look at internal consistency, boolean control structures, and orthogonality as the most important traits of a language. A linguist will likely look at the mnemonics of the operators, keywords, and standard library calls before anything else. Many a deadline-driven programmer will tell you that conciseness of code, visual differentiation of syntax which serves different purposes, strong debugging support in the implementation, a large standard library, and good access to additional libraries are the keys to his success. An accountant likely cares as much about the guaranteed precision of numeric representations as anything else.

Considering the differing constituency of the students and their influences, perhaps languages which suit those other than professors of CS are the best introductory languages.

If the text is really more important than the specific language, then perhaps all of this is moot.

(* I initially credited Ehud for this quote. It turns out it's something I read in one of his father's papers. Sorry for my confusion. )

In the spirit of Characterizing people as non-linear, first-order components in software development, all this is moot.

Although it talks methodology, it's very similar to my thoughts and feelings on language selection. It's not the language that matters as much as the people: how they communicate, what concepts are most comfortable to them, and how they can express what they understand about a situation in code will determine their own best language.

Perhaps, then, a language that fits how the professors think is at odds with how the students think? Is the difficulty in teaching new students the fact that students don't "get" what the professors are teaching, or that the professors need to think more like the students?

It should be easier for the professors, who are now well versed in the field but once were not, to relate to the students than vice versa.

Perhaps, then, a language that fits how the professors think is at odds with how the students think? Is the difficulty in teaching new students the fact that students don't "get" what the professors are teaching, or that the professors need to think more like the students?

Which is ironic, since the ultimate goal is to teach the students to think more like the professors. :-)

The ultimate goal of the program as a whole would definitely teach the students to think like the professors.

It may be that the introduction is a good place to reach the students on common ground, and then expand their thinking towards that of the professors. This is in contrast to trying to make a clean break from what's come before their introductory courses, and setting up a framework for thought separate from anything many of the students have known.

I'm not sure of which is better, but I don't think anyone else is really certain either. I'm not sure there's even an existing language that would successfully do all of these things:

1. allow a layperson (which is what an absolute novice student is) to learn to program more easily
2. still be suitable for teaching the concepts the professors feel need to be taught
3. do so without actively encouraging poor habits of thought and programming

It may be very helpful for such a thing to exist.

Those features are pretty much exactly what underlies the choice of Scheme for books like HtDP. You might be interested to read this TeachScheme, ReachJava! page from the TeachScheme project. It addresses a number of the issues that have been raised in this thread.

teach the students to think like the professors

No disrespect to any professors here but professors only exist to teach students, so your argument assumes the circular justification of academia that ignores the rest of the world.

Given that most students leave academia to work in industry, perhaps the ultimate goal should use a different measure of success e.g. to teach students how to write useful programs? Note that professors rarely have any experience of writing programs that are used by the rest of society.

Cheers,
Jon.

...professors only exist to teach students...

Professors nominally exist to "advance the state of human knowledge", with teaching being a secondary responsibility (it's handy to have those with advanced knowledge pass it on). Granted, some professors seem to focus more on publication counts and making themselves seem important than on either actually advancing human knowledge, or on teaching students. But that's a separate issue.

Given that most students leave academia to work in industry, perhaps the ultimate goal should use a different measure of success...

That raises yet another issue, which is the unfortunate trend towards using CS programmes to train software engineers. Computer science and software engineering are different disciplines, with fundamentally different motivations and goals. David Parnas did a far better job than I could articulating the differences in his paper "Software Engineering Programmes Are Not Computer Science Programmes", so I won't bother repeating his arguments here.

Professors nominally exist to "advance the state of human knowledge",

No. Researchers (both in industry and in academia) exist to advance knowledge. In most of the world, teaching is a core part of being a professor.

Either way, most of the world's best code does not come from professors (it may come from researchers). So the word "professor" has no place that definition.

Cheers,
Jon.

I think you are using the word "Professor" with diffrent meanings.

Acording to wikipedia:

"The meaning of the word professor .. varies. In most English-speaking countries, it refers to a senior academic who holds a departmental chair, generally as head of the department, or a personal chair awarded specifically to that individual. In some countries like in the United States, Canada and India, individuals often use the term professor as a polite form of address for any teacher, lecturer, or researcher employed by a college or university, regardless of rank. In some countries, e.g. Austria, Romania, Serbia and Italy, the term also applies to high school teachers. (See differences and main systems below for more information.)"

I know that at least in sweden, the title of professor involves something like 70% reaserch and 30% teaching.

70/30 sounds about right for US Universities as well, in my experience. Some professors teach more than others, but if they have the money for buyouts, they can teach as little as one or two courses per year. And research impact is, while not the only factor, certainly more important than teaching skills in determining tenure.

Note that professors only exist in teaching institutions and that most research is done in industry and not in academia.

Cheers,
Jon.

I don't know whether to laugh or cry...

The background research for HtDP is about as close as you're likely to get to a methodical treatment of the subject.

About the only thing I can personally add is that based on translating bits of SICP into a bunch of other languages, I can say without a doubt that the text as it was written would not have been written with the same emphasis, examples, or sequence if they had chosen any other language than Scheme. Which is just my way of saying that the Text is the most important thing outside of the teacher - but that text is very much influenced by the foundation of the PL used.

Zvi Lamm is my father.

Perl has libraries for Tk, OpenGL, SDL, wxWidgets, curses, Glade, Gnome, gtk, gtk2, Qt, and Etk for example. These are all graphics, menu, or otherwise UI libraries other than "boring ascii files".

Perl also has libraries for ImageMagick, GD, and rrdtool support. It has libraries for SVG support.

Perl is used for log monitoring and CGI programs, yes. It's also used for bioinformatics, network server software, virus scanning, artificial intelligence, automation, database front-ends, audio, games, e-commerce, network administration, tying together other languages, and tying together software written in other languages. It's a fully working general-purpose language with lots of freely redistributable libraries which are easy to find.

Perl may have its demons. People don't like the syntax. They think there's too much syntax. They think the syntax is too sloppy. The Perl community takes some some small liberties with CS vocabulary in a few areas. It's easy to use Perl to shoot yourself in the foot, or to strangle yourself with spaghetti code. The partly compiled, partly interpreted mode of operation can get confusing. The interpreter is a mess of updated implementation and is difficult to modify.

Please, pick any three of the above to complain about. But please, please, please do not bash languages based on false representations of them.

How about not insulting languages at all?

LtU is not for insults (nor language advocacy).

I am aware that Perl, Javascript, and certain other languages draw the ire of the academic computing crowd for reasons I'm not sure I understand. Lack of elegance or even "general ickiness" may be reasons to dislike or advise against a tool. They are not reasons to make false assertions about them in an effort to discredit their usefulness.

There are obvious drawbacks to a language like Perl, and the trade-offs have often been considered by those using the language. However, I would expect that on LtU the true drawbacks of a language are enough to recommend against it if one is planning to do so.

Perhaps "insult" was a strong word, but that's what was happening. I don't feel I have the authority as a relative outsider on LtU to say "stop that, that's not policy". I believe anyone in such a forum, though, can spot an outright untruth and point it out.

maybe your examples are better reasons for not using perl at all but the context here is an introductory language let me present a random pick of the libraries you mention and look at what you need to do to install them

http://search.cpan.org/dist/Wx/docs/INSTALL.pod#wxPerl_installation

http://gtk2-perl.sourceforge.net/win32/

http://www.melax.com/perl/getit.html

Also I was not that serious. I read pieces of the article of the original poster and I did not take it to serious so that explains my mood when i was reacting.

I accidentally replied to the main post just a minute ago. It was meant to be here. I'll summarize by saying that the language, and not the ease of installation of its runtime and libraries, should be the primary focus.

I disagree. I started learning programming when I was 8 ... do you think I knew the answer "why do I want to write software?"? Of course not, it was just learning for the sake of the fun of learning. The reasons for writing software change, as you grow and mature. The goal of learning a first language is to learn fundamental concepts about programming and be equipped to easily learn new languages, or specialize as needed. Besides, not everyone who learns programming will even end up writing software.

I can relate, but I had also agreed with Paul's sentiment, that, "What do you hope to achieve by your effort?" is a frequently unasked question that can really matter. In your case, if you didn't have a strong motivation to limit what might work for you, you might have enjoyed better results. Goals can be strong blinders to perception, but this goes without notice much of the time.

Folks like you who enjoy learning for the sake of learning might be somewhat rare. Perhaps a more raw and unbiased curiosity streak correlates with high intelligence. A joy in finding out how things work doesn't appeal to everyone (more's the pity). And folks who have it can easily overlook pragmatic goals in others to get a specific unstated but expected payoff.

My own sons are 12 and 15, but I haven't started teaching them to program because I can't think of any good reason to give them why they should, and they need one, despite the fact they're both top percentile in math. If I could demonstrate a relation between coding and the video games they play (which I can't) that would be enough for them. But they simply lack raw curiosity in seeing what happens in text displays, since they've been spoiled by high feedback graphic environments.

Within my mental simulation (imagining a process of selling them on programming), all plausible avenues I consider end in their boredom and disinterest after 20 minutes or so, following by increasing resistance to give me attention later for more tries. (I'm already well familiar with a pattern of avoidance associated with attempting to instil an interest in something that bores them.) I actually seem to be doing best lately by not explaining what I'm doing, since the mystery of that gibberish I'm writing has a little intrigue.

They both want to affect the world in a way that would matter beyond learning an abstract new skill. Here's the motivation I think would work for them: if they could make a thing they enjoyed, and could show a friend and not be ridiculed for pursuing lame triviality, then they might see a purpose in it. The bar of avoiding ridicule from their jaded peers is a rather severe one. If it's not amazing eye candy, and it's just some low impact technical feat, then it had better at least be something no random joe can do just as easily. Just having a blog for example wouldn't do it.

I've been thinking my best bet is making it possible for them to program a server in some way, so they can show friends they've altered the way a system behaves that their friends can also use. If it was feasible for them to be makers, and not just users, then this might give them a path to follow suiting their reward oriented focus. [cf]

Perhaps setup a framework so that they could set up some Internet-borne social program. Say a chatroom, online bulletin board (as in analogy to the physical thing, not BBS) or forum for their friends. I don't know your sons well enough to know what exactly you'd need to add, to make that value-added. Maybe something like a website where they and their friends could upload text and pictures, add comments on each others content etc. An assumption in this line of thought is that having their own exclusive system would appeal to them, otherwise they'd probably respond with, "I can just do that with MySpace."

In general, one way you may want to approach this is to build a basic system and show them how they could extend it. Using the above example, let's say you made a system that would allow users to be made and have them post text. Then demonstrate adding the ability to post pictures (probably a requisite for it to be interesting to them). Then suggest ideas like adding the ability to add comments, or maybe inline music/video, emoticon support, skinning, various features other such systems support, anything you might be interested in. Make sure you only suggest a few of these at any time, and make sure you always add in "or anything you guys would like."

Just some ideas, that you may or may not have thought of.

I did think about all those things, and some others. But in my response here I'll try to get back to the issue that caused me to reply, so I can stay on topic. I was trying to say something about programming languages, and learning them, and goals for application, and the way everyone projects their own goals on others without question. The question of how to inspire my sons to learn programming is more an illustrative problem I see pertaining to the chicken and egg problem of motive and learning. But I appreciate the desire to be helpful with suggestions.

Derek Elkins: Perhaps setup a framework so that they could set up some Internet-borne social program.

Yes to "framework" but no to "social program" since I see the influence of their peers as a drawback to be tolerated and not an end to be cultivated by amplifying the means they have at hand to replace phones and tools like MySpace when they get to them. (It makes me flinch just to think of what I'd have to do to keep a social site from having things appear that would get me and them in trouble.) I wouldn't mind if they wanted a social site, if motivation made them push harder to get through technical stuff they see as just means -- but there's no reason to make it easy.

A week ago I told my older son it was hard to choose the right level to present them with tech info. As an example analogy, I told him I might aim to teach him to build a computer. At one end, I could try to teach him every little suffocating detail about hardware, and of course no substantial headway would occur in reasonable time. Or I could have him call someone on the phone and say "build me a computer with these parts", which would result in a computer being built quickly, but without him having learned anything about doing it himself.

The trick in a framework would be getting the level so he was the creator rather than user at all the levels that explain what causes a system to do something. If his part was mostly "asking to have things done" in some pre-defined slots, this would make him a passive user, which I see as not educational.

So I'd like him to see (eg) content that appears in socket traffic, because seeing all inputs and outputs -- and writing the code that responds to this -- gives the overview I think is essential to making and completely understanding the part that makes the active decisions. But then there's a big jump from that low level to one high level enough to be interesting as a result they can control. It would be best to develop the framework with them, using a language that kept them away from unnecessary detail. But I'd have to present some initial thing as a fait accompli for them to extend, as a starting example they liked but was not too complex to understand.

I've been thinking about semantics of a language plus system that would make it easier to write i/o processing systems at a high level, and it influences what I'd try. Please forgive my not saying anything about it though. I try not to broadcast ideas I have in public anymore, since it doesn't help me get things done, and it increases risk of inspiring others to erect IP roadblocks where I'm going.

(Actually, I've been thinking it's convenient to have code that's incomprehensible to others, so that after it's released, it's that much harder for folks to point at bits and claim any parts relate to IP of others -- eg, if you could see the code was good for solving problems in a domain where there were patents. So I say, good luck figuring that out.)

I need to sum this up (and on the topic I cited in the first paragraph). I think what you want to do with programming skill should influence a language you choose to learn first, since if you learn a language and still can't do your application, then you've been had somehow. So if I want my sons to program, I should teach them a language to do something they want done, where the two go hand in hand. I just don't have the combination of application and language lined up yet. Current applications they might like have tools involving too much stuff for beginners. I wish others already had server projects for rank beginners so I could refactor them to be simpler still.

Is a better question, "What kind of software do you want to write?"?

Perhaps it is, "Which language makes the faculty most efficient at turning these 5,000 freshmen into 4,000 sophomores, and eventually 2,500 graduates, in the CS department?".

"Which language is going to help the majority of students learn the future material most effectively?"?

"Which language gets us into the topic at hand most conveniently?" is a good one, too.

"Which language will raise our placement rate with employers high enough that we can recruit new freshmen more easily?" may be a valid question.

I'm not sure which of these questions is the most important. Surely, for the individual student, it is about their goals.

The faculty have their owns goals, including a numbers game of graduating a certain percentage of students with a certain minimum understanding of the field.

The commercial development employers of course want the students trained in whatever language they already use. This is sometimes even in spite of radical gains of efficiency in new development that could be gained by splitting maintenance and new projects into different languages.

There is probably no right answer to all of these questions. If there were, we'd all be using the same language.

Absolutely awesome. This is exactly the kind of thing I was talking about.

Cheers,
Jon.

Folks who appreciate Processing would probably also appreciate Breve.

You don't seem to have any major insights into this topic. That's OK, neither do I; but you don't see me writing "papers" about it and submitting links to them to blogs left and right.

I haven't even read the essay, but my first reaction to the post was similar to this. Essentially, my first thoughts were, "Who are you that I should care about your 'insights' and 'conclusions'?" This is not to say you shouldn't write about your thoughts and publish them or that they aren't valuable, but unless your name has "street cred" in the community you are presenting them to, you should use a less authoritative approach. Instead of clauses like, "explains why they are right or wrong", something like "reasons I think some are better than others" would be more appropriate. Alternatively, as opposed to "street cred", if you had some objective reason to think your results were authoritative, e.g. a study, then that information should be included as well.

To me it's not even "street cred" that's at stake here. First off, calling something a "paper" connotes a set of scholarly standards that the page he links doesn't even remotely meet.

Second, comparing two or more things fairly requires a degree of understanding of the things being compared that the author clearly lacks. For example, he doesn't show any evidence of knowing Scheme very well. More importantly, he doesn't show any evidence of understanding what the problems are that people who teach programming to beginners face. He's just yet another programmer who's stating his opinion about what language(s) he'd like others to learn.

Can we please stop the ad hominem discussion and get back to programming languages issues (if there is anything new to say on the subject of introductory courses, which I doubt).

Thanks.

I was talking only about how the LtU post was presented; this does not require me reading the "paper", reading the "paper" is completely irrelevant. Furthermore, implicit in what I was saying is that the presentation turned me off from even wanting to read the "paper" (you can call that arrogant if you like.*) Finally, as I said absolutely nothing about teaching, I don't see how I could underestimate it or overestimate what I know about it.

* Now I have read most of it and at least skimmed all of it, and had my perception completely validated. I see absolutely no reason why I "should have read the 'paper'" as I did not address it at all.

http://xkcd.com/c202.html

the extensive use of higher-order functions to abstract away usage patterns (e.g. map, fold, filter) that either can't practically be done in the alternatives you consider, or is just in fact not common practice.(The only language in your list that comes close to that is Ruby, which goes a pretty far way, but still falls short.)

I can tell that some of your objections to e.g. perl are very superficial. Map and filter (aka grep) are extremely common in perl code. Reduce less so, but it's still there. Perl Essentially Resembles Lisp.

Scheme can stand on its own merits, there's no reason to pretend that other languages, even lowly 'scripting' languages, are incapable of HOF.

Scheme can stand on its own merits, there's no reason to pretend that other languages, even lowly 'scripting' languages, are incapable of HOF.

Perl's HOF support is good, afaik, but Python and Ruby are still quite challenged in that department. Python has fixed many of the bugs it historically had with closures, but it still restricts the contents of anonymous functions, and Ruby has a lexical scope problem. Also, none of them support tail recursion, which is why they always focus on the shallow applications of HOFs, such as map and filter (as long as map and filter themselves are not implemented recursively).

Also, none of them support tail recursion

sub foo {
    if ($_[0] < 1e7) {
        @_ = ($_[0] + 1);
        goto &bar;
    }
    $_[0]
}

sub bar {
    if ($_[0] < 1e7) {
        @_ = ($_[0] + 1);
        goto &foo;
    }
    $_[0]
}

Looking at it the other way this could be reason why younger programers are better at working with abstractions, than older ones.

I know I'm about to start fighting a losing battle in this forum [...]

I so disappointed to see people write "The 'It Should Have a Decent IDE' Fallacy"

The quote about the decent IDE fallacy is from an article on someone else's site, and that article has come in for some valid criticism here. Your losing battle lies elsewhere. Search LtU for discussion of e.g. DrScheme if you want to see some perspectives of LtU members on IDEs and graphical tools for beginning (and other) users.

In addition to the OP's essay, various comments above (e.g. by Chris Rathman) indicate to me that many people are content with a slightly-better-than-emacs IDE. DrScheme is nice, but it is a world away from the integrated technical computing environments with typesetting and visualization that I was referring to.

Cheers,
Jon.

What Chris wrote and what the original article said are two different things, so quoting one and responding to the other is confusing.

An "integrated technical computing environment with typesetting and visualization" sounds like a wonderful thing, but it doesn't seem to have much bearing on the choice of the best introductory programming language right now. Teaching programming to students right now requires that they learn to create and deal with programs in their traditional symbolic form, so I agree with Chris that an "interpretive environment that allows experimentation" is a priority. That's not an argument against IDEs or other kinds of environment, it's a statement of relative importance in the teaching of programming.

I couldn't disagree more. Having an integrated technical computing environment with typesetting and visualization should be the single most important factor in choosing an introductory programming language right now.

Demanding an "interpretive environment that allows experimentation", while valid, is wildly out of date. It predates GUIs. You might as well demand a QWERTY keyboard. It reaks of monochromatic teletype interaction with a mainframe. Typing with one finger because you have to hold a clipboard whilst awkwardly straightening crazily large glasses.

Why not sex up the teaching a little bit and use something from the 21st century?

Learning Scheme in a REPL is an awful experience compared to learning Mathematica in a notebook.

Cheers,
Jon.

Having an integrated technical computing environment with typesetting and visualization should be the single most important factor in choosing an introductory programming language right now.

So which such environment(s) & language(s) are you recommending? F# with Visual Studio, perhaps? Earlier you wrote "my dream is to provide an integrated environment that makes visualization as easy as possible". I'm not arguing with your dream. The point is that until such an environment is actually available to students, it's moot as a choice factor for an introductory programming language.

Learning Scheme in a REPL is an awful experience compared to learning Mathematica in a notebook.

If the goal is to teach a more general-purpose language than Mathematica, that doesn't help.

Mathematica, Matlab, R, S-Plus, Maple, MathCAD, MuPad... All awesome compared to the state-of-the-art in the FPL world. All vastly better suited to beginners.

For some values of "introductory language", those may be suitable. But if the goal is to teach beginners to program using a general-purpose programming language, starting with one of those environments may be counterproductive. You'd also need to compare their use to that of the various environments that have been designed for teaching programming.

But this is all just underscoring that the appropriate choice depends greatly on what the student is trying to learn, or what the teacher is trying to teach.

But for what definition of "general purpose"?

How can first-class graphics be "counterproductive"?

I agree that "it depends" but doesn't Mathematica provide strictly more than Scheme, for example?

Cheers,
Jon.

Personally, I consider Mathematica to be an application that happens to have an embedded programming language that can be used to extend, restrict, and automate that environment. Being Turing complete, the theory would say that anything that can expressed in any other PL can be programmed. I'm not sure I'd want to use it to write web applications - though I'm sure some enterprising individual has probably done something along those lines at some point in time (on a dare if nothing else).

There is a gray area between computer users and computer programmers. Take calculators - most people just punch in the numbers and the calculator does it magic. Well, in the beginning, much of programming involved little more than number crunching like trajectories. But programming is different than being an end-user. A programmer automates things to make things possible and easier so that others can use the process to accomplish things (the fact that the end user and the programmer may be one and the same person is irrelevant).

At the top of the food chain are those that program for other programmers - programs that help others write programs - also known as programming languages. I find that the further you get up this abstraction pyramid, the less useful visual tools are in the process (still useful for conveying ideas, but not so useful in the actual process to construct processes - i.e. the formal algoritms). For example, it would probably be infeasible to have written the Mathematica package in the PL used in Mathematica (IIRC, they used C).

Ok, so not everyone has the talents of Wolfram - that goes without saying. And there are many more users of Mathematica than were involved in the construction of Mathematica itself. Which is just another way to say that not everyone needs to be writing things from scratch - need a ray-tracer, why study or write one - many already exist. But then that begs the question of why one would use ray-tracers for teaching O'Caml to scientists - very few will make a paycheck writing them from scratch. Most will simply acquire a software package to accomplish their task.

Of course, one could apply the same logic to the material in SICP. Not many people are going to need to write a square root function or a picture language. Indeed, if the code has already been written (which by coincidence is true of most examples that you'll find in an beginner text), then you'll not likely be writing code that does the exact same thing in most professions. So the idea must be to learn a way of thinking - the solution to 2 plus 2 has been known for a long time - but it's still useful knowledge to acquire for those that use numbers.

Parsing, data structures, evaluation, et al are all important concepts for those that seek to automate things for others. They are fundamental building blocks to programming in any language - including Mathematica, R, etc....

Mathematica... I'm not sure I'd want to use it to write web applications

Mathematica targetted people writing web applications by providing Mathematica applets (example). So Mathematica is actually fine for writing web applets, unlike many FPLs...

that begs the question of why one would use ray-tracers for teaching O'Caml to scientists

A ray tracer is the ideal example program to teach OCaml to scientists because:

• it is beautiful
• it is a numerical algorithm
• it showcases OCaml's features

Like several other people here, I used to naively believe that people bought books and did courses for the technical content. Then I started trying to sell this stuff. Few people bought it. My family went hungry. That focused my mind. I was forced to learn how to sell stuff and the number one lesson from industry is "sex sells". It doesn't matter if you're trying to sell technical content to technical people, the fact is nobody will care about your work unless you make it interesting, unless you make it captivating, unless you use typesetting, tables, charts, diagrams and even real-time interactive 3D visualization.

Teaching people programming is my business and, were I not good at it, my business would go under. That is in stark contrast with jo-academic here who can discuss GADTs until they go blue in the face because, at the end of the day, there is almost no correspondance between the effectiveness with which they convey information and the grant funding they receive.

Don't get me wrong. Two years ago I was jo-academic. I had never sold a thing. I thought "hey, I'll be a consultant and teach people functional programming using plain-text languages". Boy was I wrong. Teaching is not about the information you present, it is about getting that information into the student's brain as efficiently as possible. And that needs graphics.

Cheers,
Jon.

Mathematica targetted people writing web applications by providing Mathematica applets (example). So Mathematica is actually fine for writing web applets, unlike many FPLs...

ray tracer is the ideal example program to teach OCaml to scientists

I was forced to learn how to sell stuff and the number one lesson from industry is "sex sells".

It doesn't matter if you're trying to sell technical content to technical people, the fact is nobody will care about your work unless you make it interesting, unless you make it captivating, unless you use typesetting, tables, charts, diagrams and even real-time interactive 3D visualization.

Teaching people programming is my business and, were I not good at it, my business would go under.

That is in stark contrast with jo-academic here who can discuss GADTs until they go blue in the face because...

Don't get me wrong. Two years ago I was jo-academic. I had never sold a thing. I thought "hey, I'll be a consultant and teach people functional programming using plain-text languages". Boy was I wrong. Teaching is not about the information you present, it is about getting that information into the student's brain as efficiently as possible. And that needs graphics.

So do you think Java by virtue of having wider (sex) appeal to the mass of students serves as a good PL for the purposes of an introductory computer science course? Sure we could come up with lots of valid reasons why any other language (Mathematica, Scheme, F#) are better than Java, but if we take the argument at prima facie value, the winner should be the one that the target market finds the most attractive. Of course, if we apply such criteria to comp sci, the next thing you know is that the English Department will decide that in order to appeal to incoming students, Harry Potter will be used instead of Shakespeare.

How would it compare to a web framework say like Ruby on Rails or any number of Java web frameworks?

I have absolutely no idea (not having used either) but I'd like to know.

Personally I don't think web apps are appropriate for a first course.

Depends what the course is on. Not being able to compile a program written in language X into a standalone executable used to be a strong argument against using or teaching language X. Soon, most GUIs will be web based instead of stand-alone and many PLs will follow.

But then the supposition is whether the majority of programmers will ever actually write ray tracers for a living?

None, of course. If you calculate the derivative of x^3-x-1 on a calculus course, how many of the students will go on to do that for a living? Is it bad to differentiate cubics in an example?

The problem with using sex and money in an analogy is that it brings up many images - prostitution and pornography on the more prurient end.

Ok. Interesting. The words sex and money do not have those connertations for me. Hmm.

Anyway, if you don't make your work interesting or seemingly-relevant, nobody will notice it.

Well, programming is my business, and if I were not good at learning...

Asymmetric. I must also program and learn. An academic need not worry about sales, marketing, revenue, profit margins etc.

That is in stark contrast with jo-academic here...

Not particularly good tact in these parts - such things are against the spirit and guidelines which seek to discourage such overgeneralizations.

My point is certainly not an overgeneralization. Academia provides a vastly more stable livelihood than a small business. There are enormous fundamental differences between the two. I am not saying that one is better. I am saying that it is best to take both into account, to learn from both.

Personallly I'd counter a "sex sales" quip with an "but ideas change the world". In the specific case of GADTs, it is a hard problem that is trying to be cracked...

Absolutely. I am not saying that we should not think about GADTs whilst having sex. I'm saying: if you don't make your meme's attractive, they'll never reproduce.

So do you think Java by virtue of having wider (sex) appeal to the mass of students serves as a good PL for the purposes of an introductory computer science course?

Yes, I do. I think we can do better. I think I can make F# into something better. But Java is fine for now.

If we take the argument at prima facie value, the winner should be the one that the target market finds the most attractive.

No, you should choose the one that is most effective at teaching.

Of course, if we apply such criteria to comp sci, the next thing you know is that the English Department will decide that in order to appeal to incoming students, Harry Potter will be used instead of Shakespeare.

From my point of view, this is like choosing between monochrome and color. William grew up on black and white and is happy without color. Phillipa believes that color is only for mathematicians. I believe everyone can benefit from the widespread adoption of color and, once I've spray painted the place, I'm going to shout about how I did it and sell cans of paint. Body painting is probably the nearest I'll get to sex.

Cheers,
Jon.

The problem with using sex and money in an analogy is that it brings up many images - prostitution and pornography on the more prurient end.

Ok. Interesting. The words sex and money do not have those connertations for me. Hmm.

You seem to be missing a rather obvious connection. Prostitution = sex for money; Pornography = sexually explicit media, often exchanged for money.

This brings up the question, why bother with something as boring as a CAS like Mathematica, or mathematical & scientific graphics? Shouldn't programming be taught using, say, a scriptable version of a game like Grand Theft Auto, so that students can work with (virtual) sex and money directly in their exercises and projects?

Anyway, if you don't make your work interesting or seemingly-relevant, nobody will notice it.

The "seemingly" qualifier is refreshingly honest, and reminds me of another recent LtU forum post. But wouldn't it be better to make the work actually relevant, and sell that fact?

Heh. That reminds me of an idea I had a while back. My friend Dennis had come up with a goofy Doom based process management tool. It mapped your processes to monsters in Doom, where shooting them would renice the the corresponding process and killing one would kill the corresponding process. It was fun to get the monsters to attack each other and watch the processes on your machine randomly shut down.

Anyway, I started wondering about Doom based computation and mapping circuits to dungeons and inputs to monsters and see if a universal Doom gate could be built. But then I went out for pizza and never really though about it again.

It mapped your processes to monsters in Doom

Everyone that I know of loved that idea. Us having heard about it betrays the fact that it is a sexy idea. Not practicable, perhaps, but certainly food for thought.

Cheers,
Jon.

This doesn't half get political, no? I've used sexual analogies to "sell" ideas in computing before, but generally there's been slightly more commonality involved than just "hey, I can make a smutty pun here!".

In fact, I think I can break them down into two groups:

1) Describing some kind of pleasurable interaction or working relationship. That'd be the running theme of the article I wrote for The Monad.Reader about type-level hackery.

2) Dealing with the perverse! I don't think you can really get to be a good hacker without a sense for it - pushing the boundaries of what can be done often requires a taste for doing things that really aren't "supposed" to do that.

But that kind of thing isn't really what's meant in "sex sells" normally - it'd be a far more pleasant concept otherwise.

You seem to be missing a rather obvious connection. Prostitution = sex for money; Pornography = sexually explicit media, often exchanged for money

I got the connection but I personally don't think of prostitutes when I hear sex or pornography when I hear money. For me, there is a stronger connection to love, family and marriage. Apparently this makes me some kind of wierd curiosity on LtU, like an albino nubian.

This brings up the question, why bother with something as boring as a CAS like Mathematica, or mathematical & scientific graphics? Shouldn't programming be taught using, say, a scriptable version of a game like Grand Theft Auto, so that students can work with (virtual) sex and money directly in their exercises and projects?

We can certainly learn from the success of that games series because it is very popular among the student population. That doesn't mean we should get students implementing electronic prostitutes though.

But wouldn't it be better to make the work actually relevant, and sell that fact?

Exactly. You said "sell", and that means "make it appear relevant" and "tell people about it". You must sell ideas because their relevance is not likely to be obvious.

I spent half of my PhD improving wavelet-based time-frequency analysis. Then I commercialized it as a product. The product did not sell. Why?

Precisely because I had then the view then that you guys have now (no, not the one about prostitutes, the other one). I thought that my great idea would sell itself, after all it is obviously relevant for many people.

That is completely wrong. Not only do most people doing signal analysis not know about the entire subject area of time-frequency analysis, they do not appreciate the benefits of wavelets or the importance and relevance of the uncertainty principle.

My idea was relevant, but to sell it I must make it seem relevant. And those are two very different things.

Cheers,
Jon.

Misattributing beliefs is enough of a no-no here when you spell the person in question's name correctly!

Now, if you want to go into details? I don't think typesetting is a big deal until it comes to presentation time, and what typeset haskell code I've read certainly hasn't been how I'd want code display on screen while it's being edited - it's nice to have, but mostly I want it by way of code-to-TeX convertors. Do I have uses for visualisation tools? Sure, but I don't need them in my IDE and I also want full-blown GUI tools so that I can build visual editors quickly. What I largely don't care about are graphing tools - if someone wants to write the lib that's fine, but if your visualisation centres around graphs I don't care about your product.

So I want some of what you're talking about, but not in the form you propose and not modelled on a tool that's still primarily *aimed* at mathematicians - my working tradition is different, and some of that's for a reason (notation!). My ideal working environment for now looks suspiciously like a REPL for a sufficiently reflective language with a GUI lib attached, and one of these days I'll get round to spending some serious time with something in the Smalltalk tradition as a result.

Some of what I'm asking for here is significantly more powerful than just graphics, perhaps that might be food for thought?

Misattributing beliefs is enough of a no-no here when you spell the person in question's name correctly!

I cannot apologise enough. You may call me "John".

I don't think typesetting is a big deal until it comes to presentation time,

When you are secretly coding in your bedroom on some shameful project, do you inline everything and not indent properly, deferring those tasks until someone looks at the code?

Perhaps I am unusual, but I obsess about appearance, even in my bedroom.

and what typeset haskell code I've read certainly hasn't been how I'd want code display on screen while it's being edited - it's nice to have, but mostly I want it by way of code-to-TeX convertors.

Do you like color syntax highlighting and automatic code indentation?

Do I have uses for visualisation tools? Sure, but I don't need them in my IDE

Strictly, I want to see them in the stdlib of the language and not in the IDE. Although things (e.g. execution path visualization) can be great in an IDE.

and I also want full-blown GUI tools so that I can build visual editors quickly.

Can you elaborate on this? Do you mean something like Windows Forms or something else?

What I largely don't care about are graphing tools - if someone wants to write the lib that's fine, but if your visualisation centres around graphs I don't care about your product.

My product currently centers around triangles but, hey, its in development. ;-)

I am just as interested in network visualization, for example.

So I want some of what you're talking about, but not in the form you propose and not modelled on a tool that's still primarily *aimed* at mathematicians - my working tradition is different, and some of that's for a reason (notation!). My ideal working environment for now looks suspiciously like a REPL for a sufficiently reflective language with a GUI lib attached, and one of these days I'll get round to spending some serious time with something in the Smalltalk tradition as a result.

F# already has a reflection, a REPL and GUI libs attached. I have yet to use the GUI libs extensively but they look great.

Some of what I'm asking for here is significantly more powerful than just graphics, perhaps that might be food for thought?

Absolutely.

If I might share my dream: I want typeset mathematics (LaTeX/MathML), 2D vector graphics and 3D scenegraph-based visualization. I want it declarative and as purely functional as possible.

When the F# REPL sees a value that represents typeset mathematics, 2D vector graphics or a 3D scene, I want it to transparently spawn a visualization of the value. I want throwback from the visualization back to F#, e.g. so you can edit a call graph or a mathematical expression visually.

I want everything hardware accelerated so you can fly around documents and do sophisticated visualizations without having to worry about performance.

So far, everything except throwback is working in OCaml and typesetting isn't up and running in F# yet. My God is it beautiful. I wish you could see what I see.

I would say "coming soon" but I am concerned about the reaction that might evoke from Chris or Anton.

Cheers,
Jon.

In general I agree with what you're saying, but:

For example, it would probably be infeasible to have written the Mathematica package in the PL used in Mathematica (IIRC, they used C).

Only a very small core of Mathematica is written in C, the very vast majority of Mathematica (as in 90% to 95%) is written in Mathematica. Yes it has a lot of functionality designed for CAS purposes, but it does actually have a fairly decent amount of general purpose programming functionality -- it just doesn't tend to be highlighted quite so much when you are just doing CAS work.

Only a very small core of Mathematica is written in C, the very vast majority of Mathematica (as in 90% to 95%) is written in Mathematica

Its source code is written in a combination of C and Mathematica, and for Version 5, the code for the kernel consists of about 1.5 million lines of C and 150k lines of Mathematica - The Mathematica Book, by Stephen Wolfram.

You can write a decent kernel implementation in 2kLOC of OCaml.

Cheers,
Jon.

But for what definition of "general purpose"?

Potentially anything where the need would arise to switch away from the CAS due to it not being appropriate to the tasks the students need to tackle.

How can first-class graphics be "counterproductive"?

That's an easy one: they could distract the student from what they're actually supposed to be learning. "Captivating" isn't necessarily always good. But what I was originally getting at was that the semantic characteristics of the language may not be appropriate, depending on how learning will progress after the CAS.

I agree that "it depends" but doesn't Mathematica provide strictly more than Scheme, for example?

"More" implies quantity of something, but it's semantic quality that I'm suggesting can be an issue. In some quite successful approaches to teaching programming, less is certainly more: "more" can distract from the core principles that are being taught.

So your more precise definition of "general purpose" is "potentially anything"? Come on. Name something that you want to do in teaching computer science that you can't do in Mathematica?

Cheers,
Jon.

So your more precise definition of "general purpose" is "potentially anything"?

That's certainly a pretty good definition of "general purpose" (which can also be defined as "not limited in use or function"), but for the "more precise definition", you should have avoided truncating my original statement.

Name something that you want to do in teaching computer science that you can't do in Mathematica?

Strict evaluation, static type systems, type inference, higher-order modules. (You might be able to fake the latter, but I doubt that it would provide a good basis for instruction.)

In any case, I haven't said that CAS languages wouldn't be suitable for any introductory teaching of programming. They're presumably very suitable for teaching people who plan to go on to do mathematical or scientific programming work, for example. They're less likely to be suitable for someone who's planning to go on to develop typical IT apps in Java or C#. I personally wouldn't use them as a first language to teach core PL semantic concepts, either: they tend to have too much arbitrary syntactic and semantic quirkiness.

Some of Mathematica's features might make for an interesting case study later in a course. However, its cost tends to be an inhibiting factor, even with academic pricing, and the essential semantic features of its language can be found in quite a few other "free" languages. Given that, it's not clear what positive factors exist to favor the choice of Mathematica or any other commercial CAS, except when teaching people who need to learn the CAS in question. You've mentioned graphics as such a factor, but many of the other teaching environments for programming also emphasize graphics, for the same sorts of reasons.

Let's start with some proposed "general purpose" programming languages: C++, Java, C#, Python, Lisp, Scheme, SML, OCaml, F# and Haskell and rule them out as we go...

Strict evaluation

C++, Java, C#, Python, Lisp, Scheme, SML, OCaml, F#

static type systems

C++, Java, C#, SML, OCaml, F#

type inference

C++, C#, SML, OCaml, F#

higher-order modules

SML, OCaml

Your list of "general purpose" languages grows thin.

Cheers,
Jon.

type inference

C++, C#, SML, OCaml, F#

My toenails start to curl when people say C++ has type inference.

I was only trying to give Anton's argument as much chance of being correct as possible.

From my point of view, clarifying "Mathematica is no good because it is not general purpose" with "it doesn't have higher-order modules" stinks every bit as much as implying that C++ has type inference.

Cheers,
Jon.

He did no such thing, he answered "Name something that you want to do in teaching computer science that you can't do in Mathematica?". If something stinks here, it's the rhetorical trickery.

Mathematica, Matlab, R, S-Plus, Maple, MathCAD, MuPad... All awesome compared to the state-of-the-art in the FPL world. All vastly better suited to beginners.

Here's a blog post about Teaching Mathematica as First Programming Language, by someone with some experience in that area. Although a bit of a rant, it also goes into some detail. I'm convinced. ;)

I'm a little curious if anyone of the PL teachers here doesn't favour a paternalistic educational model? I avoided programming completely and found it not worth spending my time unless I wanted to solve some algorithmic ( or meta-algorithmic ) problems. Mathematica was quite adequate and accessible for solving them. The development environment was decent. So my primary motivation to learn programming had nothing to do with programming languages themselves. They were a means and a medium. At the time I started to use them I didn't care for learning languages for sake of learning languages. That would have felt like intellectual masturbation and I already had enough of it during my mathematical studies. I have no idea what could have seduced me to learn Scheme.

Teachers, as we know them today, are mostly the product of medieval canonisation of teaching material and the mass school of the industrial age that is dated back no further than the 19th century. The idea that students have to be motivated by all kinds of gimmicks and teachers ( but also parents ) have to be a paradoxal crossover of entertainers and supervisors is even more recent and I don't believe we find much of its propaganda before the 80's of the last century. This evolution indicates a crisis. When someone has to be activated / motivated the cause is already lost - not at least because people are basically active / alife and can't therefore be activated. Usually this kind of discourse ends up in one of compensation. Frank Furedo is also correct in talking about "infantilisation" here. But his elitist counter-ideal is also brittle and might end up in academic irrelevance and snobism. However being a snob might be at least a personal ideal and should therefore be considered seriously...

This evolution indicates a crisis.

Indeed. Up until now, we've been able to mass-produce education in the subjects needed to run our societies, sufficient to meet our self-imposed needs. But the most important subjects have become too complicated and specialized to easily do this. Educating a large enough proportion of students to the level that is assumed to be required for continued progress-as-we-know-it is turning out to be a serious challenge. Hence the perceived need to motivate, via any and all means.

Underlying this is the dark fear that if we don't keep moving forward, we will suffocate, like a shark that stops swimming. Snapping at our heels[*] is the spectre of a descent into irrationality: widespread rejection of hard-won scientific achievements (evolution vs. "intelligent design"), or perhaps just a slow decline into the endless production and consumption of increasingly banal entertainment, ranging from TV reality shows to blog discussions about our imminent decline and fall.

It's almost enough to drive one to seek refuge in the comforting narrowness of a technical discipline, such as programming languages!
_{[*] so much for the shark metaphor[**].
[**] although one might question whether this thread has jumped one.}

So my primary motivation to learn programming had nothing to do with programming languages themselves.

Yes. I think the incestuous nature of your typical computer science syllabus underpins the comparative unemployability of computer scientists. They are not equipped to solve practically important problems so, if they can get a job, they'll either be back in academia or rebooting a server in industry.

I think this is a real shame because the programming languages that technical people use suck from a theoretical point of view. Compare the core languages inside Matlab and Mathematica to Lisp and SML, for example.

Cheers,
Jon.

The above comment is overly inflammatory and IMO has no place on LtU.

He writes Mathematica code as well as Lispers write ML.

His complaint about complexity applies equally to Lisp and Scheme (what is the asymptotic complexity of fetching the "n"th argument in a function), for example.

Cheers,
Jon.

A funny side note. I taught myself programming using Mathematica at university, where it served as a language for doing artificial life simulations and algorithm breeders, while Pascal scared me away from programming, some years before. So I draw the not representative conclusion from my own example that everything that doesn't scare a novice to programming is also a good teaching language. BTW I'm not completely sure why Mathematica style notebooks are not used more often in non CAS environments. I found them pretty ingenious.

Now that's what I'm talking about. :-)

Cheers,
Jon.

Learning Scheme in a REPL is an awful experience compared to learning Mathematica in a notebook.

And that's a statement whose truth entirely depends on a: the person doing the learning, b: the person doing the instruction, and (most importantly) c: what is being taught.

Additionally, whether or not it may be more "fun" to program with graphics readily available^[1], the more important question is whether it's more effective or not. If it's not improving the learning of the material, it can't be all that important, can it? Sexing things up solely for the sake of sexing things up seems like misplaced effort to me. Of course, if it doesn't hinder the learning effort either, then more power to whoever is developing the sexy IDE.

[1] And having had this to an extent when I got to college and had shiny new Macintoshes in the computer lab allowing us to learn Pascal by writing code to draw bezier curves and visualize sorting routines, where a year earlier in high school it was Pascal in a text only environment, I can say it simply wasn't that important to me -- of course I grew up in an age of text adventures, not Wiis, so who knows how I'd feel today.

The languages I cited are much more popular than any of Lisp, Scheme, ML or Haskell despite the fact that most of them are very expensive. So the users already voted, and they voted overwhelmingly in favour of graphics.

I'm horrified that anyone could disagree. Teaching programming is little more than teaching mathematics. Mathematicians have used typesetting since they first found a pencil. Now you're advocating that we stick to 80 columns of Courier because we used to have to? Sounds like Stockholm syndrome to me...

The languages you cited are domain-specific in a way that FPLs aren't - the vote you're taking is that of 'mathematical' users, what does that have to do with everyone else?

Mathematica is the package that I am most familiar with and it is no more domain specific than any of Lisp, Scheme, SML, OCaml, Haskell or F#.

If I want to plot a simple graph I go straight to Mathematica. Look at the verbosity vs speed plot of my ray tracer language comparison, for example. Nothing mathematical there, just dots and labels in 2D. So I contest your assumption that Mathematica is either domain specific or for mathematical users. I think that is a common misconception among programmers who have restricted themselves to plain-text-only languages.

Personally I've restricted myself to languages I can afford! And it's still clearly targetted at mathematical users even if it has general purpose power. Dots and labels in 2D are "nothing mathematical"? Hah.

You fell into my trap! By implying that "dots and labels in 2D" is a mathematical challenge, you've conceded that lots of programming challenges are "mathematical" so I didn't split the community by choosing a language that handles maths well!

Excuse me, I have to go and do a victory dance...

Cheers,
Jon.

No, it was split by choosing one that's marketed commercially on that basis and isn't freely available nor readily introduced to people who don't have a mathematical background. It's plenty possible, and I suspect the majority experience, to graduate from a computer science degree having never touched it or anything sufficiently similar - doesn't that rather suggest a split community?

That certainly suggests a split community. However, it does not suggest any asymmetry with respect to Mathematica. Computer scientists are just as unlikely to come across many other programming languages, e.g. VB, Python, Perl, Ruby, Lua, OCaml, F#, Scheme...

The reason is simply that you cannot hope to teach all languages to all students. If they're lucky, they'll be told about procedural, functional, OOP, logic and term rewriting.

... isn't freely available ...

This is a big problem. What about MuPad? That has a free edition.

Cheers,
Jon.

MuPad's free edition appears to be no more.

IME computer scientists are more likely to at least be aware that VB, Python, Perl et al are reasonable general purpose languages, give or take a "scripting" label. As you say, if we're lucky we get told about various different paradigms - but even you leave off working with graphical tools!

Now you're advocating that we stick to 80 columns of Courier because we used to have to?

The point was that people have different preferences and learning styles.

I'm horrified that anyone could disagree [...] Sounds like Stockholm syndrome to me...

Please tone down your rhetoric. See the LtU policies, particularly points 3 and 4.

I wasn't seriously suggesting that William was ritualistically abused by CEEFAX, although many people were.

Cheers,
Jon.

I'm horrified that anyone could disagree.

And I'm horrified that anyone would infer that prettier means better without any evidence. Well, not horrified, just disappointed.
I'm not saying that it wouldn't be a benefit. I'm saying that I'm unconvinced that it will be a benefit above what can already be done with simple libraries crafted to enhance the lesson plan, such as the one described in A library to support a graphics-based object-first approach to CS1, which is used as a tool, for example, in teaching structural recursion.

Sounds like Stockholm syndrome to me...

No. Just the words of a guy who hasn't needed any form of graphics in his profesional programming for 10 years or so (unless you count the web based front end for a demo that I volunteered to do last year). Of course, I do crypto research, so my viewpoint is a bit skewed. But there are plenty of fields out there like mine where the only place graphics and typesetting are useful is in paper preparation, and there, the text-based *tex systems are still worlds better than any graphical/variable font program out there (with the possible exception of professional layout and publishing packages).

In any case, this is about learning how to program, and not what you do/use once you've gained some ability. And here I'm still unconvinced that packages like Mathematica are really of any great benefit. I could be terribly wrong, but outside of perhaps enticing the students to explore outside of their lesson plan on their own, I'm unsure that it would help. Yes, in one sense, you can develop a lesson plan that provides good visual feedback that corresponds to what the student is doing, but a well designed plan can also do that in the text-only realm, or via the use of libraries that are developed for the subject matter like those mentioned above.

And the need for these extra niceties seems to become less and less important as the education continues past how to program and into what to write programs for. Years ago, when I was taking a class in automated reasoning, I used Mathematica for some work in algebraic proofs, and I never once made use of its graphical features. It provided me with nothing that an OCaml toplevel wouldn't have (outside of a suite of built-in mathematical functions). And I'm hard pressed to think of anything outside of my image and signal processing classes that would have seen any real benefit from such features (there, a domain specific package like matlab/octave and Khoros worked quite well -- even if Khoros was a minor pain to extend). Of course, all this is just personal experience, and the masses might indeed have different reactions.

To cut all of my rambling down to less than ten words, I'd go with something like: Sure, it's nice. But does it really help?

A REPL is a great way to get students to experiment. And experimenting is a great way to learn. First-class graphics take that a step further.

Let me ask the converse: if typesetting and graphics really are as uninspiring as you claim, why do people teaching computer science bother typesetting their maths and drawing diagrams?

Let me just throw in a case study here. I'm going to pull the singularly most text-oriented computer science book that I can find off the shelf and leaf through it, looking for typesetting and diagrams. I find Appel's "Compiling with Continuations" (an excellent book, BTW). Typeset maths on page 1, and almost every other page. For the first diagram I had to wait until page 107. But there is a diagram!

Indeed, these diagrams are just static representations of some idiological data structure. If we're all so good at programming, why not write a function to visualize whatever data structure the student creates? Wouldn't that help them to understand what's going on? After all, isn't that why Appel put all that effort into drawing this diagram for his book, to elucidate an otherwise abstract concept by visualizing it precisely because a graphical representation is the best way that we have invented to inject information into a student's brain?

I think so. I fill my books and papers with diagrams. I think a diagram is easily worth a thousand words, maybe even a thousand lexical tokens.

As for you managing to avoid toying with Mathematica's graphics. I dare you to tinker with some of the graphics examples from the integrated help. Maybe I'm a freak, but I find those things captivating.

Let me ask the converse: if typesetting and graphics really are as uninspiring as you claim, why do people teaching computer science bother typesetting their maths and drawing diagrams?

Let me just throw in a case study here.

OK... let me counter with Bach & Shallit's Algorithmic Number Theory vol. 1. It has two images in the entire book, and one is wholly unnecessary, yet it's still an outstanding book... The Handbook of Applied Cryptography is another text that's quite light on figures, yet is a standard in its field. And don't even make me pull out any of Goldreich's books... What does this mean? Pretty much nothing.

The thing is, I'm not saying that notions like typesetting and graphics aren't useful -- they can be and usually are very effective ways of conveying information (and if they're one thing I appreciate, it's good typesetting). What I am saying is that they aren't necessary (and are actually often overused and misused). A few examples spring to mind immediately: the twisted ladder representation of a Feistel cipher is a poor picture of what's going on -- it provides no intuition whatsoever why such ciphers are inherently invertible; the Merkle-Damgard hashing structure -- it's much more efficiently described as a fold over a list of blocks; getting back to PLT the worst offender is the ⊢ symbol used for type judgements. I read about 10 papers that used it before I came across one that bothered to explain how one should read something like (E,Γ) ⊢ t : τ. I had worked out something close to what was expected, but not quite the same. Would it have been so much worse to use a somewhat Objective-Cish typeof: t inContext: Γ andEnvironment: E → τ? Or even better, after a line of explanation, the more compact judge(t,(E,Γ)) → τ is much preferred (to me at least) over the cryptic ⊢.

One of the reasons I think we've become so reliant on typesetting like this is the space savings if gives us, even though we lose clarity. When I had to get a paper down to size for publication, I was forced to throw in all sorts of shorthand like ℰ^k_d0,d1(l,r) that even I, as the author, would forget the meaning of. And overloading of notation is another issue. If I were to write ( n / m ) (imagine the typeset version that looks like n choose m with a horizontal bar between the n and the m), would I be meaning the Jacobi symbol, or the Legendre symbol? The two are intimately related, one is a generalization of the other, but they're different enough that one needs to know which is being used. Similarly, what do I mean by the incantation ℤ/ℤ_p? Well, that depends on if I'm talking to a cryptographer or a number theorist...

Unfortunately, all of the above really has nothing to do with the topic at hand, which is whether typesetting and images built into a programming environment are of any great benefit when it comes to learning how to program. Now, I'll admit that I'm a quite unable to visualize the possibilities here, but about the only immediate benefit I can see in this circumstance is the ability to visualize tree-like data structures and perhaps simple state machines (of course these all need to be restricted to small cases, otherwise the picture becomes too crowded to be of much use -- but that's fine for introductory material anyway.)

Perhaps if you could provide some examples of what such an environment would be good for that can't easily be provided by a simple library, such as one built using lablgl for OCaml that might help me see your vision a bit more clearly.

I suspect the cryptic ⊢ predates computer science per se. One of the things that makes me wary about typesetting in general is that computer languages currently discourage some of the more wrinkly aspects of written mathematical notation and if we get in the habit of typesetting code for reading then that tends to make the stuff we write while we're editing rather uglier. I'd hate to have to write source code in TeX markup or the likes!

Oh, I'm sure it does. And the problem there isn't so much the symbol as the assumption that those who are reading your work already know how to pronounce, parse, and understand the symbols that you use. My calling out of ⊢ is essentially a product of it being fresh in my mind, and it being one of the worst offenders w.r.t. lack of explanation that I can recall seeing. Other representations just seem more, and I hate to use this word, intuitive to me.

As for writing source code in TeX, or HTML, or whatever, I do agree (though usually I find typesetting the code to be easier than setting the math behind the code). But that's what well made style files are good for. Programs to typeset programs rather than typesetting programs, and all that jazz.

It's one of those things where it's slightly difficult to realise you need the background and then pick it up - myself I was still looking to do my undergrad project at the time, and my supervisor pointed me at TaPL, but to someone sitting outside academia itself it's rather trickier.

This is when you join #haskell and go "wtf does |- mean?" Or whichever decent community of choice, though #haskell is a particularly good place for these types of questions, even if you don't really care about Haskell.

I suspect the cryptic ⊢ predates computer science per se.

Oh, I'm sure it does.

Phil Wadler described its history in Proofs are Programs. It evolved from a more pictorial depiction used for logical judgements by Frege, in 1879.

Re intuitiveness, I suspect that the readability of type judgements is not entirely a question of familiarity. I think there's a usability problem with the use of judgement symbols in representing modus ponens. The problem is that premises and conclusions are separated by an ordinary horizontal line, and the only unambiguous clue that modus ponens is being represented is the presence of multiple judgement symbols. It's almost as though modus ponens is represented by a single, very strangely shaped symbol, which looks like this:

⊢     ⊢
------------
   ⊢ 

I think it would be better to follow the model used by the big Sigma for sum, e.g.:

 ₄
Σ f(i)
ⁱ⁼⁰

I.e., use a single special symbol, and drop the judgement symbols, since they would be considered implied.

If the judgement symbol weren't already taken, it might have made sense to represent modus ponens something more like this:

B -> A
  ⊢ A
  B

...where the top and bottom positions represent premises, and the right hand side represents the conclusion. Of course a convention would be needed to scale to more premises, but that's easy enough.

Incidentally, I have heard (froom a proof theorist) the argument that the turnstile ⊢ should not be used as a symbol in a formal system as it traditionally indicates the meta-theoretical statement that some formula is derivable from given assumptions, and it's bad style to mix up the object language and meta-language.

That is why sequent calculus, which formalizes the derivability relation, is often written using ⇒ or similar arrows. Since simply-typed lambda calculus is effectively an intuitionistic sequent calculus with explicit proof terms, it would be reasonable to use the same notation with both, but, alas, this is not done.

(However, with a classical calculus there's less historical baggage, so Wadler had no problem using a "logical" notation style for the dual calculus.)

Oh, finally, I think I have also seen ▷ somewhere being used to separate the environment from the term in typing judgements. So there's a notational mess.

Since TAPL seems to have become the de facto standard introduction to type systems, I'm hoping that it will eventually form the basis for a more coherent notational convention that would be followed by everyone...

Since TAPL seems to have become the de facto standard introduction to type systems, I'm hoping that it will eventually form the basis for a more coherent notational convention that would be followed by everyone...

Except that the TT typesetting in TAPL is the ugliest thing since zubaz, particularly when you come to the second volume...

Exactly that sort of thinking is what led to the current diversity in the first place. :)

But I'm interested: exactly what do you find troublesome with TAPL's typesetting? Feel free to answer privately or in a new thread, as this is wandering pretty far from the original topic.

exactly what do you find troublesome with TAPL's typesetting?

The use of teletype font to represent phrases of the object language, particularly in rules and formulas. It wastes space, unbalanced spacing hampers reading, and it harmonises badly with other math symbols. In brief, it just runs afoul of all aesthetic lessons from typography.

TT fonts were originally designed to cope with the limitations of very poor printers or displays. Obviously, they were not optimised for aesthetics or reading experience in high quality printing.

Seems to me that "TT fonts" is most frequently used to mean "TrueType fonts". I gather from context that you mean something else. I think the US conventional abbreviation for "teletype" always has a "Y" in it, as in the infamously archaic and confusing unix message "not a tty".

I think for many these days, tt is more familiar as typewriter text, as in *TeX and HTML.

Perhaps if you could provide some examples of what such an environment would be good for that can't easily be provided by a simple library, such as one built using lablgl for OCaml that might help me see your vision a bit more clearly.

I'll do my best.

Graphic design predates the computer by a considerable margin. Graphic designers have evolved very efficient ways to get information into a human. The primary use of graphic design is advertising but the approaches are just as applicable to human-computer interaction. I believe that every single programmer can benefit from easier-to-use graphics.

I learned to program almost 30 years ago, on a ZX81. It visualized my program using a television. The display was black and white, the code written in a fixed font.

I moved onto a BBC B. One of the single most important factors that kept me on the learning curve was the ability to generate graphics using code as simple as "MOVE 10, 10; DRAW 100, 200". I like to call that "first class graphics".

By the time I got to university, I had progressed through a series of Acorns and had written several significant programs (e.g. the game TwoPlay). At university, my new PC had a GPU (Riva 128) and I wanted to use it. To my amazement, the barrier to doing graphics was vastly higher, both under Windows and under Linux.

Now, I have a graphics card with more computing power than my CPU that can render 10^9 triangles every second but writing a program to draw a single triangle is much harder than it was 10 years ago. Using OpenGL and LablGL you're looking at 25 lines of code, with F# and Managed DirectX you're looking at 100 lines of code.

I'm sick of having less than I did 10 years ago. I don't want less, I want more.

When I write a value representing a color into a REPL, I don't want to see "#ff4576", I want to see something drawn in that color.

When I write a value describing a 3D object, I want the computer to instantaneously visualize that object.

When I write a function to tesselate a surface into a million triangles, I want it rendered interactively using my GPU.

When I write a pattern match that rearranges a symbolic expression, I want an animated visual representation of the data structures and the rearragement.

But I don't want any of this stuff to be invasive. I'm looking for the next stage in the evolution of the blinking-parens, auto-indentation or color syntax highlighting. These things are not massive in-your-face features but they make an overwhelming difference to the usability of a system.

I'm going to put up a web page describing what I'm working on, with images and video, and you can tell me if you believe.

Cheers,
Jon.

I'm sick of having less than I did 10 years ago.

But you don't have less. OpenGL and DirectX offer you so much more than what your older machine was capable of. But the price for this is ability is extra overhead. it's a bit like with bicycles. You've got your fixed gear which is just a get on and ride and keep those pedals a-turnin'. Then you can move up to a single-speed which allows you the freedom to coast, but at the expense of having to maintain your freehub. Then you've got bikes in either category with flip-flop hubs which allow you to change gears, but you need to remove the rear wheel and flip it over to do so. A step up from there are simple geared bikes which give you the ability to select the gearing on the fly, but now you need to find the right spot on your friction shifters for the gear you want -- and you need to remember what the shifting patterns are, and you now have at least one derailer and set of cables to maintain and you have to learn about the limit screws so you don't throw your chain and so on. Then we can step up to indexed shifters, which do away with a lot of the hassle of friction shifters, but the shifters now have to be more carefully paired with the derailers, and the mechanism is much tougher to repair and to replace. Now we're getting some "automatic transmissions" on bikes, but good luck to you if you need to repair it and aren't a pro wrencher. So... do I have less with my current bike than I did with my old blue Mowhawk because I hove so much more overhead associated with it? I'd say no.

Anyway, you're always free to fire up the Graphics module of OCaml for your simple drawing tasks. This works just fine.

# #load "graphics.cma";;
# open Graphics;;
# open_graph " 600x600";;
# moveto 10 10;;
# lineto 100 200;;

Total overhead? Three lines.

When I write a value representing a color into a REPL, I don't want to see "#ff4576", I want to see something drawn in that color.

When I write a pattern match that rearranges a symbolic expression, I want an animated visual representation of the data structures and the rearragement.

Well, a lot of what you want could be done (though perhaps not in an ideal manner) via the installation of printers in the OCaml toplevel. For example, a *very* simple version of the first request can be done using (assuming you have an open graphics window -- you can just toss an open_graph in the printer if you wish):

type color = int * int * int;;

let show_color (r,g,b) = 
  let c = (((r lsl 8) lor g) lsl 8) lor b in
  set_color c;
  fill_rect 0 0 100 100;;

let print_color f (r,g,b as c : color) =
  show_color c;
  Format.fprintf f "#%02x%02x%02x" r g b;;

#install_printer print_color;;

This obviously has limits, as something like let l = [80,20,20; 128,128,128];; will only display the last color (unless I install an appropriate printer for color lists). Similar things can be done with the other visualizations by hiding a call to an OpenGL rendering stage in a printer.

I'll grant you that there are better alternatives. A simple one is to wrap the text output with something the display can parse to change the color of the text for you (ANSI color escapes are a very course way of approximating this). Of course, a simple wrapper around the toplevel offers much more flexibility, and formatting the output as HTML or similar and displaying its output in an HTML renderer even moreso.

And again there are tricky issues with scaling -- if you're manipulating a structure with millions of elements in it how will you visualize that? Zoom in on the local effect? Fit everything into a fixed size window so each item is indistinguishable from the next? What if you have a seven dimensional list of colors? What will you display? A two dimensional slice? Which slice? Can I manipulate the displayed object? What's going to be involved in telling the display to distinguish between two elements of a variant type? What's involved with choosing the desired representation? Would Expr (Add (Int 4, Int 7)) look the same as Section (Paragraph (Sentence "Hello world", Sentence "How are you?")).

Perhaps I'm being the uber-pessimist, not even seeing the glass as half empty, but wondering what would happen if half an anvil were dropped on it instead. Still -- I see lots of problems and not a lot benefit. Anyway, I fear this this is straying quite a bit afield from LtU-oriented discussion, so I'll just say that I'd love to see the web page once you get it up and would have no problem continuing the discussion off of LtU.

OpenGL and DirectX offer you so much more than what your older machine was capable of

Neither OpenGL nor DirectX offer simplicity. OpenGL is closer but it is still worse than BBC BASIC.

Anyway, you're always free to fire up the Graphics module of OCaml for your simple drawing tasks.

Right but, like I said, I want to use this £350 beast of a GPU. Incidentally, F# also provides native-code performance from the top-level.

And again there are tricky issues with scaling...

Very true. I just want the basic functionality to start with.

Would Expr (Add (Int 4, Int 7)) look the same as Section (Paragraph (Sentence "Hello world", Sentence "How are you?")).

Depends which printers you install. That is exactly the same as asking if the int32 "3" will display the same as the int64 "3".

I see lots of problems and not a lot benefit. Anyway, I fear this this is straying quite a bit afield from LtU-oriented discussion

I think this is the most important omission from current FPLs for a beginner.

Cheers,
Jon.

You're comparing BASIC with lower level libraries (DirectX/OpenGL) and complain that they are much more difficult to use, then when suggested to use a simpler library, you complain that it doesn't use efficiently the GPU.

Did BASIC used efficiently your hardware?

You're comparing BASIC with lower level libraries (DirectX/OpenGL)

No. I'm comparing what used to be provided with popular programming languages with what is now provided with popular languages.

Modern languages are often deficient when it comes to graphics. C++, Java, C#, OCaml, SML, Haskell etc. all require more code to draw a triangle than BBC BASIC did 20 years ago.

I think graphics are more important than higher-order modules and I don't think I'm unusual in believing that. I'd like to see a high-level interface to OpenGL/DirectX provided with modern languages like F#.

Did BASIC used efficiently your hardware?

Yes, it did.

Cheers,
Jon.

For Python, I'd add VPython to the list. I saw a really nifty series of video tutorials teaching physics using it.

TIOBE, Google fights, Google trends and so on. Matlab is almost as popular as Python, Ruby, Perl etc. and much more so than any "general purpose" FPL.

My statement about mathematics is really an assumption following implications by other people that we're really talking about the classical teaching of programming: evaluation, concrete data structures, parsing. I'm thinking SICP here. That's fine. Most programmers don't do that when they get a job, of course...

TIOBE Programming Community Index for April 2007
17 Lisp/Scheme
27 MATLAB
30 Logo
38 Haskell
47 ML
48 OCaml
49 Mathematica

Bad example. Check out this Google trend. Matlab walking all up and down Lisp's ass.

Cheers,
Jon.

Possibly because Matlab is, fundamentally, an engineering tool. And a very popular one at that. It's widely used by engineers of all stripes. Especially in fields like controller design, and signal processing. Some of those engineers may be doing Matlab programming. Many more are using Simulink, or Stateflow, or the various other Matlab add-ons for domain-specific analysis of engineering problems. You can't really compare Matlab and Lisp directly as programming languages.

Possibly because Matlab is, fundamentally, an engineering tool. And a very popular one at that. It's widely used by engineers of all stripes.

That is equivalent to: "Matlab is used by other people. It is used a lot. It is used by lots of people.".

Many more are using Simulink, or Stateflow, or the various other Matlab add-ons for domain-specific analysis of engineering problems

Also: "Matlab users use FFI and libraries".

You can't really compare Matlab and Lisp directly as programming languages.

That conclusion does not follow.

Cheers,
Jon.

That conclusion does not follow

You were trying to claim that a Google-based measure was a good comparison of the respective popularity of Matlab and Lisp as programming languages. My point, which you so glibly summarized as "Matlab is used by other people. It is used a lot. It is used by lots of people.", was that Matlab is used as far more than a programming language, so trying to use a Google-based comparison to draw conclusions about its popularity as a programming language is not a worthwhile exercise. Note, for example, that based on your proposed measure Star Wars is much more popular than Matlab. Of course, that comparison tells us very little.

Star Wars is much more popular than Matlab

While that is true, both Lisp and Matlab are programming languages. Star Wars is not.

I think we can agree that the usage of Lisp and Matlab is different but that doesn't exactly contend with my assertion that Matlab is more useful and more widely used as a consequence.

Cheers,
Jon.

...both Lisp and Matlab are programming languages...

...my assertion that Matlab is more useful and more widely used as a consequence

Again, that is precisely the point: Matlab the tool is widely used because of features other than the Matlab programming language. The widespread use of Matlab says little about whether the Matlab language is more useful than Lisp (or any other language for that matter). What it says is that Simulink, Stateflow, and the various Matlab toolboxes are useful to people who need to do engineering analysis.

Just to clarify my position here: I am not a Lisp user, let alone a Lisp fanatic. My sole experience with Lisp dialects is a little emacs Lisp, and a single class involving Scheme. I have used Matlab far more extensively than I have Lisp (or indeed many other programming languages). I have used Matlab in both engineering schools and in industry. It is a useful tool. But its usefulness stems from its support for domain-specific engineering applications.

Matlab is more than a programming language. It's also the numerical libraries, toolboxes, block diagramming tools, simulators, and other stuff that makes up a Matlab installation.

Then we're talking at cross purposes because we disagree about what a "programmer" is and what a "programming language" is.

I see a programmer as someone who uses a computer as a tool to perform computations. So I include physicists, chemists, biologists, bioinformaticians, engineers and, of course, computer scientists.

I see a programming language as a programmable software environment that lets you achieve this. Excel, for example.

With the definition I am using, a programming language that provides easy access to FFTs, linear algebra and graphics is vastly more useful than one providing higher-order modules and first-class functions instead.

I agree that there is merit in teaching obscure theoretical concepts, but they should be taught alongside practically-relevant material.

To quote the OP: "The First Language should be Practical". I wholeheartedly agree. We didn't invent cancer research to use the y combinator.

Cheers,
Jon.

I see a programming language as a programmable software environment that lets you achieve this. Excel, for example.

Given that sentiment, why are you not advocating Excel as a first language, rather than Matlab? Excel is (using your own popularity criteria) much more popular than Matlab. It's also much more "practically relevant" to a wider cross-section of students than is Matlab - it's used in everything from finance to spacecraft design, much more likely than Matlab to be encountered in the workplace by the average worker, and significantly cheaper than Matlab. Heck, it's even (according to Simon Peyton-Jones) a functional programming language. Not to mention that it includes embedded Visual Basic. Oh, and if necessary it can be used as a frontend to Matlab, so you also get "easy access to FFTs, linear algebra and graphics".

Speaking for myself, I would rather see teaching done with languages (such as Mozart/Oz or PLT-Scheme) that make it easy for students to learn general principles that they can then apply to many practical problems. I've done a fair amount of programming in Excel (including a tool which propagated spacecraft orbits, and computed solar illumination on different spacecraft faces in 3 dimensions - yes, Excel isn't really the best environment for developing such a beast, but that's another story), and I can guarantee that my use of Excel and VBA was significantly enhanced by the "obscure theoretical concepts" I'd previously learned through eduication with languages like Scheme.

[Edit: as we are drifting further and further into ungrounded discussion based on personal experience and preference, and away from conversations which are appropriate to LtU, I am unlikely to participate further in this discussion.]

Given that sentiment, why are you not advocating Excel as a first language, rather than Matlab?

I'm not advocating Matlab (I've never even used it) but, rather, its features. Like "first-class graphics".

Excel is (using your own popularity criteria) much more popular than Matlab.

While that assertion may well be true, your Google fight is undermined by the fact that "Excel" is a relatively-common word.

It's also much more "practically relevant" to a wider cross-section of students than is Matlab - it's used in everything from finance to spacecraft design, much more likely than Matlab to be encountered in the workplace by the average worker, and significantly cheaper than Matlab.

Maybe. I've never used either for serious work. I've just started playing with Excel because I'm being paid to. It has a kind of FFT but it isn't very good. It doesn't seem polished enough to be useful for most technical users.

Cheers,
Jon.

Higher-order modules and first-class functions make it simpler to extend a language to deal with things unforeseen by the language designer and to reuse code written by the programmer. In what way does having FFTs in the core of a language give advantages that having database access or networking support in the core of the language does not?

I include (by your definition) as programmers not just hard science researchers and engineers but also corporate IT developers, software testers, web developers, system administrators, game designers, data miners, desktop application developers, stock market speculators, search engine developers, and a whole lot more.

I could easily see many of these people wanting database primitives in a language proper, or financial functions, AI primitives, OS library overlays, or pretty much anything else. The way to keep all of these things that some people want and others don't out of the core of a language is to have strong support for libraries. Higher-order modules and first-class functions are two ways to offer this strong support.

Higher-order modules and first-class functions make it simpler to extend a language to deal with things unforeseen by the language designer and to reuse code written by the programmer.

Only in theory. In practice, there is a non-causal correlation between languages that have such features and languages with poor interoperability. This is a practically important observation that drives the choice of languages because few decision-makers are willing to risk choosing an experimental language that only has theoretical benefits. After all, the proof is in the pudding.

In what way does having FFTs in the core of a language give advantages that having database access or networking support in the core of the language does not?

None. I would advocate the use of languages that make database and network access easy as well.

I could easily see many of these people wanting database primitives in a language proper, or financial functions, AI primitives, OS library overlays, or pretty much anything else. The way to keep all of these things that some people want and others don't out of the core of a language is to have strong support for libraries.

Maybe, but the adoption of languages like OCaml is unquestionably hindered by the language designers resorting to "we'll provide higher-order modules and first-class functions and you can do everything else yourself with libraries" because writing or binding-to libraries can be very difficult.

Higher-order modules and first-class functions are two ways to offer this strong support.

I value interoperability over higher-order modules, which is why I'm choosing F#. I believe other people will too.

Cheers,
Jon.

Floppies aren't really relevant for ease of installation these days anyway though - ease of downloading, maybe, but failing that if you can get a distro on a CD all's fine. Bonus points if you can do a business card CD or fit on a sufficiently cheap USB key, I guess. Having a trivial installer that'll get a decent environment up and running is another matter though, and that's exactly where your C+asm setup fails.

I agree re historical order, and not just because you run into lisp pretty early!

Maybe I failed to make my point, but the floppy itself wasn't it.

My point is that the quality of the language for instruction should not necessarily be judged by the ease of installing the tools.

Many languages have implementations which don't require much space or much of an installer. My example was that I can put several assemblers and C compilers on something so small (let's call it a 2 MB flash card this time) and that they can even be run from right there in the directories on the distribution medium. For ease of installation, you can't beat copying a directory.

Now, I haven't done this much on modern operating systems. I tend to, now that bootable CDs and USB drives are so common, carry a pretty complete Linux with me everywhere. However, I do have a floppy diskette with a bootable MS-DOS (actually Windows 98 command line in the most recent version). On that diskette, I have three assemblers, a Pascal compiler, a C compiler, a Basic interpreter, a text editor, a grep tool, four or five linkers, a disassembler, a hex editor, and a debugger. All of the programs are running programs, not just archive files. A directory copy of this floppy would give me a number of languages with which to tinker on a machine. Yet I hesitate to recommend C, Basic, or assembly (particularly x86 assembly) as a first language. Pascal wouldn't be my first choice for an introduction, but I don't think it would be too bad.

I suspect what was intended wasn't just the ease of installing a minimal toolchain, but of installing a decent set of tools that're appropriate for the student. It's no good being able to produce a flashy environment if it requires hours of painstaking work for the student!

Me, I used to find archives and ramdisks were a good combination when I was a kid - especially if you had a load of stuff that figured 640K was enough.

The purpose of an introductory or programming CS class is to teach CS or programming, not system administration. Anything that can be set up once and put in a bundle on the school network should be considered. A disk image for a Live CD may even be worth considering.

The language is the important part here. Whether the language is C, Java, Forth, Logo, Basic, Lisp, or whatever else, the language matters much more than the ease of setting up an environment from scratch. This is especially the case since the student should not have to start from scratch as that's not the point of the class.

I don't know about you, but I'm not about to reboot my only desktop into another OS without really good cause - and I wouldn't be the only student reluctant to do so. So you want something that takes an install location and a couple of options for not crapping on people with existing setups (associations, blah blah) and then installs something that's otherwise entirely set up.

Ultimately, access to a good environment does matter - the world's best language coupled with notepad and a command-line compiler just isn't going to be as useful as a good environment for a slightly worse language.

I really disagree with you. I believe that shell scripting is a terrible language to teach beginners. That and...

Csh Programming Considered Harmful

...I figured most people in this forum would disagree with me on this opinion, but I do find sh (bash and especially ksh) to be very powerful high level programming languages that are well suited to beginners (especially those that are not going to go off and do programming and research for a living). This was the type of opinion I heard about LISP back in the day (easy for beginners, practically no syntax, etc), and this holds true for shell script as well.

And for the record, csh is a completely different shell than I am talking about, and yes, it is harmful. Here's some interesting factual information about shell script and it's high level features that you get "for free": http://www.rdb.com.

Just because it's old doesn't make it any less useful as a teaching tool.

Just because it's old doesn't make it any less useful as a teaching tool.

No one here is going to make that argument.

Personally, I like the idea of going bottom up from logic gates to whatever. But going top down, or some other combination, might work for others.

This whole idea of "best" is ridiculous.