4 ms·

Things I really liked: + recording runs as tests + one library for all layers of abstraction + building in assembler to avoid the big runtime. + using liter

by vinodkd 11y ago

Things I really liked: + recording runs as tests + one library for all layers of abstraction + building in assembler to avoid the big runtime. + using literate programming techniques to manage coding in assembly. + scenario, "screen-should-contain" and "assume-keyboard". awesome. + spaces: nice primitive of the closure and similar concepts + attributes for meta programs. again, awesome. + labels and using [,] as labels. genius. Suggestions: * If there's a valid reason to call them recipes, go ahead. If they're actully just functions, please stick with what everyone knows and gets. Same thing with "reagents","reply", "ingredients" and "products". Update: I did read your blog post about this. still think the regular names are better in the long run. * I dont know where you're going to with multiple types of the "number:list" kind, but if so, the map must look the same, not lispy. In all, I really like where you're going with this. Kudos! I find a lot of resonance of ideas I've had for a long time now.

akkartik 11y ago
Wow, that's a very detailed look. Thanks! Feel free to email me; my address is in my profile. The terminology is definitely a work in progress. It's mostly for my attempts to teach programming using Mu. I noticed that mathematical words intimidated some students. I tried to write up my rationale here: http://akkartik.name/post/mu http://akkartik.name/post/mu. But I've certainly started mixing up the terms with my student, so it might not last.
- vinodkd 11y ago
  Will do. And yes, I did read your rationale. The intent is not bad, the names probably are.
