Can we simplify the set of primitive pictures?

[cdsmith]

I don't know an easy way to do this, but @marcianx pointed out that if we're looking at reducing the number of colors in the name of avoiding cognitive load and memorization early in the class, it's actually the primitive pictures that play a bigger role in that. We have:

• circle
• thickCIrcle
• solidCircle
• rectangle
• thickRectangle
• solidRectangle
• lettering
• styledLettering (I don't teach this one)
• polygon
• thickPolygon
• solidPolygon
• polyline
• thickPolyline
• closedCurve
• thickClosedCurve
• solidClosedCurve
• curve
• thickCurve
• arc
• thickArc
• sector
• blank
• codeWorldLogo
• coordinatePlane

They do follow a lot of common patterns (plain/thick/solid variants, and polygon/polyline/closedCurve/curve), but it's still a huge list of vocab!

• Some primitives are redundant. For instance, rectangles can be defined as polygons, and circles as arcs. But those are cases where students need to practice with simple shapes before introducing the more general form.
• We could avoid the combinatorial explosion by following the Elm GraphicsSVG route, where Stencil and Shape and Collage are different types. But this just adds its own form of complexity.
• We could just eliminate primitives that are rarely used. I suppose the candidates would be styledLettering, arc and thickArc and sector, and all the curve functions, for a savings of 9 primitives. But these were each added for a reason, either because students want them, or because they exercise math skills that are part of the goal!
• As one stretch idea, we could eliminate the thick variants of shapes, and instead have all shapes drawn by a line of fixed thickness, which could then be scaled up or down to get a thicker line. This makes some simple pictures much harder to draw, but it removes the most complex primitives -- and also helps to fix some thorny issues with #649 by just defining blank as the right picture when scaling by 0.

I strongly suspect the right answer here is to do nothing. Perhaps we could postpone learning the polygon and arc families of functions until later in the curriculum sequence if the choices are really so overwhelming, but no need to take them away.

But I wanted to document the thought given to the question.

[alphalambda]

I think it may be productive to distinguish between the base library and the curriculum library. In my opinion, the base library should provide as many primitives as necessary to make anything possible, but no more than that.

On the other hand, the curriculum library (or "a curriculum library") could restrict those options to fit a particular curriculum, or it could add additional functionality built on the base library, as I do with the Extras modules.

Even though this is not exactly the topic of this thread, it is strongly related.

In this particular case, the base library should provide ways to create all the shapes in either solid, outlined or full version.

Then, a curriculum library could restrict the shapes available to just a few of those. For example, polygon and rectangle are redundant for the base library, since polygon would be enough. However, rectangle makes sense in a curriculum library, as square would too.

Another example: styledLettering and all kinds of crazy colors are heavily used by high school students, who really want to customize the look of their designs. Even though we only teach the basic pre-defined colors at the beginning, students skip ahead and figure out how to work with RGB colors right away. However, middle school students may be more amenable to using just a few colors and the standard font. So, a high school curriculum library may not need a rich set of predefined colors, while a middle school curriculum library may offer just pre-defined colors and the color modifiers (light,dark,mixed,etc.)

On Tue, Nov 27, 2018 at 10:14:35PM -0800, Chris Smith wrote:

I don't know an easy way to do this, but @marcianx pointed out that if we're looking at reducing the number of colors in the name of avoiding cognitive load and memorization early in the class, it's actually the primitive pictures that play a bigger role in that. We have:

• circle
• thickCIrcle
• solidCircle
• rectangle
• thickRectangle
• solidRectangle
• lettering
• styledLettering (I don't teach this one)
• polygon
• thickPolygon
• solidPolygon
• polyline
• thickPolyline
• closedCurve
• thickClosedCurve
• solidClosedCurve
• curve
• thickCurve
• arc
• thickArc
• sector
• blank
• codeWorldLogo
• coordinatePlane

They do follow a lot of common patterns (plain/thick/solid variants, and polygon/polyline/closedCurve/curve), but it's still a huge list of vocab!

• Some primitives are redundant. For instance, rectangles can be defined as polygons, and circles as arcs. But those are cases where students need to practice with simple shapes before introducing the more general form.
• We could avoid the combinatorial explosion by following the Elm GraphicsSVG route, where Stencil and Shape and Collage are different types. But this just adds its own form of complexity.
• We could just eliminate primitives that are rarely used. I suppose the candidates would be styledLettering, arc and thickArc and sector, and all the curve functions, for a savings of 9 primitives. But these were each added for a reason, either because students want them, or because they exercise math skills that are part of the goal!
• As one stretch idea, we could eliminate the thick variants of shapes, and instead have all shapes drawn by a line of fixed thickness, which could then be scaled up or down to get a thicker line. This makes some simple pictures much harder to draw, but it removes the most complex primitives -- and also helps to fix some thorny issues with #649 by just defining blank as the right picture when scaling by 0.

I strongly suspect the right answer here is to do nothing. Perhaps we could postpone learning the polygon and arc families of functions until later in the curriculum sequence if the choices are really so overwhelming, but no need to take them away.

But I wanted to document the thought given to the question.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/google/codeworld/issues/783

[cdsmith]

"Make anything possible" is quite a high bar! Off the top of my head, some of the things we can't do that are possible in other libraries include: dotted line variants of shapes, gradients, fill patterns, and constructive area geometry (#28).

Point taken, though. I guess I just mean that there's a kind of bias involved in not wanting to lose any capabilities, when we have for years been coping with limitations in the name of simplicity. The question is whether we've made the right choices. I can't think of a much more compelling design trade-off yet, but I explicitly want to avoid missing chances because of a never-give-an-inch attitude toward the current feature set.

[alphalambda]

It seems to me that the trade-off between limitations and simplicity is not absolute, but it depends on variables such as the grade-level of the target population.

I guess what I wish for is a mechanism to be able to set the trade-off level within some range [maxSimplicity .. maxCapabilities]

On Wed, Nov 28, 2018 at 06:45:25AM -0800, Chris Smith wrote:

"Make anything possible" is quite a high bar! Off the top of my head, some of the things we can't do that are possible in other libraries include: dotted line variants of shapes, gradients, or fill patterns, or some of the tricks you can play with constructive area geometry (see #28).

Point taken, though. I guess I just mean that there's a kind of bias involved in not wanting to lose any capabilities, when we have for years been coping with limitations in the name of simplicity. The question is whether we've made the right choices. I can't think of a much more compelling design trade-off yet, but I explicitly want to avoid missing chances because of a never-give-an-inch attitude toward the current feature set.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/google/codeworld/issues/783#issuecomment-442471467

[cdsmith]

I doubt there's a continuous version of that trade-off that can be made automatically. There are substantial design differences between the various choices. But new modes with different libraries is worth considering. I think it's independent of this bug, and related to #138.

Feel free to flesh out a proposal there. As I see it, the major challenges are:

• Avoiding too much additional complexity in the UI. It's important to avoid losing too much class time to students setting up the right configuration for their projects.
• Coming up with a communication story. It's already confusing that "CodeWorld" is a name for both the environment, and the simplified language variant. We probably would end up devising new names for the different supported language configurations.
• Abstracting over all the differences. There are many places where haskell-mode and codeworld-mode differ: compiler flags, libraries, editor configuration, error message handling, debugger logic, etc. We'd want some kind of module surface for a configuration to handle all of these.
• Namespacing and ownership of configurations. Should configurations be owned by the CodeWorld project, which implies a high barrier to entry for adding a new one? Or should they be owned by non-privileged users, which implies some kind of name registry, or unique ids, or something, and more complex processes for teachers to share them with students?

In that post-configs world, one could see this bug as being just about whatever configuration currently captures the existing codeworld-mode API.

[cdsmith]

I still don't see an easy way to simplify the set of primitives that's better for most use cases. I doubt one exists. So I'll defer to #138 instead, and close this issue.