Rather than a new language, I'd like to see a good implementation of Sather really take off.
Sather is a wonderful language that provides a simple inheritance model, constrained genericity, good support for preconditions and postconditions and class invariants (I didn't appreciate these immediately, but once I figured them out my debugging time dropped by two thirds), and support for iterators (a rather different model than the C++ one), and some other features that would take a while to describe.
There is a GNU sather, but I'm not sure that its really active and I'm not enough of a compiler wonk to do much on it myself.
Most computer books - no matter how good - are out of date before too long, so a library would have to be very careful. Here are a few I'd put on the shelves - some obvious, more not so much. Several are out of print. For the most part this list avoids "how to" books on specific languages and systems - any such are probably too ephemeral for a library with a limited budget. Its not likely to be a popular list though.
<br>
Knuth - The Art of Computer Programming. This is a MUST - probably over the heads of half the people who will use the library, but not to be missed. (But then, anyone who knows me well, knows that I figure that in this imperfect world, Knuth is close to being God.)
<br>
Dijkstra - a Discpline of Programming. You may not always agree with Dijkstra, but you must respect him.
<br>
Kernighan and Plauger - Elements of Programming Style. Likely to seem dated to many, but I reread it recently and it has aged far better than other books that gained higher praise when first published.
<br>
The anatomy of Lisp (I dont remember the author) - Teaches quite a bit of the innards of a real programming system as well as a lot about recursion, internal representation of data and the like.
<br> Gamma... - Design Patterns. When I read this, it was a revelation of sorts - put into words things I'd known for a long time.
<br> Baase and Van Gelder Computer Algorithms- Currently my preferred algorithms book - one of the sections taught me quite a bit about an algorithm I thought I already knew.
<br>
Kernighan and Ritchie - The C Programming Language
One of the few language specific books I'd recommend.
<br> Foley, Van Damm... Computer Graphics - There are better texts, there are better books on graphics systems, but this one is the best for showing the breadth of computer graphics and giving the basics of how it all works.
<br>
Felleisen, Friedman - the Little MLer - every procedural programmer should look at functional programming - it will improve their procedural code. This is an excellent start. And non programmers will find it a fun way to start learning about ML and programming.
<br>
Revised Report on Algol 68 -- not just a language specific book, but one for a language nobody uses. Still, you can learn a lot about language design and programming from this.
<br>
Okasaki - Purely Functional Data Structures -- A wonderful short book with a lot of information in it - I'm still digesting some of it, but implementing the algorithms has taught me a shitload.
<br>
Eliens -- Principles of Object Oriented Software Development. About the best general all around book on OOP and its process. Not specific to any particular methodology, but lots of good info.
<br>
"sometimes a bad programmer is better than no programmer"
Ewwwww! A bad programmer can increase (and quite radically) the workload of the others on the project. A bad programmer can cause a project to fail completely (I was in a startup where one of the programmers was convinced he was the "Java God" and he basicly went unchecked and destroyed the project and the company). A bad programmer might let a bug through that could cause injury or death. (Admittedly, so can a good progrmmer, but its less likely.)
I teach CS - and teach CS to beginners and I use Java. The reasons are simple - its free, available on most platforms, there's a good deal of documentation and books available, its relatively simple, and you can do graphics with only a bit of code overhead.
For the most part I try to give out assignments in which most of the code is provided by me and I ask the students to change it, add a few things and so on. Having taught CS to beginners for a number of years now, this has been the most successful for me - but its labor intensive - I usually require the students to do a 2 hour lab each week and these function best when I have enough TA's (who can be second or third year undergraduates) to have one for every 6 or so students. I like graphics because the students get to <b> see </b> results quickly.
My goals though may be different than other instructors at this level - I want students to start to <b> look </b> at code quickly and to start to think about how to check their results (Does it work?)
I've thought about Smalltalk - and looked seriously at squeak, but I think the learning curve there is quite steep at the beginning and there is a relative lack of good documentation.
I don't use C or C++ - C pointers are tough and C++ is just way to big a language to learn quickly unless you skip all the stuff that makes it powerful (and dangerous).
But I also try to stress that the language doesn't matter - that learning new languages and systems should be something that CS people do all the time. And I try to get students to learn languages that use seriously different paradigms - it doesnt matter if the language is popular - its what the student is <b> thinking </b> about the software process that is important. I've recently been using Haskell in classes - but the students claim that Haskell is not used anywhere and that it is thereby a waste of time. My goal though is not to teach them Haskell so much as to teach them a programming language that is radically different than any they've already learned.
However, I've been branded "the worst CS teacher ever" by some of my students (but I've also had students say that I was the only CS teacher that they learned anything valuable from). My current employer "Eastern Orgone University" is terminating me in part because I've required students to learn new languages. Instead they've found someone who is requiring students in early courses to pass in programs on paper.
Back in the mists of prehistoric time I used a Univac 1100 system running some Univax OS whose name I forget for the moment. It had the (um) feature that in text files, the last five versions of the file were stored in the file itself with each line marked with its version. So you could easily move backward - up to five versions back.
Of course, this did rather complicate reading in a text file a bit.
You often hear that voting for anyone but the top two candiates (often about as dissimilar as tweedledum and tweedledee) is a waste of your vote - but its more likely that voting for one of them is a waste of your vote. Most of the major news media now say that the presidential election will be decided in about four states. This seems to imply that if you are not going to vote for the candidate that is forecast to be the winner you will be wasting your vote. So instead of wasting it on tweedledum - vote for a third party candidate whose views you agree with.
Slashdot Mirror
Rather than a new language, I'd like to see a good implementation of Sather really take off.
Sather is a wonderful language that provides a simple inheritance model, constrained genericity, good support for preconditions and postconditions and class invariants (I didn't appreciate these immediately, but once I figured them out my debugging time dropped by two thirds), and support for iterators (a rather different model than the C++ one), and some other features that would take a while to describe.
There is a GNU sather, but I'm not sure that its really active and I'm not enough of a compiler wonk to do much on it myself.
Most computer books - no matter how good - are out of date before too long, so a library would have to be very careful. Here are a few I'd put on the shelves - some obvious, more not so much. Several are out of print. For the most part this list avoids "how to" books on specific languages and systems - any such are probably too ephemeral for a library with a limited budget. Its not likely to be a popular list though. ... - Design Patterns. When I read this, it was a revelation of sorts - put into words things I'd known for a long time.
<br>
Knuth - The Art of Computer Programming. This is a MUST - probably over the heads of half the people who will use the library, but not to be missed. (But then, anyone who knows me well, knows that I figure that in this imperfect world, Knuth is close to being God.)
<br>
Dijkstra - a Discpline of Programming. You may not always agree with Dijkstra, but you must respect him.
<br>
Kernighan and Plauger - Elements of Programming Style. Likely to seem dated to many, but I reread it recently and it has aged far better than other books that gained higher praise when first published.
<br>
The anatomy of Lisp (I dont remember the author) - Teaches quite a bit of the innards of a real programming system as well as a lot about recursion, internal representation of data and the like.
<br> Gamma
<br> Baase and Van Gelder Computer Algorithms- Currently my preferred algorithms book - one of the sections taught me quite a bit about an algorithm I thought I already knew.
<br>
Kernighan and Ritchie - The C Programming Language
One of the few language specific books I'd recommend.
<br> Foley, Van Damm... Computer Graphics - There are better texts, there are better books on graphics systems, but this one is the best for showing the breadth of computer graphics and giving the basics of how it all works.
<br>
Felleisen, Friedman - the Little MLer - every procedural programmer should look at functional programming - it will improve their procedural code. This is an excellent start. And non programmers will find it a fun way to start learning about ML and programming.
<br>
Revised Report on Algol 68 -- not just a language specific book, but one for a language nobody uses. Still, you can learn a lot about language design and programming from this.
<br>
Okasaki - Purely Functional Data Structures -- A wonderful short book with a lot of information in it - I'm still digesting some of it, but implementing the algorithms has taught me a shitload.
<br>
Eliens -- Principles of Object Oriented Software Development. About the best general all around book on OOP and its process. Not specific to any particular methodology, but lots of good info.
<br>
"sometimes a bad programmer is better than no programmer"
Ewwwww! A bad programmer can increase (and quite radically) the workload of the others on the project. A bad programmer can cause a project to fail completely (I was in a startup where one of the programmers was convinced he was the "Java God" and he basicly went unchecked and destroyed the project and the company). A bad programmer might let a bug through that could cause injury or death. (Admittedly, so can a good progrmmer, but its less likely.)
Bad programmers are Bad News .
I teach CS - and teach CS to beginners and I use Java. The reasons are simple - its free, available on most platforms, there's a good deal of documentation and books available, its relatively simple, and you can do graphics with only a bit of code overhead.
For the most part I try to give out assignments in which most of the code is provided by me and I ask the students to change it, add a few things and so on. Having taught CS to beginners for a number of years now, this has been the most successful for me - but its labor intensive - I usually require the students to do a 2 hour lab each week and these function best when I have enough TA's (who can be second or third year undergraduates) to have one for every 6 or so students. I like graphics because the students get to <b> see </b> results quickly.
My goals though may be different than other instructors at this level - I want students to start to <b> look </b> at code quickly and to start to think about how to check their results (Does it work?)
I've thought about Smalltalk - and looked seriously at squeak, but I think the learning curve there is quite steep at the beginning and there is a relative lack of good documentation.
I don't use C or C++ - C pointers are tough and C++ is just way to big a language to learn quickly unless you skip all the stuff that makes it powerful (and dangerous).
But I also try to stress that the language doesn't matter - that learning new languages and systems should be something that CS people do all the time. And I try to get students to learn languages that use seriously different paradigms - it doesnt matter if the language is popular - its what the student is <b> thinking </b> about the software process that is important. I've recently been using Haskell in classes - but the students claim that Haskell is not used anywhere and that it is thereby a waste of time. My goal though is not to teach them Haskell so much as to teach them a programming language that is radically different than any they've already learned.
However, I've been branded "the worst CS teacher ever" by some of my students (but I've also had students say that I was the only CS teacher that they learned anything valuable from). My current employer "Eastern Orgone University" is terminating me in part because I've required students to learn new languages. Instead they've found someone who is requiring students in early courses to pass in programs on paper.
Back in the mists of prehistoric time I used a Univac 1100 system running some Univax OS whose name I forget for the moment. It had the (um) feature that in text files, the last five versions of the file were stored in the file itself with each line marked with its version. So you could easily move backward - up to five versions back.
Of course, this did rather complicate reading in a text file a bit.
You often hear that voting for anyone but the top two candiates (often about as dissimilar as tweedledum and tweedledee) is a waste of your vote - but its more likely that voting for one of them is a waste of your vote. Most of the major news media now say that the presidential election will be decided in about four states. This seems to imply that if you are not going to vote for the candidate that is forecast to be the winner you will be wasting your vote. So instead of wasting it on tweedledum - vote for a third party candidate whose views you agree with.