- slang800 11y ago
  > Functions, arguments, classes, methods, objects, threads, locks, all these are reassuring everyday words, and yet their meaning in programming (and math) bears no relation to their everyday meaning. (from http://akkartik.name/post/mu http://akkartik.name/post/mu) I can see how the use of the term "arguments" could be confusing ("parameters" or "inputs" would make more sense), and "threads" is a rather tenuous metaphor for how scheduling works within a kernel, but all of the others mirror their real-world meaning pretty well. I'd be more worried about students needing to unlearn "containers", "ingredients", and "reagents" when they start reading material from outside of Mu, talking to other developers, or learning calculus (which uses functions, sets, and arrays).
  - akkartik 11y ago
    Actually, the only thread a ten-year-old knows is the one you might play cat's cradle with. It isn't obvious why there should be anything exclusive about one, or why you're better off keeping multiple of them 'separate'. Functions are what something is for, as opposed to form. It isn't natural to think about their inputs and outputs. It's quite possible my solutions are too blunt and problematic, but these seem like real problems.
    - nickpsecurity 11y ago
      Ada called them tasks. I always thought a multi-tasking program made more sense intuitively if one knew what a task was. A language designed for easy learning might call them actions, activities, jobs a la 1960's... something more intuitive. Interesting, as I tried a quick brainstorm, I thought of a group of kids sitting together playing with the same toys. Actions that only one could do on a toy at the same time. Trying to convey the problems or exclusivity. Mentally came to problem of sharing. Then that people often borrowed toys temporarily then the owner checked up on them. (lightbulb) Rust has a borrow-checker. And ownership. Now I wonder where they came up with that haha.
      - slang800 11y ago
        I'm not sure if a term like "tasks" / "jobs" / "actions" makes more sense. You wouldn't necessarily separate each thing that a program does into a new thread... Functions are for separating each body of work, while threads represent a path of execution through a process. In this way multiple lines of execution are intertwined to form a process, just as real threads are intertwined to form a rope... It's not a very good metaphor, but I can't think of a better one. In Ada, "tasks" makes sense, but only because it is an abstraction that makes use of threads while managing all memory access and separation from the rest of the process.
        nickpsecurity 11y ago
        Hmm. Good points. Maybe make an analogy to sonething like traffic lanes? More lanes equals more throughput. Not always utilized and diminishing gains as you add lanes for given workload. Problems occur during intersections where they share a resource. Requires synchronization, signalling, and/or ordering protocols to maintain safety. How you like THAT! Maybe need a similar analogy closer to whats going on but the spirit of it seems accurate. Maybe factory workers on assembly lines or offics workers at desks.
- Someone 11y ago
  Here's an argument against using the term "ingredients" for arguments: in the real world, if you bake a cake, its ingredients are gone. In your language, they still exist (if you write a recipe for eat in mu, you can have your cake and eat it) From that observation, I think one should conclude that using analogies from cooking, as you do with recipe in the kitchen sense is not the best idea.
  - akkartik 11y ago
    That's a really good point. I'm going to keep an eye out for this confusion with my next student.

by vinodkd 11y ago

akkartik 11y ago

Wow, that's a very detailed look. Thanks! Feel free to email me; my address is in my profile. The terminology is definitely a work in progress. It's mostly for my attempts to teach programming using Mu. I noticed that mathematical words intimidated some students. I tried to write up my rationale here: http://akkartik.name/post/mu http://akkartik.name/post/mu. But I've certainly started mixing up the terms with my student, so it might not last.

vinodkd 11y ago
Will do. And yes, I did read your rationale. The intent is not bad, the names probably are.
slang800 11y ago
> Functions, arguments, classes, methods, objects, threads, locks, all these are reassuring everyday words, and yet their meaning in programming (and math) bears no relation to their everyday meaning. (from http://akkartik.name/post/mu http://akkartik.name/post/mu) I can see how the use of the term "arguments" could be confusing ("parameters" or "inputs" would make more sense), and "threads" is a rather tenuous metaphor for how scheduling works within a kernel, but all of the others mirror their real-world meaning pretty well. I'd be more worried about students needing to unlearn "containers", "ingredients", and "reagents" when they start reading material from outside of Mu, talking to other developers, or learning calculus (which uses functions, sets, and arrays).
- akkartik 11y ago
  Actually, the only thread a ten-year-old knows is the one you might play cat's cradle with. It isn't obvious why there should be anything exclusive about one, or why you're better off keeping multiple of them 'separate'. Functions are what something is for, as opposed to form. It isn't natural to think about their inputs and outputs. It's quite possible my solutions are too blunt and problematic, but these seem like real problems.
  - nickpsecurity 11y ago
    Ada called them tasks. I always thought a multi-tasking program made more sense intuitively if one knew what a task was. A language designed for easy learning might call them actions, activities, jobs a la 1960's... something more intuitive. Interesting, as I tried a quick brainstorm, I thought of a group of kids sitting together playing with the same toys. Actions that only one could do on a toy at the same time. Trying to convey the problems or exclusivity. Mentally came to problem of sharing. Then that people often borrowed toys temporarily then the owner checked up on them. (lightbulb) Rust has a borrow-checker. And ownership. Now I wonder where they came up with that haha.
    - slang800 11y ago
      I'm not sure if a term like "tasks" / "jobs" / "actions" makes more sense. You wouldn't necessarily separate each thing that a program does into a new thread... Functions are for separating each body of work, while threads represent a path of execution through a process. In this way multiple lines of execution are intertwined to form a process, just as real threads are intertwined to form a rope... It's not a very good metaphor, but I can't think of a better one. In Ada, "tasks" makes sense, but only because it is an abstraction that makes use of threads while managing all memory access and separation from the rest of the process.
      - nickpsecurity 11y ago
        Hmm. Good points. Maybe make an analogy to sonething like traffic lanes? More lanes equals more throughput. Not always utilized and diminishing gains as you add lanes for given workload. Problems occur during intersections where they share a resource. Requires synchronization, signalling, and/or ordering protocols to maintain safety. How you like THAT! Maybe need a similar analogy closer to whats going on but the spirit of it seems accurate. Maybe factory workers on assembly lines or offics workers at desks.
Someone 11y ago
Here's an argument against using the term "ingredients" for arguments: in the real world, if you bake a cake, its ingredients are gone. In your language, they still exist (if you write a recipe for eat in mu, you can have your cake and eat it) From that observation, I think one should conclude that using analogies from cooking, as you do with recipe in the kitchen sense is not the best idea.
- akkartik 11y ago
  That's a really good point. I'm going to keep an eye out for this confusion with my next student.