Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mu: making programs easier to understand in the large

github.com

Post reply on HN
Print view View original

61–66 of 66 posts

Re: Mu: making programs easier to understand in the large

#61

Post by slang800 »

akkartik wrote: post #31
slang800 wrote: post #29

Earlier quoted context omitted.

> 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 ) 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…

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…

Yeah, I agree about the term "threads" - it doesn't make for a very direct metaphor.

As for functions, I think the term makes sense, even with the non-mathematical definition, and especially in the context of OOP:

> an activity or purpose natural to or intended for a person or thing. synonyms: purpose, task, use, role

The "purpose" part doesn't make much sense with the way that we use the word, but it's certainly an activity. For example, a function of a stove is boiling water, its input would be liquid water, and its output would be steam & hot water. In OOP, "stove" would be the name of the class, and "boil_water" would be the function.

Re: Mu: making programs easier to understand in the large

#62

Post by akkartik »

slang800 wrote: post #61
akkartik wrote: post #31

Earlier quoted context omitted.

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…

Yeah, I agree about the term "threads" - it doesn't make for a very direct metaphor. As for functions, I think the term makes sense, even with the non-mathematical definition, and especially in the context of OOP: > an activity or purpose natural to or intended for a person or thing. synonyms: purpose, task, use, role The "purpose" part doesn't make much sense with the way that we use the word, but it's certainly an…

Ah, that's an interesting way to look at it. I hadn't considered that. Was that how the term appeared in math, I wonder.. Thanks!

Re: Mu: making programs easier to understand in the large

#63

Post by nickpsecurity »

slang800 wrote: post #60
nickpsecurity wrote: post #40

Earlier quoted context omitted.

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. T…

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 go…

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.

Re: Mu: making programs easier to understand in the large

#64

Post by akkartik »

nickpsecurity wrote: post #63
slang800 wrote: post #60

Earlier quoted context omitted.

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 go…

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 spi…

I like that very much.

Re: Mu: making programs easier to understand in the large

#65

Post by akkartik »

enqk wrote: post #48
akkartik wrote: post #42

Earlier quoted context omitted.

That's great!! Yes, create-array was just a version I created so I could teach arrays separate from new and addresses. But it creates an array on the 'stack' (default space) so there's no way to take an address of it. I quickly take my students past it to new . memory-should-contain doesn't currently support named locations, sorry. Part of the problem is that with spaces a name can have many different addresses in di…

Indeed, I missed the output for find! A warning would definitely be helpful. I like that you have users and thus will be able to test things out and get some genuine feedback. This might however introduce a bias guiding your language and standard library in a certain direction (I think it's inevitable and what's happening in all languages anyway) .. Therefore I would add some of your peers into the mix. Otherwise I r…

I just added the warning.. and found several bugs in my mu code. Thanks! I've credited you in this commit: https://github.com/akkartik/mu/commit/8fd27372b6

Re: Mu: making programs easier to understand in the large

#66

Post by ktRolster »

akkartik wrote: post #59
ktRolster wrote: post #58

Earlier quoted context omitted.

> How did you get into such issues? Were there classes where you got started, or was it all on the job? I took the usual college classes dealing with concurrency (in my school it was in the OS class), but it took several years in the industry to really feel confident with threads (it took less time to feel confident with networking). I wrote down my knowledge (for what it's worth) in this book: http://www.amazon.com/…

Yeah, I'm familiar with the notion of critical section, and ideas like Ada's monitors, though my understanding is mostly theoretical. I'm glad I kept the conversation going so I could find out about your book. Purchased.

I'm looking forward to seeing what interesting things you come up with in the future.
Post reply on HN