Posts tagged ‘C’

Improve Computing Education: Take the More-than-Java Pledge

I have a sure-fire way of improving computing education.  Everyone reading this, post this to your blogs and Facebook status and every other way that you make public, digital statement these days:

I promise to no longer teach Java to anyone at the undergraduate Freshman level or earlier.

I am teaching Java in my Media Computation Data Structures class this semester, the first time I’ve taught first year students in four years.  I had forgotten how bad Java is for beginning students!

My students are almost all non-CS majors.  This is all their second semester CS course, but for the most part, last semester was the first time any of them had ever programmed.  Their first course was in Python (robots), Python (MediaComp), or MATLAB.  It’s a small enough class that students actually do come to my office hours, and that lets me see the aggravating errors that they are facing.

Here’s a common error — it’s a faulty method declaration.

public void foo();  
{    
    // blah, blah blah
  }

The error you get is: missing method body, or declare abstract.  Sure, that message makes sense if you understand about semi-colons and blocks, but if you don’t…”What’s abstract?!?  I have a method body there — why doesn’t it see it?”

Here’s the one that I saw multiple times (both versions), which I find just infuriating.

while (a < 4);
{
    // do something in here, and probably change "a"
}
if (sometest());
{
   // do something if true
}

These are infuriating because there is no error — the first generates an infinite loop, and the third one just always executes the body, ignoring the result of the test.  Programs don’t work, and the compiler gives no clue that the students did something that only experts can handle correctly.

I’ve read Kernighan and Ritchie.  I know that, with magical side-effects and complex C-magic, one doesn’t actually need to have a body on loops and IF’s.  Everything can be done in the IF or WHILE test, or in the body of the overly-complex and macro-like FOR loop.  But why allow that in a language for beginners?  We’d never want to teach that to first year students, and by allowing these experts-only practices in Java, we lay land-mines for them!

I completely believe that students should learn C-based languages, and Java is a powerful tool that most CS students should learn.  But not to start.  It’s a lousy language to wrestle with when you are still trying to understand what commanding a computer is all about.  My students are trying to understand object interactions and creating dynamic data structures, and errant semi-colons are eating into all of their programming time.  Seriously — a bad semi-colon may cost a starting student 30 minutes of programming time (as Matt Jadud’s ICER 2006 paper showed).  If you can only afford two hours of programming time for an assignment, one wrong semi-colon now means you only have 90 minutes.  If you can’t complete the assignment, you never get the motivation boost of success and your grade suffers.  I really believe that semi-colon errors correlate with our retention problems.

So why do we teach Java so early?  Because it has become the language of CS education.  We have to teach Java to prepare students for what comes next.  This is particularly salient for me because, as of this semester, we no longer teach Smalltalk to students at Georgia Tech.  Lisp died from our curriculum about a dozen years ago.  Now, the required courses teach (in order): Python, Java, Java, C, Java, and options in upper-level courses between C, C++, C#, and Java.  If students want, they can take a specialty course where they might see some ML.  I don’t think GT undergraduates can even take a class where they’ll use Lisp anymore.  C has won.  This is a learning problem because I worry that students won’t develop cognitive flexibility without these other language approaches. Forget about transfer, forget about vocational training — let’s focus on being able to think about problems and representations in different ways. Here’s our goal in Rand Spiro’s words (which weren’t about programming, but fit perfectly): “Cognitive flexibility theory suggests that learners grasp the nature of complexity more readily by being presented with multiple representations of the same information in different contexts.”

The real tragedy here is that few of us can take the pledge.  I can’t take the pledge, either.  We live in an educational ecology, and none of us can act alone. If I did, then I would be doing my students a disservice — they would be unprepared for their later courses.  If high school teachers took the pledge, then they couldn’t teach AP CS, and there would be even less high school in CS.  And no, that wouldn’t be a good thing — by every study we have, students without a CS course emerge from high school with extremely ill-informed and negative views of CS, and any high school CS makes things better.  High school students with CS have a better understanding of what CS is, and are more likely to pursue later studies.

