Slashdot Mirror
Computer Programming for Everyone
jbc writes "According to Guido, DARPA has accepted an initial version of a proposal called Computer Programming for Everybody. The idea is to use government money to develop and promote a Python-centered curriculum for high schools and colleges. He defends the choice of Python, as opposed to languages like Perl, Tcl, or Visual Basic, because the latter are, in his view, 'too cluttered with idiosyncracies' to be effectively taught to beginners. " This is actually something I've been peripherally involved with. My CS teacher and I have been talking with Guido about this (I go to Yorktown, one of the schools mentioned in the proposal) - I can tell you firsthand that C++ is just too difficult for first-year CS students in high school, whereas Python is quite simple and elegant. Hopefully, this program will serve as a nice intro for students so that they can get started in programming and perhaps move on to other
languages as they become more and more accustomed to the practices of programming.
Although Python is elegant, it was not designed as a beginers language. Almost no languages have been designed in this way, with Basic (and Pascal) being the ones I can think of. But I would not advocate the use of these languages.
My choice would be (although I don't like it for general purpose programming) ML. This has been designed from the ground up to be syntatically and semantically well designed and provide all of the facilities for well formed design and implementation. It can (and is being) be extended to provide a whole specification language with facilities for ensuring that the final code matches the specification. The MLWorks enviroment provides a nice front-end on many platforms. It's also got a really simple syntax, and can be made to do some really powerfull things (like infinite presision arithmetic.)
I have been programming for 35 years and have taught several programming courses. One of the best books I ever came across for learning programming was George Polya's "How to Solve It", originally written in the 1940's.
It didn't have much about coding (since computers weren't around when he wrote it) but it did have a lot about analysis of problems, frameworks, abstraction and most other tools of modern programming.
In one sense, introductory programming should not need computers at all. Computer programming has two main tasks. The first is developing algorithmns, the second is developing data representations. Each task affects the other but both are neccessary for correct implementations of systems. Developing algorithms for hand implementation (playing computer) helps you understand things much better than trusting any language implementation.
Drawing diagrams of the relations between data elements is neccesary before declaring any types and objects in a language.
Only once someone understands iteration, alternation and object properties on paper should the computer become involved. Thus the language should be as close to formalizing natural language descriptions of problems as possible.
Python is a good language for algorithmic analysis because of a clean clear syntax, although dependence of indenting for blocking can sometimes confuse people.
It is not such a good language for data type analysis because it allows mistakes in types to stand in programs. Python with a stronger type system would be a good teaching language, especially with the case insensitivity of Alice.
Python's a good choice, but what really needs to be done is to separate the coding aspect from the theory aspect (I know, difficult to do). I went to school at Lehigh University where, among other things, I delved a little into the CS department (I was an architecture major, so it was a bit of a sidestep). I hadn't had any programming experience prior to Lehigh, and I cut my teeth on programming theory using Pascal. The programs are so basic at that level that idiosyncracies don't matter, but learning Pascal itself became the major obstacle. Since then, Lehigh's taken their curriculum and moved it over to C++, but the introductory course teaches neither C++ or Pascal. It uses a pseudocode that is very simple, so the class really becomes about theory and not about coding. Later, you learn C++ as part of coding, and you already have the background to handle the theory part. Because the theory part is so complicated and the coding so simple, they can go into different ideas that may not be available in a certain language. That, I think, is where CS studies should go.
Personally, I use Perl non-stop and it was very easy for me to pick up, even having only a Pascal background. I learned Perl reading through old source code and reading the man pages. I do think that programming should be taught by Unix admins. The best CS course I ever had at Lehigh was a course called C & Unix which was taught by Lehigh's EECS sysadmin. I learned so much about coding, and it was all stuff that the Windows-based professors didn't seem to think was important.
*clink* *clink*
There's my two cents.
Yes, Java removed multiple inheritance, and replaced them with what? Interfaces. Interfaces that have no protection against stomping on each others namespaces. Interfaces that you must reimplement, from scratch, by hand, on any class that implements them. Interfaces that almost demand you access private class data of the implementing class regardless of whether the interface was meant to know about it.
All that said, it's possible to write clean interface code, but god knows they aren't intrinsically any better than a mixin class in C++ (a mixin being a non-derived class that is used for MI purposes). Matter of fact, they're basically the *same thing*, only without any kind of namespace protection.
Now C++'s use of pointers as object identity drives me bats, I won't argue with that.
"If you deny yourself a useful tool simply because it reminds you uncomfortably of your own mortality, you have uselessly and pointlessly crippled yourself" -- Chairman Sheng-Shi Yang, _Ethics for Tomorrow_
I've finally had it: until slashdot gets article moderation, I am not coming back.
Indeed. Which is why you don't start teaching Java that way.
I've written and taught a number of Java programming courses for a number of types of customer (Postgrad AI students, 4GL junkies, complete beginners, OO gurus), and even those who have never written a line of code in anger have tended to take to Java like a duck to water.
A few introductory exercises clear up the difficulties with tools (whether it's the command-line tools or an expensive IDE), and the fact that it's difficult to avoid basic OO concepts from the start is a bonus as far as I'm concerned. If I want to teach nasty procedural stuff, there are other languages far better for that.
Don't get me wrong: I'm not claiming that Java is inherently a better language for teaching to beginners than Python (I don't have the background in teaching Python to make a fair judgement on that, and I don't believe you can make that sort of comparison anyway). But I will say that my experience as a trainer is that Java is a good language to teach to those new to programming.
One final point: probably more important than the choice of language is the skill of the teacher/trainer. For whatever reasons (lack of skilled staff almost certainly being the foremost), IT appears to be the one subject where schools are happiest to use sub-standard teachers: I don't think any member of my family was ever taught by an IT teacher who knew more than his/her pupils...
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
actually this is why javascript should die as a language:
operators: =, ==, and ===
Check this out:
Boolean x = new Boolean(false); if (x) { y; }
y will be executed. Every object is true in an identity test, including Boolean false. However:
x = false; if (x) { y; }
y will not be evaluated. a literal false is still false, but an instance of it is not. false is true unless it is the True false. my head just exploded at that point.
I've finally had it: until slashdot gets article moderation, I am not coming back.
Yunno, if the company wants me to deliver a package and gives me a coughing banging studebaker that still starts and barely makes the speed limit, I can do my job. Do I want to be using that tool to do the job? No. Did they teach you that concept in management school?
I've finally had it: until slashdot gets article moderation, I am not coming back.
it runs on many systems, it's very similar to C++ and pretty easy to code. Also you can do lots of cool stuff with it early (web graphics and so on), which is really important if you want to keep interest of your students.
Of course a relational database is the best option. But there's definitely no reason you can't decouple the framework from the database stuff. The problems you're talking about only happen if you base the design of your application based on the DATA. That's completely the wrong approach. You design your framework based on the application domain. The flexibility to change the way data is accessed should be built into the design. You certainly shouldn't have your database structure duplicatd in your object model. If that's the case, the design isn't even object oriented.
For example, if a customer can suddenly have more addresses instead of one, the customer object will have read its address from a different table: it's, therefore, broken.
See, this is a perfect example of the design being wrong. Does a customer know his address? Yes. Does a customer know how to go into your database and store or retrieve his address from your files? I certainly hope not, and I hope you realize why this is wrong.
> High School students should be taught how to read WELL, write WELL and do math WELL.
AMEN! Programming is the skill of telling a computer what you already know how to conceptualize and structure. It's the formation of concepts and ability to structure it that is foundational to programming, writing, speaking, planning, analysis, and just plain critical thought. I took no CS classes at all all the way through grade school, and my exposure to computers was owning a VIC-20 then a C64 which I wrote trivial BASIC programs on. The most instructive class I ever had was 5th grade grammar: I must have diagrammed hundreds of sentences in that class, which taught me to recognize structure in sentences. This is an invaluable skill in recognizing patterns in programs now.
I've finally had it: until slashdot gets article moderation, I am not coming back.
My high school offers C++ as the language for first-year CS students, and it doesn't seem to be a major problem. In fact, all high schools wishing to participate in the AP curriculum/tests must offer C++ to their CS students, since the AP CS test is only offered in C++ (changed from Pascal about 2 years ago).
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
As an old man (48 years old) who has made his living programming for a long time now, I will vociferously support ANY effort to teach kids programming. Computer programming is the love of my life, my passion. There's nothing more satifying. Whether it's Python, Perl, C, C++, even COBOL, I'm for it. If taxes need to be raised to get kids into it, I'm for it. I want the next generation to love it as much as I do.
I don't know about US, but in my country if you call yourself a CS student people assume you're smart enough to learn Pascal or C.
Not that I don't like Python (actually I don't know anything about it).
-jfedor
> Most /.ers seem to dislike Visual Basic. There can only two reasons for this: a deeply rooted hate for Microsoft, and pure ignorance.
Just cuz you say so don't make it so. Ignorance, hatred of Microsoft, and let's not forget a vast deep disdain for BASIC. Let's enumerate some of its faults:
Overloading of = by context. Strictly speaking this wouldn't have been too bad if the use of the LET keyword was enforced, then you're simply asserting a fact. But let's be real, it's just silly as it's used now.
VB's idea of error handling: ON ERROR GOTO
VB has no idea of inheritance. None. I've seen some hacks to do it, and wow are they Not Fun.
Rather laughable string functions like MIDSTR$, lacking really fundamental functions we expect to see to manipulate strings. Last I checked, there wasn't a simple index() function (or strstr() as C would call it)
I've finally had it: until slashdot gets article moderation, I am not coming back.
I don't even want to attempt to try and respond in full to your entire messge, because I could easily spend hours writing a huge essay in response. I'll just focus on the part where you discuss OO, since a pet peeve of mine are all the misconceptions I see about OO, particularly on Slashdot (they seem to be less prevalent in the industry).
Now, sorry if this comes off like a flame, but the above sounds like it's coming from someone who doesn't understand the real principles behind object oriented programming, and who does not have experience working on large-scale software projects. In my experience I have found the opposite of almost everything you say to be true. The only problem with object oriented development is that most programmers don't know how to do it properly.
I have seen projects succed and fail, and I am quite convinced that given competent designers, using an object oriented approach is guaranteed to be more successful (in terms of time, money, and risk) in a large project than other methods of design. There is an overwhelming amount of evidence out there that this is the case. Look into some of the research. Read some of the books on software engineering. You are right that an object oriented design will increase the overall complexity of your design. This is a good thing, since it's precisely what gives object oriented designs their inherent flexibility. Flexibility is the most important benefit of an object oriented design. Another consequence of an OO design is that it will drastically decrease the complexibility of the individual and components within your system. Even on the surface this should be obvious if you think about it. Clearly object oriented models better represent their associated real-world systems than other methods like data modelling. I don't see how anyone can argue that. Now, if the inherent complexity of a system is in the overall design, that is where it should stay, is it not? Other techniques only move the complexity elsewhere, which is less natural, and therefore inevitably more expensive to maintain. You have to expend more effort to constantly differentiate between your application domain and your model since they become quite different.
These business objects "know" your data structure, and, therefore, have to be informed of changes in it.
NOT TRUE!!! In a proper OO design, you do not have "data structures". You have data, which is distributed throughout the objects in your system and encapsulated by those objects. But you should never have to think about data structures. I suspect you have a lot of experience with bad OO designs where a lot of data is passed around. This happens a lot in practice, but is simply poor design.
only two reasons for this: a deeply rooted hate for Microsoft, and pure ignorance.
Actually, in my case it simply doesn't provide the flexibility I need to design complex, large-scale software systems. VB has it's place. I think it is a very good tool for prototyping, and in many cases is appropriate for develping the GUI front-end of an application. I don't use it myself, as I prefer other tools for those purposes, but I can see where it would be useful.
You may, for example, ask most classes, in code, what their properties are, what their methods are, and what their parent class is, and so on. C/C++ not only lack self-knowledge
You don't understand; VB is more of a high-level, dynamically typed scripting language. That's why it can do these things. One can debate the merits of static typing vs. dynamic typing, C++ vs. Smalltalk, etc. all day, however with a proper OO design, you should never need to ask a class what it's properties or methods are. There are rare cases where you might want to know if a class supports a certain interface, which is what dynamic_cast is for in C++. But by and large you're doing something wrong if you ever need these capabilities in C++.
The most important thing to learn from a first language is coding style. *grin* You can code dirty later, but you should know how to code clean.
Most languages have a similar underlying way of looking at the world. Once you've got that you can twig another languages syntax easier, because you know what you're looking for, IMO.
£0.02
Well, well, well; three holes in the ground...
Dude... woefully false. That's all I have to say. Yahoo's web server is apache, which is written in C, so sorry.
I've finally had it: until slashdot gets article moderation, I am not coming back.
I don't think that Java is suitable for teaching to beginners, especially little kids; it is simply too complex. Personally, I'd have sprung for something even simpler, like Scheme, but Python is also fairly easy to learn; its biggest advantage over Java is that you can program outside the class structure, which means that you can introduce people to the most basic concepts ('the computer does one thing after another, this is a variable, you can print values out, ....') without having to explain all of object-oriented programming to them or, worse, give them a 'magic formula' to make things work. Daniel
Great, now that you've boldly proclaimed your child genius status; do you have any other accomplishments to list? I'm pretty sure many people reading Slashdot learned how to code around that age, humble myself included. Perhaps working at Pizza Pizza would have been much better for building a real character; and perhaps the modesty that usually accompanies real geniuses.
One lesson GvR took away from ABC was the importance of OS interfaces; in ABC you couldn't walk through directories or open files, though it provided persistent variable storage that was an abstraction on top of files. This made ABC a nice sandbox to play in, but you couldn't get out of it, and ultimately this proved too confining.
... C isn't. While I don't want to knock Python, I feel it is more useful for a beginner to learn a fairly low level language like C first.
...
The problem I have noticed with CS graduates who have learnt high level langauges to the exclusion of all else, is that they can't then grasp `real world' programming concepts. This may only be a problem afflicting British CS grads, but it is becoming increasingly hard to find good staff.
Programming isn't easy, although languages like Perl and Python can make certain tasks much easier than they were with C. The problem is making the distinction between tasks that should be tackled with tools like Python, and those that should be tackled with C or C++.
Perhaps it is time that CS degrees were split into systems programming courses and scripting based ones. There is a massive demand for programmers who will rarely need to touch compiled languages like C (with its memory allocation and lack of inbuilt dynamic types). So differentiating courses this way could allow a student to focus on one of these two distinct areas.
Or maybe this is just a refelction of my disgust at the low skillsets of CS grads being produced nowadays
Chris Wareham
I think that this is a great idea. I recently meet a foriegn exchange student from Yogosloviva. He said that in 6th grade you could start taking programing classes their. They first learned pascal and then could goto C. Here in America for at least the Florida Education system you can't have typing classes until 8th grade. And Practical computer skills are tought in 9th. I'm a Senior in high school and we are still using PS2's. The only internet access we have is on Imacs, and their are only like 10 for a school of 1600.
The American education system sucks. They could have at least taught me how to spell decently.
1. Questions
The most important issue, and one which surprisingly few posters have addressed, is to identify the properties that are desirable in a 1st programming language. Identify also which properties are considered undesirable in that same environment. Once you've done a thorough study of these issues, only then can you analyse existing programming languages for how well they fit these criteria, or to create a new one that better satisfies them than existing languages. But until you know against what metrics these languages are to be judged, you cannot objectively do so.
Is this ideal beginner-oriented programming language also a language that's good for other focused domains? Will the decisions you've made in designing or selecting this ideal beginner-oriented programming language render it less than optimal for programming that isn't oriented toward non-programmers? Or if you add in properties conducive to non-beginner programming, will this compromise your goals of creating something for beginners?
Can we leverage our natural cognitive strengths in learning natural languages to learn a programming language? Does this imply that we acquire language more readily when we have lots of easy, contextual examples than we would if presented with sets of rules and axioms? Does this mean learning by a usable subset of a language first, and only adding sophistication if and when it becomes necessary? If so, does this not engender dialectical subsets? Would a beginner (equivalent to a seven-year-old speaker of his native tongue) confronted by a complex piece in the language (say, equivalent to a doctoral thesis) find himself somewhat lost? Would it be better to throw out the language you'd learned until age seven and start a new one so this can't happen, or is it better to learn incrementally?
Does it make sense to expect the same language that is used for one domain to be equally applicable to an unrelated domain? Aren't domain-specific languages both more powerful and more user-friendly?
Are we talking about a particular age group, such as ages 9-12, 13-17, or 18-21? Does this affect our criteria? Should a university really be used as nothing but a high-classed tech school as feeders for industry? If so, shouldn't diverse core curricula emphasizing reading, writing, and effective skills get more attention?
Do we understand the differences between "IT" training and "CS" training? What's a business programmer, and how is that different than a programmer? Is the goal to teach programming, or is it to teach computer science? Or are we just talking about teaching computer use? Since when is a computer science degree required to use a computer, or even administrate it?
How do you define "readability"? Does resemblance to a natural language suffice? Is this a good thing? Remember one notorious attempt to create a programming language that even non-programmers could use cursed us with Cobol. Wouldn't it be nice to avoid that next time around?
Is readability culturally biased? Can a language designed to be easy for Unix users to learn be equally easy for non-Unix users? Can a language designed to be easy for non-Unix users to learn be equally easy for Unix users? Think of it this way: Does your knowledge of Greek help you learning Russian? Is it the character sets, or are there more important underlying similarities? Is a language designed to be used by people who know language XXX going to be different than one designed for those ignorant of XXX? Do semantics grow out of syntax (ordering, positioning), or should they be explicitly reinforced by inflection markers (singular vs plural, noun vs verb, etc)?
Should a programming language require a fancy, hand-holding IDE before it can be used effectively, or should a line editor suffice? How much hand-holding is useful to the beginner but annoying to the expert? Can you make a programming language that's designed to be completely learnable in a very short time that doesn't rule out its use later down the road? Is "user-friendly" well defined? Does "user-friendly" always denote "expert-hostile"? Will software that pleases one set also please the other set? Should it? Are languages designed for short-term use or long-term use? Where then should optimization occur?
That's certainly plenty to think about, and mostly what I just did is provide important questions that should be thought through. In many of the questions, there is no single right answer, but there are consequences. Try answering the questions in more than one way, and then compare the resulting trade-offs that arise depending on which path you took.
2. Answers
I certainly don't have all the answers to those questions. But I do have some comments on the Perl matters. The first is that Perl and Python are actually essentially the same language, and that there are a great deal of other sorts of languages out there that a computer scientist should be exposed to. Much like the warning to beware the man of one book, also be wary of the programmer of just one programming language.
And before you can begin to compare two languages, you actually have to know them both! Oh, not necessarily with equal fluency, but you actually have to have taken the time and energy to play with them, to sound them out in real situations. Superficial assessments based upon surface appearances are useless.
The "scripting language" versus "programming language" bigotry is nothing but cultural arrogance borne out of theoretic ignorance. I'm aware of Ousterhout's paper, and I have responded to it before. John is a very bright man, but like all of us, he carries with him his own historical baggage from the past and unfolding agenda for the future.
In this case, this a false dualism of "scripting" versus "programming" does nothing but harm. It has virtually no basis in theory, and little in practice. The assertion that byte-compiled Perl or Python can't handle certain tasks but that by merit of being compiled to machine language, C or Pascal or Ada or Modula automatically can--well, this is completely ludicrous.
Rob Kolstad long ago conjectured the following: "The success of a new programming language is directly proportionate to its resemblance to C." Perhaps a more accurate statement would be "The degree to which a new programming language will be embraced by C programmers is directly proportionate to its resemblance to C." And now you can swap in other programming languages in that equation.
As far as real-world programming goes, I assert that the majority of it gets done using C or a derivative of the same; and yes, I consider Awk, C++, Java, and Perl to be derivatives of C. Now, I'm not trying to claim that this is the best of all possible worlds. I'm simply stating that it's the reality. And given that reality, overcoming the inertia to get existing C-oriented programmers to jump to a completely different programming language, such as Smalltalk, Lisp, ML, or Prolog, is non-trivial at best.
There was some question of non-Unix support for Perl. As far as non-Unix ports go, Perl runs on so many diverse sorts of systems that it's easy to lose track of them. Not only that, but it also ships (or will ship in the next release) as part of the standard O/S release. Perl in some form ships with, or can ship, with at least some systems from these vendors: Apple, BSDI, Be, Compaq, Data General, Debian, FreeBSD, HP, IBM, Microsoft, Novell, OpenBSD, Red Hat, SCO, SGI, Sequent, Siemens-Nixdorf, Slackware, Stratus, and Sun. Those are just standard systems. The major workstation vendors like SGI, HP, Sun, IBM, and DEC/Compaq are all shipping Perl with their current or upcoming release. That means it's in the standard vendor configuration, which is important to many people.
Of course, Perl I run on nearly anything, including: 3b1, aix, altos486, amigaos, apollo, aux, beos, bsdos, convexos, cxux, cygwin32, dcosx, dec_osf, dgux, dos_djgpp, dynix, dynixptx, epix, esix4, fps, freebsd, genix, gnu, greenhills, hpux, irix, isc, linux, lynxos, machten, mint, mips, mpc, mpeix, ncr_tower, netbsd, newsos4, next, openbsd, opus, os2, os390, posix-bc, powerux, qnx, rhapsody, sco, solaris, stellar, sunos, svr4, ti1500, titanos, ultrix, umips, unicos, unicosmk, unisysdynix, utekv, uts, uwin, and vmesa.
On the matter of Microsoft compatabilty for you MIS and IT types, we CS types have tried very hard to make sure that standard Perl programs try very hard to run everywhere. That doesn't mean you can't get at the Unix getpwuid() function or the Microsoft Win32::Process module if you want, but that's not the same as basic functionality that is expected runs everywhere. This includes portable systems programming as well. Basic systems programming functions in Perl like rename() and flock() are not restricted to those systems that support rename(2) and flock(2) syscalls, i.e. kernel traps. We use whatever emulation is necessary to provide the same semantics using whatever your system's primitives provide.
And we don't stop there. The POSIX fork(2) syscall, that simple, elegant, and incredibly powerful feature that has long formed an essential keystone for systems programmers, and one which Mr Bill has never figured out how to do, will be supported on Microsoft's systems as well. This will show up in the 5.6 release of Perl, which is now in late alpha and imminently passing into beta. That means your traditional multitasking server that calls accept() on a socket and then fork()s off a clone to handle the incoming connection will work even if you're a Prisoner of Bill.
If you aren't familiar with the wealth of Perl modules out there, or how easy it is to build and install them, you should look at this search engine.
Perl has seriously different design goals than Python. One of these was to be easy for Unix programmers to learn and use, both simple sh programmers and sophisticated C programmers. Another was to support incremental learning and incremental growth of the language itself. Another was to provide good support for multiple different programming styles (procedural, object oriented, and functional), which goes along with avoiding moral judgments about programming style issues and letting people program the way that comes naturally to them. Python supports both procedural and object-oriented programming reasonably well, but its support for functional programming is clumsy and unsatisfying. Without the nested lexical scoping in anonymous that languages like Perl and Scheme provide, there's only so much you can do. This is not in practice an onerous restriction, however.
Another was speed of execution; as a result of this design requirement, Perl's compiler is remarkably more clever than Python's, because it does quite a few more optimizations and special-case detection at compile time, so that run-time is more streamlined. This includes string-related issues like pattern matching, but also simple base programming features, such as when identifiers are looked up in symbol tables. Python was never designed to run fast, and by and large, it doesn't.
Perl was designed to conform itself to the programmer, not to make the programmer conform themself to the language. This is seen in the "do what I mean" (DWIM) principle. Matters such as memory management and strong typing are largely there to help the computer not the programmer. Because of this, you'll see Perl and Python take divergent paths when it comes to these matters. For example, Perl will automatically allocate space for strings, indexed arrays, and associative arrays as they are needed, without requirements of pre-growing the way Python's lists need. Another example is that Perl doesn't distinguish between 3/2 and 3./2 the way Python does. In Perl, a number is just a number, and if the compiler or run-time library needs to perform some promotions behind the curtain to do what the programmer meant, it goes and does it.
Perl was also intended to support short-cuts for common programming tasks so that expert programmers wouldn't be forever bogged down by spelling things out the long way. In short, it was designed to be expert-friendly, by which I mean that it did not become tedious for those who actually knew how to use it. One example of this is the multiple assignment statement of
Some of Python's design properties were that explicit is better than implicit, that general cases are better than special ones, and that simple features are better than complicated ones--even when this makes the programmer to put the simple features together in complicated ways. But like any language that actually gets used, these goals are not always followed. Compromises happen. I'm not going to sit here and point out all the warts and knobs in either language. Rest assured that they are there.
Do not be distracted by Python's whitespace issue nor by Perl's type-markers. These are both red herrings that aren't related to the core of what the language can truly do. Interestingly, both of these features commonly cited as negatives were actually added to ameliorate not to exacerbate legibility.
Despite Perl and Python starting from different sets of design criteria, they are, in most of the senses that really matter, the same language, just as C and Pascal are really the same language. I strongly encourage anybody who only knows one of them to go out at learn the other as well as you can in a week or two's worth of playing around. Try to write equivalent programs. By and large, you'll find that the final program takes more lines of code in Python than it does in Perl, and that the Perl version runs faster than the Python one. But not usually by a large amount. Usually it's just 20% or 30%.
But if the problem domain happens to be text manipulation, (and not just sed and awk style either), then the difference can be far more dramatic. It is not at all unheard of to find that Perl requires just 1/3 the code that the Python does, and that the Perl version runs in just 1/10 the execution time. Perl is not just about text processing, and there is no tool that's best for all jobs. But if there's one place where Perl outshines all competitors, this is that place. Even people who are heavy users of Python often turn to Perl for these tasks.
Learn as much as you can.
Comment removed based on user account deletion
Comment removed based on user account deletion
The Alice developers modified Python in a few way to make it easier for their intended audience. The major changes were:
Those are the only changes I can remember from the talk, and it's a remarkably short list. They also avoided using XYZ coordinates, instead using object positions and directions. For example, you can say rabbit.lookAt(copter), after which an Energizer bunny object will always stare at a helicopter, no matter where the copter object is moved. People had no trouble with the idea of objects, but little things like case-sensitivity threw them.
As someone who has done an undergrad degree in CS and is currently working in the industry for a large company (they don't get much larger), I would say that I strongly endorse Smalltalk as the best language for teaching the fundamentals of OO. If you haven't heard of it, Smalltalk is a language with a very simple english-like syntax; the syntax can be mastered in less than a day. This is very important, because many languages which are touted as great for teaching have such a massively complicated syntax that the only time the entire rules were bound together in one volume, it underwent gravitational collapse and became a black hole (apologies D. Adams). I've seen students get so caught up in the syntax of these languages that they lose sight of the fact that they are supposed to be learning how to PROGRAM, not how to PROGRAM IN (insert language of choice for this year).
Many of the "new" features of a language such as Java were in fact borrowed from Smalltalk, which has boasted them for over 20 years. These features include Virtual Machine/Bytecode technology and Garbage Collection. However, Smalltalk has many other features that make it ideal for teaching. For example, EVERYTHING is an object: no base types, no "magic" classes that aren't really objects, etc.; Java sacrificed these critical features in the name of efficiency.
For a time, the university that I attended taught Smalltalk as the first year language (after I had gone through...). Unfortunately, choosing a good language is only half the journey. I saw, much to my dismay, that rather than getting a solid grounding in Object theory, students were learning useless and irrelevant things like how to put pretty buttons on windows. I realize that SOME visible gratification is necessary, but delving right into widgetry before the basis of programming has been drilled in is useless. Such things are implementation dependent, and much more importantly, language dependent. When Java becomes the thing of the past, there will be 200,000 Swing programmers out there who are screwed because the only thing they know how to do is add a component to a panel. They don't understand the deeper issues at hand, and will find it hard to adapt to new technology because they will have to learn it all over again. Given a solid grounding, any new language is simply a variation on principles that you learned in your first year.
Please don't think that I believe that OO is the solution for everything. I've done my share of C, Assembly, and other non-OO languages. I simply think that OO is a great teaching tool because it mirrors real-life interactions, responsibilities and state of objects. I also know that it is relevant in the workplace, otherwise I wouldn't have a job right now. Even procedural languages can be programmed in an object-oriented manner, although the method of doing so usually overrides the simplicity desired of a teaching language.
I don't want this to sound like an advertisement, but you can get gnu-smalltalk for just about any unix-like system. VisualAge for Smalltalk is available from IBM on www.software.ibm.com/ad. VisualWorks is available from ObjectShare, formerly ParcPlace, at www.objectshare.com. Squeak is available from www.create.ucsb.edu/squeak.
I'm convinced that JavaScript shouldn't even be a language. The ideal is elegant enough, but due to the fact that different implementations exist, and there isn't a suitable consistency to even the most basic of ideas (try working with pull-down menus in forms for what I mean), JavaScript is a pain for even the most hardy of programming veterans to grasp.
The language isn't what's important. What's important for CS studies is the theory behind the language. Languages come and go (witness Ada, Java, etc), but the fundamentals rarely change.
But why start from scratch when it comes to programming environments? Why not build on the decades of experience with other teaching languages, like Logo, Scheme, and Smalltalk?
And for real-world relevance, the facts of life are that there are hundreds of "little languages" serious computer users need to learn. Rather than pretending that everybody can exist in a little shell, exploring what is out there in the real world might make for a much better introductory CS curriculum.
And, in fact, even the "little languages" casual computer users encounter teach a lot of interesting concepts: event driven programming (dial-up scripts, game character programming), functional programming (database queries), OOP and message passing (Apple's scripting languages), etc.
I think it's nice to see more money go to Python, but the proposal really doesn't make that much sense to me. I think the development of a good introductory computer curriculum should start with no preconceived notions of which language to use.
I think computer literacy is a prerequisite to programming of any serious type. You need to understand how computers work, how they process data, and the various methods of I/O before you can attempt to program. For people who just discovered that Word has a spell-checker... getting them to learn programming will be about as successful as convincing Microsoft to drop their crummy MFC classes in favor of Java...
--
Java would be a horrible choice for beginners
for example, "Hello World" in Java is :
// Java application hello.java
//compile: javac hello.java
// run: java hello
public class hello {
public static void main (String[] args) {
System.out.println("Hello World!\n");
}// end of main
}//end of class
The student has now learned out to output one
line of text, but is left with the questions:
"What is a class?", "What is static?", "What is
void?", "What's the difference between javac and java?" and "What is System.out.println?" An
awful lot of stuff to try to digest on the
first day.
The same code in python :
#!/usr/bin/python
print "Hello World!"
Pretty self explanatory. Also, Java's got plenty
of wierdness that came from being based on c++.
For instance, how would you explain the difference
on and int and Integer to a new student.
Which leaves the student with the questions
Um, pardon me if I come off sounding elitist, but programming is not something that can be taught to your average user without a *lot* of background work. Teaching someone to program without having them understand what the heck is going on inside the machine (as it seems they want to do) is Bad and Wrong.
Furthermore, the choice of Python because it's "easy on the eyes" and has "simple syntax" is questionable: Python has its own quirks and weirdnesses that make it just as bad as Perl/Tcl/whatever.
Programming is *not* about languages. Programming is about problem solving and algorithm creation/manipulation. Once you understand these ideas you can learn almost any language and implement them. Granted, there are are a few different programming "styles" available (imperative, applicative, declarative), and learning to translate your solution into those molds is important, but understanding the basic problem-solving and algorithm manipulation *must* be done first, before any actual "coding" begins.
I think we should all have understood by now that the criteria by which people assess the quality of a programming language/tool are mostly wrong. The worst of which are: bit-level performance and object orientation.
/.ers seem to dislike Visual Basic. There can only two reasons for this: a deeply rooted hate for Microsoft, and pure ignorance. There may be a lot of things that can be done better in VB. However, VB and Access have quite a large amount of self knowledge. You may, for example, ask most classes, in code, what their properties are, what their methods are, and what their parent class is, and so on. C/C++ not only lack self-knowledge, even worse, these languages require you to code details that are of no interest to problem at hand. C/C++ is for people who don't understand programming. What is programming? It's rather simple: A is the amount of time you have, and B is the result that you need. If you then chose C/C++, you should go and see a shrink.
Bit-level performance is a non-issue for most programmers. The operative word here is "most". What do most people write anyway? Well, just look at who is paying most programmers: corporations. What do they need from programmers? Programs that run their business, that is, programs that help with order processing, manufacturing, payroll, accounting, and so on. Most of these programs spend 95% of their time in larger frameworks that manage the databases, the GUIs, et cetera. Therefore, your language of choice may be fast or slow, it won't make any difference. If you want speed in these applications, chose a fast database, a fast GUI framework and fast, other supportive components.
Object orientation is another one of these miracle cure-all solutions that almost never work, even though no one will openly admit it. By modeling business apps as objects, you will not only lose a lot of time, but, even worse, make your applications much less maintainable. Why so? Because the complexity of business applications is in their data, and the only thing you will do by modeling business applications as object frameworks, is to replicate this complexity once more in your object classes. And then you will have an extra chunk of code to maintain, when you change your database structures. Next to your database design, your GUIs and your batches that you need to maintain, you will need to maintain the so-called business objects. These business objects "know" your data structure, and, therefore, have to be informed of changes in it. The duplication effort is ridiculous and only pays off in wasted time.
The whole concept of business objects is a laughable hype. Quite naturally, the more someone is ignorant and incompetent, the more he will jump from one hype to another, trying to use the latest fad, and miserably fail. This is normal, because the only way incompetent people can judge a technology, is by hyping along with the rest.
I didn't say that object orientation is a bad idea altogether. I've said that it is of no use in typical business applications, and even dangerous.
What is a true criterion for quality in a language/tool? Well, as ever. It's definitely not new. Read the classical Greek literature for the source of true wisdom. A language/tool is of high quality if it has a high level of self-knowledge.
A relational database is a great tool, primarily, because of its self-knowledge. You can ask it what tables it contains, what relationships there are between those tables, what columns they contain, what datatype they have, and so on. You don't need to enumerate all fields in a particular table in your program. You may prefer to work at a more abstract level, and define rules that work in general, and only mention the exceptions to the rule. Therefore, You may manage your code by exceptions, instead of replicating knowledge all over the system, and create potential for inconsistencies.
Most
Please remember that the point of this proposal is not to churn out programmers who can write CORBA applications, or add to the Linux kernel. This proposal's main purpose is to raise computer literacy, which includes the ability to understand the very basics of how a computer works, and how to make modifications to existing applications. Hopefully this education program will also help future systems programmers and computer scientists get a head start, but I will address that issue later in this comment.
I believe that having lots of programmers who can modify and extend applications is a good thing. Yes, most people will not be good programmers, but this program, if implemented well, will give people the skills and tools to make real contributions to our software that we might not even be able to conceive of right now.
Raising computer literacy will also help in discussing and deciding technology issues as a society, especially as government establishes a larger role in privacy, security, and censorship across the internet.
I have read many posts questioning Python as the choice for a first language. How many of you first learned Basic, then went on to learn C, C++, assembler, and other languages? Did Basic really impede your development as a programmer, and do you really think that Python would be worse as a first language?
My point is that future hackers will learn to use other languages, even if their first language is not C++ or Java. I learned Basic in high school, then Scheme, C, Lisp, and assembler (MIPS) in college. I somehow doubt that learning assembler was made any harder or easier by learning how to program Basic on a Commodore 64.
One previous poster made a very good point that high school should be for learning basic skills such as reading and writing, and not for vocational skills. If done properly, learning how to program can teach one how to think logically, communicate effectively, and organize information in a coherent manner. In order to motivate students and give them positive feedback, it may be necessary to give them work that produces something that is useful, or at least works. I know that it was frustating to only be able to print "Hello world" when I was first learning C.
This is why a user friendly development environment is vital for teaching programming to everybody. On a related note, does anyone have anything to say about the DrScheme? This is a Scheme development environment for beginning students. Is Guile a useful thing for DrScheme, or are the two things irrelevant?