Posts tagged ‘programming languages’

We can build new programming languages that people will teach, learn, and use: Scratch 3.0 in August

When I come out with blog posts saying that we need new programming languages (like this one), I regularly get a bunch of skepticism.  People will only use industry-approved languages, says one argument.  We need to teach the languages that exist, says another.

Then I just reply, “Scratch.”  It’s real programming, it’s popular, and it’s taught around the world.  We ought to study how Scratch succeeded.  One key insight: Don’t beat your head against the traditional CS1 teachers.  There’s a lot more people to teach, and not everyone has to become a software developer.

A new version of Scratch is coming this August!

Source: 3 Things To Know About Scratch 3.0 – The Scratch Team Blog – Medium

June 25, 2018 at 7:00 am 20 comments

Is there a “hype cycle” for educational programming languages?

As a longtime Smalltalk-er, I loved this piece: “The 50-year Gartner Hype Cycle for Smalltalk

Interesting how the hype cycle applies to Smalltalk:

  • Technology Trigger — the hype began with the famous 1981 BYTE cover and continued throughout the 1980s.
  • Peak of Inflated Expectations — in the 1990s, Smalltalk became the biggest OOP language after C++ and even IBM chose it as the centrepiece of their VisualAge enterprise initiative to replace COBOL.
  • Trough of Disillusionment — Java derailed Smalltalk by being: 1) free; and 2) Internet-ready. Free Squeak (1996) and Seaside web framework (2002) were not enough to save it.
  • Slope of Enlightenment — Pharo was released in 2008 and became the future of Smalltalk, thanks to its remarkable pace of evolution. We are still in this phase, which requires continuing and sustained advocacy.
  • Plateau of Productivity — we are waiting for this phase, perhaps in the next decade. I am sanguine.

Educational programming languages (or maybe just programming languages’ use in education) don’t seem to follow this curve at all.  Does a programming language ever “come back” once it has left classrooms?  Logo? Pascal?  Even if there’s a “Trough of Disillusionment” (e.g., when we realized just how hard C++ and Java are), we still see longterm use. Even if we later realize how good something was (e.g., Logo for integration into curriculum), it doesn’t come back.

I wonder what the similar curve looks like for programming languages in education.

May 18, 2018 at 7:00 am 24 comments

New programming languages are important to develop as we improve our knowledge of how students learn computing

I was at a workshop at Google a couple weeks ago where someone asked me, “Do you still think that there’s a place for developing new programming languages in computing education?” I said, “ABSOLUTELY!”.

We know little about how people learn programming, and developing new programming languages is important for improving usability, learnability, and productivity of programmers (professional, novice, end-user, casual, or conversational). The interplay between design of programming languages and research into how people learn programming languages is a hot and important research topic. (See, for example, the recent Dagstuhl seminar on empirical data for programming language design.)

My Blog@CACM post for this month (see link here) is based on the cover story for the March Communications of the ACM (CACM), on “A Programmable Programming Language.” The (interesting and recommended) article is on building problem-specific programming languages. My post was about the educational questions raised by these languages. Would they be easier or harder to learn if they’re problem-specific? Will novices be willing to put in the effort to learn a programming language that is specific to a problem? Do problem-specific languages make it harder or easier to find (or train) programmers to work on old software (built in these problem-specific languages)? If a programmer learns a problem-specific programming language created at Company X, then leaves for Company Y and creates a similar problem-specific programming language, was intellectual property stolen?

Barbara Ericson’s defense was March 12 (as mentioned here). It was very successful — not only did she pass, but all of her committee signed off on the same day. She’s Dr. Ericson!

Alan Kay was on her committee and asked some insightful questions about her work with Parsons problems. In a Parson problem, students are ordering lines of code into a correct solution. Barb did her research using Python, and she’s also done work with Parsons problems in Java. These are pretty similar languages in terms of notional machines.

What’s the influence of the programming language on student success with Parsons problems? What if the underlying notional machine was simpler to understand? Would students find it easier to sequence a program? In general, we explore non-imperative programming paradigms so rarely in computing education research. We change modality (e.g., Scratch), but not the underlying computational model. The work with Racket is a rare example. Alan mentioned HyperCard in his comments, which was explicitly designed to be easy to learn. Would HyperCard programs be easier for students to order correctly?

I hope that we continue to invent new programming languages and explore the educational implications of them. There’s a big space of possible designs, and we have only started evaluating them empirically.

March 26, 2018 at 7:00 am 1 comment

Jean Sammet passes away at age 89

Jean Sammet passed away on May 21, 2017 at the age of 88. (Thanks to John Impagliazzo for passing on word on the SIGCSE-members list.)  Valerie Barr, who has been mentioned several times in this blog, was just named the first Jean E. Sammet chair of computer science at Mount Holyoke.  I never met Jean, but knew her from her work on the history of programming languages which are among the most fun CS books I own.

Sammet

GILLIAN: I remember my high school math teacher saying that an actuary was a stable, high-paying job. Did you view it that way?