How do we get to a better place from where we are now?  We who teach CS all have to decide that there’s more to programming computers than C, that 1973 was not when humans reached their peak in ability to communicate with a computer.  We have to recognize that other forms of programming are important, even if it doesn’t get students a job.  And by teaching those other languages, perhaps we create a seed to change industry, too.  We just can’t settle for what we have now.   We have to decide to teach other kinds of programming languages (somewhere!), and to create pathways so that we don’t doom students who don’t have Java in their first year.

Here’s a pledge that I hope that all computing faculty can make:

I pledge that I will work with my colleagues so that all of our computing undergraduates will learn a programming language that is not based on C, and we will build that into a required course within the next two years.

March 1, 2011 at 8:20 am 63 comments

Is 2011 the year of Scripting? 11 hot skills for 2011

Interesting that prototyping and rapid development is predicted to make a comeback.  Maybe this is the year when scripting becomes more important than more traditional, compiled languages that have a main() in them?  Many of us already think scripting is pretty important, and much easier to learn.  Yet, C++ is still taught in an awful lot of CS1 classes.

About 47% of the survey respondents who said they plan to hire IT professionals in the next year will be looking for people with programming or application development skills. Moreover, Monster.com reports that three quarters of 245 HR managers and recruiters it surveyed in May plan to hire IT staffers with applications expertise by the end of this year.

“Those skills are separate from enterprise business applications,” says David Foote, CEO and chief research officer at Foote Partners LLC in Vero Beach, Fla. In this volatile market, companies need to quickly reposition, as well as use IT to grow the business through new products and innovation. So “RAD, rapid programming and agile programming seem to be coming back. Companies are starting to increase some of their pay [in these areas], which means they’re looking for more capabilities in their companies,” he says.

via 11 hot skills for 2011 – Computerworld.

February 2, 2011 at 10:23 am 5 comments

New Myro Languages

Doug Blank just sent out this report on where the IPRE robot education technology Myro was going — the movement into new languages and platforms is pretty exciting!

This is a note to let you know the status of three new versions of Myro,
the API to interact with the Fluke and Scribbler. For more information on
any of these projects, please feel free to use this mailing list.

1) Myro in C++. This project has been developed at the University of
Tennessee at Knoxville, by Bruce MacLennan, John Hoare, and others. Mayro
in C++ is ready to use. For more information, please see:

http://wiki.roboteducation.org/Myro_in_CPlusPlus

2) Myro in Java. This project is underway at DePauw University by Doug
Harms. Myro in Java is under development and ready for testers. For more
information, please see:

http://wiki.roboteducation.org/Myro_in_Java

3) Myro in the Pyjama Project. Pyjama is a new scripting environment for
Python, Ruby, Scheme, and more. This is the latest version of Myro from
the IPRE. Pyjama is designed to run very easily on multiple platforms, and
with multiple languages. Pyjama is under development and ready for
testers. Form more information, please see:

http://pyjamaproject.org/

The pages at http://wiki.roboteducation.org/ will begin to change to
reflect these exciting developments and alternatives.

I invite users and developer of all of these systems to further describe
the projects, and provide additional details.

-Doug

January 28, 2011 at 8:43 am 13 comments

Predictions on Future CS1 Languages

A recent article in InfoWorld on up-and-coming languages got me thinking about the future of CS1 languages.  They went on at some length about Python, which I think most people consider to be the up-and-coming CS1 language.

There seems to be two sorts of people who love Python: those who hate brackets, and scientists. The former helped create the language by building a version of Perl that is easier to read and not as chock-full of opening and closing brackets as a C descendant. Fast-forward several years, and the solution was good enough to be the first language available on Googles AppEngine — a clear indication Python has the kind of structure that makes it easy to scale in the cloud, one of the biggest challenges for enterprise-grade computing.Python’s popularity in scientific labs is a bit hard to explain, given that, unlike Stephen Wolframs Mathematica for mathematicians, the language never offered any data structures or elements explicitly tuned to meet the needs of scientists. Python creator Guido von Rossum believes Python caught on in the labs because “scientists often need to improvise when trying to interpret results, so they are drawn to dynamic languages which allow them to work very quickly and see results almost immediately.”

