Class 26: Reflections on JavaScript

Held Tuesday, March 7, 2000

Overview

Today we reflect on what we've learned about JavaScript over the past few weeks. What are the strengths and weaknesses of the design of JavaScript?

Question 26 for today's class: What do you consider significant implications of being able to copy JavaScript programs from the Web?

Question 27 for Wednesday's class: Describe a game that we might be able to write using the JavaScript we've figured out to date.

Notes

• Don't forget, there is no class on Friday. I'll be at the SIGCSE Symposium on Computer Science Education.
• A few of you have asked about the stories (since I haven't given you samples). I'd still like you to write stories, but we'll wait until after break (when I'll have samples ready).
  • If I don't have samples ready after break, we'll drop the assignment.
• Tomorrow, we'll look at JavaScript from a different perspective: the interaction of non-programmers (the students in this class) with programmers (Sarah and SamR). In particular, we'll try to design (and maybe even build) a game.
  • Your question for tomorrow involves thinking about how the techniques we've learned so far might be used in a game.
• For next Monday, read Forester & Morrison, Chapter 5

Contents

• JavaScript Techniques
• Background: Intellectual Property
• Copying JavaScript
• JavaScript as Construct

Summary

• What we've learned how to do with JavaScript
• Open Source, revisited
• Implications of JavaScript

JavaScript Techniques

• On Wednesday, we'll look at how ``professional'' programmers might use the JavaScript we know to build an interesting application.
• Your goal is to brainstorm interesting things we can do with the tools at our disposal. For fun, I thought we might focus on games.
• I also thought it might help if we went over some of the things that we know how to do.
• Here are some that I've come up with. Yours may vary:
  • We know how to change images in the document.
  • We know how to change the document.
  • We know how to make popup menus.
  • We know how to make changes happen with some regularity.
  • We know how to replace the contents of the page.
  • We know how to do different things depending on a condition.

Background: Intellectual Property

• Before we go on to our discussion of JavaScript, I thought it might be helpful to consider a little bit of intellectual property law in the U.S.
  • What do you know about intellectual property law?
  • What kinds of intellectual property are there?
  • Why did congress first create intellectual property law (and the associated offices)?
• Because we're in academia, we have a second set of ``laws'' to consider: those of citation.
  • How do rules of citation differ?

Copying JavaScript

• You identified many reasons that it is good (and bad) to be able to copy JavaScript. Let's consider some of those in a bit more depth.
• Obviously, many of these questions harken back to the open source discussion, but it would not hurt to consider those issues again.
• Because you can read the JavaScript on pages, you can (with lots of effort) eventually understand how they work.
  • Should you be allowed to learn how the programs you use work?
• Because you can read the JavaScript on pages, you can copy code from those pages.
  • Should you be able to copy code?
  • When is it reasonable to copy code?
  • Is it more valid to copy techniques than code?
  • How should you cite copied code? Is it different than citing copied text?
  • Do your answers differ if you're talking about HTML rather than JavaScript?
• Because you can copy code, you can ``program'' without really understanding JavaScript or general programming techniques.
  • Should we allow non-programmers to program, or should it remain in the hands of those with proper training?
  • Can such copying encourage others to learn to program?
  • Can anyone learn to write JavaScript with enough work?
• Sam noted that such copying can lead to homogeneity.
  • Why would we want homogeneity?
  • Why might we want to avoid homogeneity?
• Here's another way to look at some of these issues:
  • What alternatives are there to using JavaScript? Could HTML have been designed differently to support most of what we want to do?

JavaScript as Construct

• Like all computer languages, JavaScript is constructed (by the folks at NetScape).
• We should see how well this construct met its design goals, and also consider whether various aspects are truly appropriate.
• For example, Should JavaScript have been designed in such a way that the ``source code'' for a program is available to the user?
  • The source code for Microsoft Windows or Office is not available to the user. For these applications, the source code is translated to a more efficient (and significantly less readable) language.
• There were clearly conflicting design goals for JavaScript:
  • It was intended to be easy for non-programmers. (This encourages a smaller language.)
  • It was intended to be ``natural'' for other programmers. (This encourages a C-like language.)
  • It was intended to support a wide variety of operations. (This leads to a larger language.)
• Another way to consider the question is:
  • Suppose we were designing our own successor to JavaScript. What would we do differently?