JEAN: No. I was looking in The New York Times for jobs for women—when I tell younger people that the want ads were once separated by gender, they’re shocked—and actuary was one of the few listed that wasn’t housekeeping or nursing, so I went.Sammet found her way to Sperry. “Everything from there, for quite a while, was self-learned,” she says. “There were no books, courses, or conferences that I was aware of.” For her next move she applied to be an engineer at Sylvania Electric Products—though the job was again listed for men.

Source: Gillian Jacobs Interviews Computer Programmer Jean E. Sammet | Glamour

May 26, 2017 at 7:00 am 1 comment

Stanford CS department updates introductory courses: Java is Gone

See update here: Stanford is NOT switching from Java to JavaScript: I was mistaken

Stanford has decided to move away from Java in their intro courses. Surprisingly, they have decided to move to JavaScript.  Philip Guo showed that most top CS departments are moving to Python.  The Stanford Daily article linked below doesn’t address any other languages considered.

The SIGCSE-Members list recently polled all of their members to talk about what they’re currently teaching.  The final spreadsheet of results is here.  Python appears 60 times, C++ 54 times, Java 84 times, and JavaScript 28 times.  I was surprised to see how common C++ is, and if Java is dying (or “showing its age,” as Eric Roberts is quoted below), it’s going out as the reigning champ.

When Java came out in 1995, the computer science faculty was excited to transition to the new language. Roberts wrote the textbooks, worked with other faculty members to restructure the course and assignments and introduced Java at Stanford in 2002. “Java had stabilized,” Roberts said. “It was clear that many universities were going in that direction. It’s 2017 now, and Java is showing its age.” According to Roberts, Java was intended early on as “the language of the Internet”. But now, more than a decade after the transition to Java, Javascript has taken its place as a web language.

Source: CS department updates introductory courses | Stanford Daily

ADDENDUM: As you see from Nick Parlante’s comment below, the JavaScript version is only an experiment.  From people I’ve talked to at Stanford, and from how I read the article quoted above (“more than a decade after the transition to Java, Javascript has taken its place”), I believe that Stanford is ending Java in CS106.  I’m leaving the title as-is for now. I’ve offered to Marty Stepp that if CS106 is still predominantly Java in one year, I will post a new blog post admitting that I was wrong.  Someone remind me in April 2018, please.

April 21, 2017 at 7:09 am 36 comments

Scientists Looking at Programmers’ Brains see more Language than Mathematics: The Neuroscience of Programming

I’m not convinced that our ability to image brains is actually telling us much about cognition yet.  I did find this result surprising, that our understanding of programming languages seems more linguistic than mathematical

Scientists are finding that there may be a deeper connection between programming languages and other languages then previously thought. Brain-imaging techniques, such as fMRI allow scientists to compare and contrast different cognitive tasks by analyzing differences in brain locations that are activated by the tasks. For people that are fluent in a second language, studies have shown distinct developmental differences in language processing regions of the brain. A new study provides new evidence that programmers are using language regions of the brain when understanding code and found little activation in other regions of the brain devoted to mathematical thinking.

Source: Scientists Begin Looking at Programmers’ Brains: The Neuroscience of Programming | Huffington Post

January 23, 2017 at 7:00 am 12 comments

Which is better for novices, C++ lambdas or iterators? New research from Andreas Stefik’s group

I needed to look up a paper on Andreas Stefik’s page the other day and came across this fascinating new paper from him:

Phillip Merlin Uesbeck, Andreas Stefik, Stefan Hanenberg, Jan Pedersen, and Patrick Daleiden. 2016. An empirical study on the impact of C++ lambdas and programmer experience. In Proceedings of the 38th International Conference on Software Engineering (ICSE ’16). ACM, New York, NY, USA, 760-771.

(You can download it for free from his publications page: http://web.cs.unlv.edu/stefika/research.html.)

Since this is Stefik, he carefully describes what his paper is saying and what it’s not saying.  For example, he and his students measured C++ lambdas vs iterators — not a particularly pleasant syntax to work with.

The results are quite interesting.  This graph is what caught my eye.  For professionals, iteration and lambdas work just about the same.  For novices, iterators blows lambdas away.  Lambda-using students took more time to complete tasks and received more compiler errors (though that might be a good thing, in terms of using the compiler to find and correct bugs).  Most interesting was how the differences disappeared with experience. Quoting from the abstract:

Finally, experienced users were more likely to complete tasks, with or without lambdas, and could do so more quickly, with experience as a factor explaining 45.7% of the variance in our sample in regard to completion time.

This is an example of my “Test, don’t trust” principle (see earlier blog post).  I was looking up Stefik’s paper because I received an email from someone who simply claimed, “And I’m using functional notation because it’s much easier for novices than procedural or object-oriented.”  That may be true, but it ought to be tested.

Cursor_and_p760-uesbeck_pdf

July 29, 2016 at 7:42 am 4 comments

Older Posts


Recent Posts

August 2018
M T W T F S S
« Jun    
 12345
6789101112
13141516171819
20212223242526
2728293031  

Feeds

Blog Stats

  • 1,538,499 hits

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

Join 5,301 other followers

CS Teaching Tips