via 7 programming languages on the rise | Developer World – InfoWorld.

There have only really been three “CS1 languages,” the way that I’m using the term: Pascal, C++, and Java.  All three programming languages were used in a large (over 50%) percentage of CS1 (intro CS for CS majors in post-secondary education in the US, and AP in high school) classes.  All three were AP CS languages.

Pascal at one point was probably in over 80-90% CS1 courses.  Not everyone jumped immediately to C++, but C++ was in the majority of CS1 classes.  I know that because, when our Java MediaComp book came out, our publisher said that Java had just pulled even with C++ in terms of percent of the market — that means C++ had to have been in lots of classes.   Java is the dominant language in CS1 classes today, but it’s declining.  Python’s market share is rapidly growing, 40% per year the last three years.  While it’s not clear that the new AP CS nor the AP CS Level A would ever adopt Python, Python might still gain the plurality of all CS1 languages.  I doubt that any language will ever gain more than 30-40% of the CS1 market again — there are (and will be) too many options for CS1 languages, and too many entrenched interests.  Faculty will stick with one, and may skip a plurality, e.g., I’ve talked to teachers at schools where they stuck with C++ but now are switching to Python.

I have two specific predictions to make about future CS1 languages, based on observations of the last three and the likely fourth.

  • All future CS1 languages will be in common use in industry.
  • No language will gain a plurality of CS1 courses unless it existed at the time of the last transition.

The transition from Pascal to C++ led to the greatest spike in AP CS Level A tests taken in Georgia.  Until 2010, that was largest number of AP CS exams taken in Georgia.  The transition from C++ to Java had nowhere near that kind of impact on the test numbers in Georgia.  What might have led to so much more interest in the Pascal -> C++ transition?  Pascal was a language that was not (perceived to be) common in industry, while C++ was.  I don’t think that people perceived such a huge difference between C++ and Java.  I believe that the sense that C++ was vocationally useful, was approved of by industry, had a huge positive impact on student interest in the test.

In this blog, we have often touched on the tension between vocational and academic interests in computer science classes.  Vocational most often wins, especially in the majority schools.  The elite schools might play with BYOB Scratch in their intro courses (but notice — even at Harvard and Berkeley, it’s for the non-majors, not for those who will major in CS), and community colleges might use Alice to ease the transition into programming, but the vast majority of schools in the middle value industry-approval too much to adopt a pedagogical language for their CS majors.

The implication of the first prediction is that, if Scratch or Alice are ever adopted for the new AP CS, only schools on the edges of the distribution will give CS major credit for it, because most schools will not adopt a CS1 language that isn’t useful for programming in industry.  That isn’t necessarily a bad thing for the new AP CS — to succeed, schools must agree to give some credit for it, not necessarily CS major.  Another implication is, if my prediction holds true, Scheme will never gain a plurality in CS1 courses.

The second implication is based on an observation of the timing of the four languages.  Each existed as the previous was adopted for the AP CS Level A, which is a reasonable point at which to claim that the language had reached plurality.  C++ existed (since 1983) when the AP CS Level A was started in Pascal (1988, I think).  C++ was adopted in 2001, and Java came out in 1995.  AP CS Level A shifted to Java in 2003, and Python 1.0 came out in 1989, with Python 2.0 (the one receiving the most interest) in 2000.  It takes a lot of time to develop that industry use, and to build up the sense that the new language may be worth the pain in shifting.

The implication is that, whatever the next CS1 language will be (after Python), it exists today, as Python reaches plurality.  Maybe Ruby, or Scala –more likely Ruby, given the greater industry penetration.  Any language that we might invent for CS1 must wait for the next iteration.  Scratch, Alice, and Kodu are unlikely to ever become CS1 languages, because it is unlikely that industry will adopt them.  Few professional programmers will get their jobs due to their expertise in Scratch, Alice, or Kodu. That absolutely should not matter to CS1 instructors.  But it does.

January 24, 2011 at 7:38 am 30 comments

Lisp and Smalltalk are dead: It’s C all the way down.

