Proposal: Remove keywords from the language

[Chris Smith]

Another proposal for discussion.

CodeWorld removes uses of certain features of the Haskell language,
like type classes and monads. But for now, the features remain
intact! For example, the following works:
http://codeworld.info/#PaH7OwKwWRTYyNNVDSK5RdQ==)

I propose to change that, and disable the keywords for these features
(technical details of how I'd do that at
https://github.com/google/codeworld/issues/52).

Why?

1. Students actually try to use some of these keywords. It would be
nice if a student could define a picture called "class" with a bunch
of stick figures sitting at desks.

2. They raise uncomfortable questions. It's one thing to explain that
a reserved word already has another meaning. It's another thing to
explain that the word is reserved, but should never be used.

Which keywords? Well, here's a list of candidates:

Definitely:
- do
- class
- =>
- instance
- default
- deriving
- foreign (though part of me likes the possibility of doing a "foreign
import javascript", it's also unnecessary and breaks the purely
functional programming model)

Maybe, if we want to give up on separate compilation:
- module
- import
- qualified
- as
- hiding

Maybe not, but tempting:
- newtype (use data instead - kids don't need the subtle differences
between newtype and data)
- let, in (use where instead... tempting because short letter
sequences are so easy to stumble on, 'in' is an extremely common word
to accidentally use, and having two ways to do the same thing is
awkward anyway)
- Related idea: automatically replace single quotes with double quotes
(and escape the double quotes inside). We don't export Char anyway,
instead preferring a single Text type.

[Luke Palmer]

On Thu, Aug 14, 2014 at 4:37 PM, Chris Smith <cds...@gmail.com> wrote:

Another proposal for discussion.

CodeWorld removes uses of certain features of the Haskell language,
like type classes and monads.  But for now, the features remain
intact!  For example, the following works:
http://codeworld.info/#PaH7OwKwWRTYyNNVDSK5RdQ==)

I propose to change that, and disable the keywords for these features
(technical details of how I'd do that at
https://github.com/google/codeworld/issues/52).

Why?

1. Students actually try to use some of these keywords.  It would be
nice if a student could define a picture called "class" with a bunch
of stick figures sitting at desks.

2. They raise uncomfortable questions.  It's one thing to explain that
a reserved word already has another meaning.  It's another thing to
explain that the word is reserved, but should never be used.

Yes, it would "be nice" to be able to make an identifier called "class".

Often when I learn a new language, I am fascinated by the black magic. Show me the things I'm not supposed to know, let me try the things I'm not supposed to do.  Being told that I can't have an identifier called "class" because it's used for something else doesn't frustrate me, it inspires me. What is it used for? How can I get in on that action?

I have no problem with avoiding advanced features when teaching a class, but *disabling* them because they're too hard for most students was exactly the kind of thing that made me hate math in school. I was reprimanded for using the bits of calculus I was learning to solve a problem in algebra class. I'm not too stupid to know this stuff, you just won't let me!

The same goes for "foreign import javascript". What if a student is learning javascript and wants to go hacking in the guts of her language? Are we going to deny her?  What lesson does that teach?

I think it's important to remember that codeworld is an educational tool, not a perfect little snowflake. Opportunities to dig deeper should be praised, not suppressed.

--
You received this message because you are subscribed to the Google Groups "codeworld-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codeworld-disc...@googlegroups.com.
To post to this group, send email to codeworl...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/codeworld-discuss/CAPq5Pv%2B5YO8iO0okT12mdNOG_%3DH9-SkqD%3D0_tYPziYbMV8Jzdg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Smith]

Luke,

Okay, some good points, and I agree with the philosophy of letting
people play with things and get under the hood if they want to. I
wasn't proposing this as a way to try to protect students from
themselves, or anything like that. That being said, though, there's a
lot of work involved in getting the appropriate things exported so
that many of these features are usable again.

An unfortunate side effect of replacing the Prelude was that I had to
hide "base" as a package
(https://github.com/google/codeworld/blob/master/codeworld-server/src/Main.hs#L220),
so now it's impossible to even import most of the standard library.
So while you can build your own classes and instances, you can't
really use a standard library where they are used at all. Without
access to a lot of the types from base (like Int, for example), I'm
also not sure it's possible to actually use foreign imports: I
deliberately enabled the syntax back when I first picked language
extensions for CodeWorld. But I can't figure out how to use it
without just getting errors.

I'm not opposed to giving people access to advanced tools to play with
and get under the hood. I'm just nervous about leaving them laying
around when they are broken. At this point, the only thing they can
do is get in the way. I'm not sure I buy the argument that the
CodeWorld language is better for having a bunch of broken bits hiding
just out of view.

So it seems like either one way or the other. If there's a way to
offer students a usable way to escape the simplified prelude and play
with full-fledged Haskell, that's fine. Or if we bite down and commit
to treating this as a different language from Haskell, so classes and
instances just don't exist (this proposal), I'm also okay with that
choice, and it's the direction things have been moving anyway. But I
don't like the middle ground we're in, where both options are broken.

> https://groups.google.com/d/msgid/codeworld-discuss/CAH%2BCnvi7qAfyxzA34vfL_g7k8M9Rw-DXksXrB%3DxCR%3DEjRGB2FA%40mail.gmail.com.

[James Crook]

Sharing here some experience over a period of about 2 years with using Scratch with 9 to 14 year olds in an 'after school club' setting.

The sandboxed environment has huge initial benefit.  It's optimised for the children being able to get results and have fun.  The environment has many details that clearly come from extensive experience, designed to save children from getting stuck.  It's great, and I really like this aspect.

The sandboxed environment has a very significant long term downside.  The children do not want to move from it to 'more professional' development environments.  When they move out of it, they find they are back at square one, unable to do things like make simple games, that they previously could do easily.  Moreover the amount new they have to learn to get started again is not easily picked up in a couple of hours.  That de-motivates them from persevering with the other environments, and as a result they tend to go back to Scratch.  

I think it is very much a decision of personal philosophy and time available for development, as to in what ways sandbox and what transitions you offer from the sandbox.  My own thinking is that for CodeWorld letting the children easily see 'more Haskell' isn't where the value lies - any more than letting children see the 'squeak'/'actionscript' behind Scratch would be a good thing for Scratch.  More relevant is what skills the example projects build up, and how transferable those skills are.  So, I think your path of optimising for cleanness / ease of learning is good, and not providing a broken escape hatch is good.

--James.

To view this discussion on the web visit https://groups.google.com/d/msgid/codeworld-discuss/CAPq5PvLKGg-w%2BMk5-RUfeQHzNkjVj54w5SNNCULX_HPKXttaeA%40mail.gmail.com.

[Chris Smith]

James Crook <james....@gmail.com> wrote:
> The sandboxed environment has a very significant long term downside. The
> children do not want to move from it to 'more professional' development
> environments. When they move out of it, they find they are back at square
> one, unable to do things like make simple games, that they previously could
> do easily. Moreover the amount new they have to learn to get started again
> is not easily picked up in a couple of hours. That de-motivates them from
> persevering with the other environments, and as a result they tend to go
> back to Scratch.

Thanks for this point!

My knee-jerk (and mostly wrong) response is that CodeWorld is not
supposed to be an introduction to a computer programming career. And
this is true... but, at the same time, it's deeply unsatisfying to
think that students who choose to explore computer programming further
would have difficulty doing so. Last time around, my answer
(unintentionally!) was to make the web site perform very poorly, and
ultimately stop working a few months after the class was over. That
certainly motivated students to move on to more full-fledged
programming tools. Let's not do that again. :)

One interesting question is whether it's important for students to
"move on" to full-fledged Haskell, versus other languages. And that
comes back to whether we think of CodeWorld as a Haskell programming
environment, versus being its own language. Three years ago, I
explicitly set out to teach Haskell. I called my class "Haskell for
Kids", and told the kids they were learning Haskell, and how I think
it's a great language to learn. Reflecting back on that, my position
has evolved. Not that I don't like Haskell! But that I find myself
more and more willing to tweak the language to meet the goal of
"programming using algebra", which is really the central point here.
I replaced the Prelude to kill type classes. I uncurried the standard
library. Oddly, for me, the real point of accepting that I'm teaching
a different language came when I changed all the examples and
tutorials to eliminate the space after function names, going from "f
(x,y)" to just "f(x,y)". Small things...

I understand Luke's point is a little broader than this, though. More
than being an argument about whether CodeWorld should steer students
toward full Haskell, it's more that it's better to put kids in an
environment where there are rough edges for them to explore, instead
of having everything neatly packaged and pulling them away from what
they aren't "supposed to see". Part of me agrees with that... but
again, I have a hard time concluding that it's therefore better to
give them a language that's just broken in some ways.

--
Chris

> https://groups.google.com/d/msgid/codeworld-discuss/CAMe%3D4itw09iVSWGXWnnbF_d2dCGeBpXNCHWdafv2ECHThfqJww%40mail.gmail.com.

[Luke Palmer]

On Fri, Aug 15, 2014 at 9:13 AM, Chris Smith <cds...@gmail.com> wrote:

I understand Luke's point is a little broader than this, though.  More
than being an argument about whether CodeWorld should steer students
toward full Haskell, it's more that it's better to put kids in an
environment where there are rough edges for them to explore, instead
of having everything neatly packaged and pulling them away from what
they aren't "supposed to see".  Part of me agrees with that... but
again, I have a hard time concluding that it's therefore better to
give them a language that's just broken in some ways.

This is a reasonable representation. I didn't realize these features were broken, which does make me more supportive of removing them.

i keep imagining a student asking me how to play a sound or something, and I don't want to say "no, sorry". I'd love to be able to say "well, actually" and show her some awful hack which opens up the whole world of modern software underneath this toy -- one of the important things about software (and math) is that sometimes a whole world is behind a hack.

I was able to hack a foreign import to work.

    foreign import javascript safe "alert(\"Hello!\")"

       js_hello :: ()

   main = pictureOf(circle(seq js_hello 1))

   seq () x = x

Which, honestly, is pretty good.

Is there a way to get the codeworld prelude without hiding base? Maybe NoImplicitPrelude with some other magic to import it automatically?

To view this discussion on the web visit https://groups.google.com/d/msgid/codeworld-discuss/CAPq5Pv%2BMeF-bRXQUzQgUmBzAJ51SzhWiYU2MvnYGnCnO0HEqMw%40mail.gmail.com.

[Luke Palmer]

On Fri, Aug 15, 2014 at 2:43 PM, Luke Palmer <lu...@google.com> wrote:

On Fri, Aug 15, 2014 at 9:13 AM, Chris Smith <cds...@gmail.com> wrote:

I understand Luke's point is a little broader than this, though.  More
than being an argument about whether CodeWorld should steer students
toward full Haskell, it's more that it's better to put kids in an
environment where there are rough edges for them to explore, instead
of having everything neatly packaged and pulling them away from what
they aren't "supposed to see".  Part of me agrees with that... but
again, I have a hard time concluding that it's therefore better to
give them a language that's just broken in some ways.

This is a reasonable representation. I didn't realize these features were broken, which does make me more supportive of removing them.

i keep imagining a student asking me how to play a sound or something, and I don't want to say "no, sorry". I'd love to be able to say "well, actually" and show her some awful hack which opens up the whole world of modern software underneath this toy -- one of the important things about software (and math) is that sometimes a whole world is behind a hack.

I was able to hack a foreign import to work.

    foreign import javascript safe "alert(\"Hello!\")"

       js_hello :: ()

   main = pictureOf(circle(seq js_hello 1))

   seq () x = x

Which, honestly, is pretty good.

(By which I mean pretty powerful, not that it's pretty or clean. It's a good hack.)

[Chris Smith]

'Luke Palmer' via codeworld-discuss <codeworl...@googlegroups.com> wrote:
> Is there a way to get the codeworld prelude without hiding base? Maybe
> NoImplicitPrelude with some other magic to import it automatically?

I'm not aware of a way. Anything I can come up with is either
insanely complex, or broken. You could just insert the import
statement before compiling. But then you gain a bunch of corner
cases, like fixing up error messages, parsing the source to decide
where to put it, how to handle if the student already did the import,
etc.

It feels like there ought to be a cleaner answer than that. Maybe
worth poking into...

> https://groups.google.com/d/msgid/codeworld-discuss/CAH%2BCnvhOHgBhw4ERLR7bi%2B44wmtq1veUqGC%2Bwtg99CcfyXUq8g%40mail.gmail.com.

[Chris Smith]

In fact, this works as well.

import GHCJS.Types
import GHCJS.Foreign
foreign import javascript unsafe "alert($1)"
js_log :: JSString -> IO ()
main = js_log (toJSString "Foo")

The problem here is just 'base', so we can get around it by dodging
things that are defined in base. Importing stuff from text,
ghcjs-base, containers, etc. works fine.

I'm not opposed to making codeworld-base export a
CodeWorld.HaskellPrelude, and also re-exporting some set of common
modules from base. If you want to send a pull request for this,
that's fine with me! Then the pattern would be:

import qualified Prelude as CodeWorld
import CodeWorld.HaskellPrelude
import Data.List -- etc.

and hack away to your heart's content.

We still need to disable TemplateHaskell (as a security issue, since
the compiler runs on the server - actually, for the moment I'm relying
on using a version of GHCJS where TH is broken by the --no-native
flag; but when I upgrade GHCJS, I'll need to solve this problem
better). There's also no point in exporting the APIs for file and
directory access, since they won't work in the browser.

So I'll consider the original proposal dead, and add a new issue to
track re-exporting more modules from base.

On Fri, Aug 15, 2014 at 2:43 PM, 'Luke Palmer' via codeworld-discuss

> https://groups.google.com/d/msgid/codeworld-discuss/CAH%2BCnvhOHgBhw4ERLR7bi%2B44wmtq1veUqGC%2Bwtg99CcfyXUq8g%40mail.gmail.com.

[Chris Smith]

https://github.com/google/codeworld/issues/58

[Chris Smith]

This is now done. Enjoy! :)

http://codeworld.info/#PPjiM3v-S2VxRaaCcyA6tlg==

[Tim Docker]

On 16 Aug 2014, at 2:13 am, Chris Smith <cds...@gmail.com> wrote:

> My knee-jerk (and mostly wrong) response is that CodeWorld is not
> supposed to be an introduction to a computer programming career. And
> this is true... but, at the same time, it's deeply unsatisfying to
> think that students who choose to explore computer programming further
> would have difficulty doing so.

I agree that, of the students who try codeworld, maybe 1 in 10 will want go beyond the classes and become more knowledgeable and proficient in programming. Of those, perhaps 1 in 10 may go on to a career in programming. So it makes sense to optimise the experience for the 90%.

However, having tinkered with scratch in the past, my children got a buzz out of learning a little of a real programming language - something that other people use to perform real tasks. I think this can be a motivation for students.

The work you have done on codeworld is truly excellent, though I must admit that, with each step it moves away from a subset of conventional haskell, I feel a twinge of disappointment.

> I replaced the Prelude to kill type classes.

+1

> I uncurried the standard library.

-1. I can see why you did this, but if it were my choice, I would have valued consistency with conventional haskell slightly more than consistency with conventional algebra.

As for removing keywords, I’m not sure it’s worthwhile. Learning pretty much any programming language requires you to understand that there are reserved words, that can’t be used for variable names. I don’t see it as problematic that the list of reserved words includes some that aren’t needed yet for students' code.

> One interesting question is whether it's important for students to
> "move on" to full-fledged Haskell, versus other languages.

If students are going to move on to a fully fledged language, why not Haskell? Given their valuable “programming using algebra” experience, haskell is a natural step. If they have a particular reason to use another language, then they can learn it, of course. But conventional haskell is a logical progression from codeworld, that with planning could be made in gentle stages. It would be great if the progression only involved learning new concepts, and not unlearning tweaks made to “simplify” the codeworld experience.

Tim

[Chris Smith]

Just to be sure it's clear, I'm no longer considering disabling
keywords. We instead picked the other direction, and quite a few
changes have gone in (which should not affect anyone using the
standard Prelude) to make CodeWorld more usable if you choose to hide
the replacement Prelude and program in more vanilla Haskell.

It's a little wordy at the beginning. You have to say:

{-# LANGUAGE NoImplicitPrelude #-} -- or: import Prelude()
import HaskellPrelude
import CodeWorld

But after that, you're all set. Except for the functions in CodeWorld
being uncurried, that is... but if someone wants to contribute a
HaskellCodeWorld module to work around that, I'm fine with that, too.

> --
> You received this message because you are subscribed to the Google Groups "codeworld-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to codeworld-disc...@googlegroups.com.
> To post to this group, send email to codeworl...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/codeworld-discuss/8350840B-A1D3-4EF9-A2EB-47F5104626B5%40dockerz.net.

[Luke Palmer]

Wow, cool.  The stepping stones are in place. Thanks, Chris!

To view this discussion on the web visit https://groups.google.com/d/msgid/codeworld-discuss/CAPq5Pv%2B_jzLaLGmTYwCCS2k-Y%3DtopJA81wW0YDUzQ-3SSnCZoQ%40mail.gmail.com.