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.
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.
What makes you say it wasn't designed as a beginners language? IIRC, Guido was involved in developing ABC, a programming language specifically designed at beginners. The problem was they tried to get C people to like it too and they didn't buy it. Another problem was trying to make it a little to theoretical (good for teaching). As a result, no one really used it for "real work". Guido took all he learned from this when making Python. It was not designed as a "beginners language", but it was designed by someone who knew what should be in a beginners language and how they could fail. He made a beginners language that was useful. Personally, my first experience with programming was Apple BASIC and Logo :) Talk about useless!
But Python is used in the real world and is recommended and used by experts and beginners alike. Just like people may be turned off from Pascal because it's rarely used outside of teaching (there are exceptions, of course), people might be against ML for the same reason. Few people take their first computer science class hoping to learn computer science--they want to learn how to program. And while the best goal is arguably to teach them how to learn any programming language, your retention rate and interest level are bound to be higher with something like Python.
Please correct me if ML is used more than I think it is, or if I got the history of Python wrong.
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.
You want flamebait, try this on for size, moron. My default threshold is 2, which means I have something interesting enough to say a fair amount of the time that enough weirdos moderated up my posts. Did you see a comment next to the 2? No. That means no one moderated it up. Learn the damn system, idiot.
I'm not finished yet, barfbag. Was I talking about fucking make? No. Did I say I liked make? No. Do I think its block structure by indentation makes sense? No. Should python make the same moronic mistakes? No. Jesus H Fucking Christ Perching On A Spin-Fuck Chair and Screaming Blasphemy, do you see what the fuck I mean by the bleating hordes?
Moderate THIS down.
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++.
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.
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 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