Georgia Tech’s College of Computing is now considering a proposal to remove Smalltalk from the required curriculum in favor of C++.  When I got here in 1993, we taught Pascal (mostly) and had required courses in C, Lisp, and Smalltalk.  The faculty explicitly valued that students see more than one school of programming thought. I took over the Smalltalk-using course from John Schilling and Richard LeBlanc, and moved it from ObjectWorks to Squeak. When we moved to semesters in 1999, Lisp got dropped, and we’d moved from Pascal to Java as our main teaching language.  When we drop Smalltalk (now using VisualWorks), we will have a first semester in Python, and the rest of the required curriculum will be Java, C, C++, and C#.  We will explicitly tell students “C and C-like languages are all that there is.”

Why drop Smalltalk?  Students and teachers view it as “a dead language, not worth learning.”  It is the case that there are concepts in Objects and Design (the name of the course) which can most easily be discussed in C++. C++ is wildly popular in industry, so it’s not surprising that some language-specific techniques have developed, techniques that our students should probably know.

It’s reasonable to teach a course on object-oriented analysis, design, and programming in C++ rather than Smalltalk.  I’m more disappointed that we will have a curriculum that is all about C.

Richard Gabriel has been thinking a lot about the C-ness of our discipline.  If you have not read Richard Gabriel’s articles on “Worse is Better,” I recommend them. Dan Weinreb has a nice overview, and there’s a list of all the various pieces in Gabriel’s debate (some of which was with himself!). Gabriel has been trying to understand why Lisp, despite its many measurable benefits over C (e.g., Lisp programmers are more productive and generate fewer bugs, Lisp environments are amazingly powerful, Lisp code is small and runs fast), has so clearly lost the battle over hearts and minds.

Gabriel contrasts two design philosophies, the MIT/Stanford philosophy (which he calls “the right thing“) and the “New Jersey” C/UNIX philosophy (which he calls “worse is better”).  In short form, the MIT/Stanford philosophy (which he associates with Lisp, and which I also associate with Smalltalk) is that correctness and consistency are the most important design quality. In Lisp and Smalltalk, we have S-expressions and objects consistently.  The C/UNIX philosophy places simplicity in interface and implementation as the most important design quality.

Python is a mishmash of the two design philosophies.  Yes, you get lambda and map/reduce and objects and classes.  But you lose the consistency and syntactic flexibility of Lisp and Smalltalk.  What’s interesting is that Python, being the least C-like of the popular languages in computing education today, is mostly seen as a language for the NON-computing major.  It’s like faculty are saying, “Oh sure, those simpler and more conceptual ways of programming are fine for people who won’t be real programmers.  For our students, it’s C all the way.”

I don’t dispute that Unix/C philosophy has won the marketplace. I worry about only teaching that to our students. I think it’s important for Computing  majors to understand Gabriel’s debate, to understand what’s valuable about Lisp, Smalltalk, APL, and other high-power, lots-done-in-few-lines-of-code, flexible languages and environments.  We want our students to be thought leaders, to think about possibilities that aren’t currently in vogue in the marketplace. They should know about lessons of history, to avoid repeating mistakes and to resurrect old ideas when technology and opportunities fit.

The political forces are lined up to make the Georgia Tech change likely.  In comparison with the departments that I had contact with this summer, we’re late.  The C-only train has left the station.  Few departments teach surveys of programming languages anymore, and I don’t know of any department that teaches a required course in history of computing. I worry about what this means for our discipline.  Are we really going to tell students that the peak of human expressibility for computation was in 1973?  That all programming language research from here on out is wasted energy?  That simplicity is all that we can ever hope for, and correctness and consistency just aren’t worth working on? Are we forever stuck with 30+ year old ideas and don’t even teach that anything else is possible?

August 14, 2009 at 12:09 pm 64 comments


Enter your email address to follow this blog and receive notifications of new posts by email.

Join 9,021 other followers

Feeds

Recent Posts

Blog Stats

  • 1,977,189 hits
December 2021
M T W T F S S
 12345
6789101112
13141516171819
20212223242526
2728293031  

CS Teaching Tips