computer science education

8月 172016
 

My computer geek colleagues are boasting about their humble beginnings by sharing lists of their first seven programming languages. You can find these under the hashtag #FirstSevenLanguages.

From what I've seen of these lists, the programming languages that appear are very much a function of age -- not the age of the language, but of the person sharing the list. It's also a function of industry. For people of a certain age who first worked at a bank, COBOL appears early on the list. Did you work in the defense industry? Ada is probably on your list.

Of course, the SAS programming language features prominently among my colleagues. I have argued that listing SAS is a bit of a cheat, since SAS actually comprises several different programming languages: DATA step, SQL, DS2, SAS macro, IML, GTL, SCL, and more. SAS also contains hooks into other languages like Lua and Groovy. Some SAS analytical procedures are programming languages in their own right, like PROC OPTMODEL.

I have several friends who have built their entire careers on SAS programming. There is little risk of boredom, as the SAS language evolves with each release and is used in virtually every industry. It's like a huge mansion of a programming language -- we all have our favorite rooms where we spend most of our time, but there are always new additions to discover and explore.

I've said that I don't identify myself as a programmer, even though programming is an activity that occupies lots of my time. Here's my #FirstSevenLanguages list. It's not exactly in chronological order, and like other folks I'm cheating by grouping some languages together into eras.

  • Extended basic on the TI99/4A (high school, in my parent's basement)
  • Turbo Pascal and Turbo C and Assembly (school and internships)
  • REXX and Perl (two different jobs, but used both to automate tedious tasks)
  • C++ (our first versions of SAS Enterprise Guide)
  • Java (various projects)
  • C# and .NET (SAS Enterprise Guide since the mid 2000s)
  • SAS - (first learned in a SAS education class in 1993, and still learning it)

Unlike some of my more distinguished colleagues, there are no "punch cards" languages on my list. Nostalgia is sometimes fun, but I don't believe anyone who says that the era of punch cards, 16K RAM, and 8-inch floppy disks was "the good old days." Instead, I prefer to look forward to my #NextSevenLanguages. In my current role with SAS Support Communities, I get to dabble in JavaScript, FreeMarker, and Python. But I use SAS every day and for so many tasks, it remains high on my list of languages to learn!

tags: computer science education, csedweek, stem

The post What were your #FirstSevenLanguages? appeared first on The SAS Dummy.

7月 082011
 
The recent issue of InformationWeek features a Q&A session with Ken Thompson, one of the creators of the Unix operating system. (He collaborated with Dennis Ritchie, of C language fame. Since much of SAS is written in C, I daresay there are a few copies of K&R around here.)

One of the questions hit on the topic of code reviews:

Interviewer: Was there any concept of looking at each other's code or doing code reviews?

Thompson: [Shaking head] We were all pretty good coders.

The implication: only bad coders need code reviews.

This is an outdated attitude towards software development. Unfortunately, I've encountered this attitude among some software professionals that I've worked with (outside of SAS as well as within). Why do some programmers (especially those from the "good ol' days") place little value on code reviews?

Perhaps peer code reviews were less important 30 years ago. The constraints around running code were much tighter. There were fewer layers in the stack where bugs could lurk. Memory was scarce, instruction sets were limited. Computer applications were like my 1973 AMC Gremlin: fewer moving parts, so it was easier to see which parts weren't working correctly and predict when they would fail. (Most often, it was the carburetor -- another outmoded concept.)

Also, the discipline of programming was newer back then. Perhaps there was less variability among the approaches you could use to solve a problem with code. If you had the skills to code the solution, maybe your solution would not differ much from that of any other similarly skilled colleague.

Well, those days are gone. Now more than ever, we need code reviews to be a formal part of how we work as SAS professionals (and as software professionals in general). Mark Chu-Carroll spells out many of the reasons in his blog post, Things Everyone Should Do: Code Review. As Mark says, it's not about the problems that a reviewer will catch; it's more about the programmer who prepares to have his/her work reviewed. Knowing that you have to explain this to another person, that someone else will be looking at your work...that can help to keep you on your toes.

In addition to reasons that Mark cites, those of us who work with SAS have a special motivation: we need to pass on the knowledge of a rich legacy code base to our younger workers. And because the SAS language expands with each new release, old-time SAS programmers need exposure to people who can apply new techniques to old problems. Code reviews are one way to help make that happen: improve quality, ensure continuity, and keep it fresh. Who can argue against that?

12月 112010
 
I helped to write a quiz for the Computer Science Education Week promotions that were featured on our company intranet. Do you fancy yourself as a Comp-Sci aficionado? Let's see how you do with these.

1. Which achievement is Charles Babbage most famous for?

  1. Establishing software retail shops in shopping malls across America
  2. Inventing a strategic card game that involves using pegs to keep score
  3. As one of the "fathers" of the programmable computer
  4. Earning an all-time high score while playing Mafia Wars

2. Early computer programs and data were originally recorded on what storage device?

  1. Iomega "Zip" drives
  2. 8" floppy disks
  3. Punched cards
  4. 8-track cassette tapes

3. Which of the following is NOT a computer programming language?

  1. Lisp
  2. Python
  3. Ruby
  4. Simba
  5. SAS

4. Within a computer program, a function that can invoke itself again as part of doing its work is known as:

  1. recalcitrant
  2. recursive
  3. redundant
  4. repulsive
  5. a stack overflow exception

5. In a computer program, a variable that simply holds the memory address of another variable or data structure is called:

  1. a memory leak
  2. a pointer variable
  3. a linked list
  4. an address box

Answers:

1: (c). Charles Babbage is known as a pioneer in the concept of a programmable computer, even though he lived long before the technology to build modern computers was invented. Source: Wikipedia (http://en.wikipedia.org/wiki/Charles_Babbage)

2: (c). Punched cards have been around since the earliest "computing machines". Beginning in the 1960s, magnetic tape and other storage devices began to replace punched cards for data storage. Source: Wikipedia (http://en.wikipedia.org/wiki/Punched_card)

3: (d). At the time of this writing, there is no computer programming language named "Simba"…but it's probably just a matter of time. The most popular active programming languages are tracked at the TIOBE Programming Community Index (http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html). The SAS programming language is currently at number 18 on the index.

4: (b): "Recursive" is the most correct answer here, but unless used with extreme care, any of the other answers might be the result.

5: (b): A pointer variable (or pointer, for short). Pointers are common in some programming languages, such as C and C++, where they are usually essential for memory-efficient operations. Those who work with higher-level languages such as Java, C#, or even SAS don't encounter pointers nearly as often (the lucky stiffs).

12月 072010
 
Computer science is more than the pursuit of "let's see what we can make this computer do." If that's your only goal, then you might make a fine computer geek, but a lousy computer scientist. In her blog post for Computer Science Education Week, Caroline McCullen reminds us that computer science is the "T" in STEM, and isn't an isolated pursuit, but an integral part of preparing today's students for the modern and future job market.

Back in the day, one of the required courses for all computer science majors at my alma mater (SUNY Potsdam) was Data Communications. The culminating project for that course, when I took it, was to link four PCs in a data comm network via the parallel port.

This was a very geeky project. We used soldering irons to modify cables; we implemented software layers in assembly code as well as C code, and we had to work together as a team. All of these are important skills for real world projects. But as the end result, we had a small network of four PCs linked by parallel port -- something that really had no practical use. (Remember, the parallel port was used mainly for communicating with printer devices. Your computer sends information to the printer, but those printers sent relatively little information back, aside from a BUSY or ERROR signal.)

That's not what computer science is about today. Within today's computer science departments, students work with their peers in other academic departments (and industry) to use their skills to solve problems in the domains of other disciplines. That includes math, economics, statistics, and physics -- the disciplines with obvious need for number crunching and equation solving. But it also includes the "humanities" subjects, such as English, music, and education. Just as important, the practitioners of these other disciplines learn that technology can help improve their work, and not just distract from it.

We still need the geeky projects like my data comm experience to help build the basic skills, so that as computer scientists we have that background knowledge to bring to the table. It's like how a medical student has to spend a certain amount of time with cadavers, not to become really good at working with dead people (apologies to Quincy), but to build up the knowledge needed to bring help to the living patients who can benefit from it.

That brings me to this true anecdote: A couple of weeks ago I had a phone conversation with a SAS customer who works for a major health insurance provider. He uses SAS to collect and report on data about surgical outcomes. We had a great conversation about SAS libnames, data sets, and many other geeky aspects of SAS programming. He spoke with such fluency about programming concepts that I was surprised when I later saw his credentials in his e-mail signature: he's a registered nurse.

12月 012010
 
Author note: I'm "replaying" this post in honor of Computer Science Education Week. It originally appeared here over 3 years ago.

Today was "career day" in my daughter's 3rd grade classroom. A few privileged parents were invited to attend and answer questions about their professions, press-conference style.

Among those on a panel of nine parents, the panelists that saw the most action included the Dog Trainer, the Duke Life Flight Nurse, and...the SAS Software Manager.

If it surprises you that the software manager profession is very interesting to 9-year-olds, welcome to the club. Personally, I wanted to hear more from the CFO of Carquest and the car dealership owner who specializes in Hummers and Porsches (and who has an EVO on his lot -- that revelation prompted excited gasps from many of the boys).

Still, I was honored to answer the students' many questions. Here is a sampling of their questions and my answers.
Continue reading "What's my line? (CSEdWeek edition)"

11月 302010
 
Next week we'll be celebrating Computer Science Education Week. SAS is a partner in this event, which makes complete sense because we have a vested interest in creating more computer scientists. After all, SAS does employ a lot of them.

When I was enrolled in a computer science program (sometime after punched cards but well before USB drives), the program was notorious for its attrition rate. Hundreds of incoming freshmen would declare Computer Science as their major, only to have most of them drop out in the second or third year. I don't think it was due to the difficulty (although of course it was a challenging program); I think that the work of designing and writing computer programs was different than many people expected.

The idea of teaching a computer to do work for you is compelling, but it does require a different mindset. Or it did, back then. Now we have higher-level languages that allow to you approach a business or science problem without having to think completely like the computer.

Programming languages and computer architecture change at a faster rate than the tools associated with most other professions. Therefore, a successful computer science education will prepare you with not only solid problem solving skills, but will instill the ability to learn new tools and approaches that allow you to practice those skills in a changing world.

Why Computer Science? (Because STEM is cool! Watch the video...) According to the CSEdWeek.org folks, computer science education is essential to:

  • Expose students to critical thinking and problem solving.
  • Instill understanding of computational thinking for success in the digital age.
  • Train students for computing careers that are exciting, plentiful and financially rewarding.
  • Prepare students to tackle the world’s most challenging problems.

Learn more at www.CSEdWeek.org.