Top-down...

[Jan Peter Axelsson]

Hello!

I am newbie here and interested both myself and as a parent to a 13-year old daughter who did a lot of Minecraft when she was 8-10.   My brief experience with Haskell is some years back. I read and worked through half of a book by Graham Hutton Programming in Haskell 2nd ed. Otherwise I work mostly with Python (and Modelica - declarative language) and consider to move to Julia. I have looked at several YouTube videos both by Chris Smith and Brooklyn Cook. For this post I mainly refer to the video by Brooklyn: https://www.youtube.com/watch?v=TDHd5RIK8DM&t=671s

I am a bit struck with the very top-down approach of making pictures etc in CodeWorld.  And Brooklyn a bit underline this. You decompose a picture to be made in parts and put ampersand in between the parts. Interesting is that the first item comes first and the second “below” sort of etc. I have heard Chris Smith talking about this design-choice and use of ampersand. I think he want to underline that by letting the second picture come "below" you get a more "declarative" style while otherwise if the picture come "above" it will be more "imperative"... And I think you are right.

1) My reflex is that ampersand in all other contexts is “symmetric”. I mean things put to the left have the same role as what is ot the right. Is not this a bit confusing? But another possible symbol could have been to use say “>” but still this symbol is very “mathematical. And I can agree you want a one key symbol. (And in Haskell you get the "and-function" with double ampersand "&&").

2) This use of ampersand I guess it is limited to the CodeWorld framework. Ampersand is not used in that way in Haskell, right?

3) I have made some Haskell practices about a year ago. But I do not recall that the program was that “top-down”, I.e. you can use the variable “basket” and then later define what it stands for… Is that also only part of CodeWorld or is it actually a true part of Haskell? I would not be surprised, and I like it, but I would like to just have it confirmed.

Look forward to some reflections here!

Jan Peter

[Joachim Breitner]

Hi Jan Peter,

good questions!

I guess its worth separating the question of order of composition, and
the choice of the symbol.

As you say: Chris has chosen the order of composition (above & below
vs. below & above) intentionally to nudge learners away from thinking
of these as “drawing operations”. We want to compose pictures here, not
sequence drawing operations.

Now as for the chosen symbol (&) – choosing symbols is always hard,
especially as many are already taken (e.g. >). What would be better
characters?


Yes, the & is CodeWorld specific. In Haskell it is reverse function
composition (x & f), but I think CodeWorld even predates the promotion
of that symbol to Data.Function:
https://hackage.haskell.org/package/base-4.15.0.0/docs/Data-Function.html#v:-38

Of course in CodeWorld you can still reorder your definition, and put
uses before defines. What makes you think that is not so, or that it is
tied to the above&below design?

Cheers,
Joachim

> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/codeworld-discuss/19958131-2e1f-4d83-93ce-688558e2b185n%40googlegroups.com
> .

--
Joachim Breitner
ma...@joachim-breitner.de
http://www.joachim-breitner.de/

[Jan Peter Axelsson]

Hello again,

I have read more of the Guide and I think I better understand the use and limited role of "&". I get the impression that ampersand is used only for composing picture and that information fall out reading the Guide/Appendix/Reference. Made some coding as well.

Also I understand that order of lines of code defining pictures etc is really arbitrarily and as you could expect from functional programming. And top-down description as you do is a matter of taste, which I like, but not necessary. 

A few comments/ questions

1. My initial worry was that ampersand was some more general technique of decomposing code and not only for pictures. Concatenation of functions that use for manipulating pictures is of course a very general technique and playing with pictures: translating, scaling, coloring etc is a very clear way to bring that to the student I guess. 
2. Looking in the Guide/Appendix/Reference I found the function "pictures" operating on a list of Picture which I in a way like better than using the ampersand. Easy to change the name picture to "composedOf" to make the code mode readable and we could write

                  beachball = composedOf [stripe, ball, sand, sky]

            So this would be a way to avoid using ampersand. Still one then need to explain operation of a 

            function on a list etc. Perhaps a complication, not sure. 

            It can be my background that make me look for general principles and looking at the video and 

            when I see ampersand presented in parallell with concatenation of functions I tended to think 

            of use of ampersand as something much more. To be fair to Brooklyns presentation she put her 

            energy on communicate the idea of concatenation of functions, while use of ampersand is 

            presented brief and clear.

       3. I have as you a quite strong belief in the value of hierarchical decomposition for code. For 

            decomposing composite pictures that contain a number of objects it should work well. Still it is

            easy to come up with "possible" pictures that does not fit into this scheme. Think of three circles that 

            partially cover each other, none is on top. How do you explain to a young student that you 

            cannot do it? How often does this kind of question come up with more complicated pictures 

            and at a late stage? 

           Perhaps worth a sentence or two in the guideline that you DO limit the kind of pictures you can 

           make.

Look forward to your further comments!

Cheers

Jan Peter