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

31–40 of 66 posts

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

#31

Post by akkartik »

slang800 wrote: post #29
akkartik wrote: post #23

Earlier quoted context omitted.

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 . But I've certainly started mixing up the terms with my student, so it might not last.

> 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 real problems.

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

#33

Post by akkartik »

dorfsmay wrote: post #26
akkartik wrote: post #11

Earlier quoted context omitted.

It translates to assembly/machine code with a lot less code. I don't need a compiler, I don't need to write optimizations.[1] I actually don't consider Mu to be a language. (I'm the author.) It's a low-level starting point to explore ways to make the standard OS primitives more testable. I don't need it to look nice. Higher level languages can come later, once the foundations are in place. I actually am growing incre…

Why the comma? Why not substract a 3 or even: (- a 3)

The comma is optional.

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

#34

Post by i573323 »

akkartik wrote: post #14
sja wrote: post #2

I'm a little hesitant to learn how to 'understand large programs', or how to structure them for that matter, from a repository that has 100 code files in the root directory. I'm not sure what I'm looking at?

Author here. For my part, I have never understood why people consider it to be a good thing to squirrel code into a bunch of different sub-directories. a) It makes the build scripts more complicated, which means they'll be more likely to break on some poor noob, and that when they break it'll be less likely the noob will be able to tell how to fix it. b) Invariably the codebase accumulates dependencies between direct…

That same line of thinking could be used to just put everything into a single huge file.

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

#35

Post by akkartik »

i573323 wrote: post #34
akkartik wrote: post #14

Earlier quoted context omitted.

Author here. For my part, I have never understood why people consider it to be a good thing to squirrel code into a bunch of different sub-directories. a) It makes the build scripts more complicated, which means they'll be more likely to break on some poor noob, and that when they break it'll be less likely the noob will be able to tell how to fix it. b) Invariably the codebase accumulates dependencies between direct…

That same line of thinking could be used to just put everything into a single huge file.

I have to admit, I like long files. Arc's compiler is all in one file (https://github.com/arclanguage/anarki/blob/master/ac.scm) and it was a big influence on me. It was just so great to be able to have it open on one side while I wrote programs in Arc.

You're right that there are points beyond which a single file becomes too unwieldy, but with a good editor that limit is quite high for me. Maybe 10k LoC. Directories can grow even larger before they start having problems.

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

#36

Post by ktRolster »

slang800 wrote: post #30
ktRolster wrote: post #10

Earlier quoted context omitted.

Really all you need for programming are > Anything more than that is for wimps. Brain is the only language I ever program in.

I think you mean "Brainfuck", I can't find a programming language called "Brain".

I haven't been posting here long, so I wasn't sure if it was acceptable to type 'fuck.' So I self-censored by replacing it with asterisks, which hackernews promptly ate. So yes, you are right of course.

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

#37

Post by enqk »

So I wrote an implementation of linear search in Mu using its array type.

https://gist.github.com/uucidl/df81b6ab0fe65713f5ba

My notes:

- creating an array w/ create-array is possible, however I could not find how to take its address and pass it around

- one cannot get the address of an invalid position of the array, so one cannot construct bounded ranges (STL style) using a begin/end pair of addresses

- the interpreter strongly suggests to use refcounted pointers (address:shared) instead of addresses even when one does not borrow the memory

- could not figure out how to write a test scenario that uses checks named memory addresses rather than ordinal memory addresses (memory-should-contain instruction)

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

#38

Post by ktRolster »

akkartik wrote: post #19
ktRolster wrote: post #18

Earlier quoted context omitted.

I'm glad I got it right :) I like your idea, and I think there's room for improved introspection in debugging. At the same time, I think that if a program can't be understood without being executed, then it's already lost (in terms of readability). Certainly, for example, if you have a threaded program, you need to be able to visually inspect and verify that there will be no deadlocks or race conditions when the prog…

It might partly be a personality-type thing. I can't imagine visually inspecting and verifying anything if I didn't write it to begin with. I wouldn't know where to begin thinking of possible ways to break it. On the other hand, it seems far more natural for the author to say, "here are the race conditions I considered, these points where a context switch would be maximally inconvenient. And still lo the program work…

  >  I can't imagine visually inspecting and verifying anything if I didn't write it to begin with.
It's a skill, you need to develop it. You develop it by doing it :)

  > I wouldn't know where to begin thinking of possible ways to break it.
For deadlocks, look at every single lock used. Show that one of the Coffman conditions doesn't apply, and you've proven that there can never be a deadlock.

For race conditions, look at every piece of shared memory (or other shared resource). That is where race conditions always occur.

For understanding a program, the key is to understand the structure. That is why people put things in subdirectories, to help communicate the structure of the program, and show which things are closely related.

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

#39

Post by userbinator »

akkartik wrote: post #11
antiquark wrote: post #3

How is "subtract a, 3" better than "a-3"? I can already feel my carpal tunnel acting up!

It translates to assembly/machine code with a lot less code. I don't need a compiler, I don't need to write optimizations.[1] I actually don't consider Mu to be a language. (I'm the author.) It's a low-level starting point to explore ways to make the standard OS primitives more testable. I don't need it to look nice. Higher level languages can come later, once the foundations are in place. I actually am growing incre…

I don't need a compiler, I don't need to write optimizations.

You've effectively created a sort of portable assembly language, but it's more verbose than usual assembly language ("sub eax, 3").

but all that effort hasn't really translated into helping me understand the large-scale structure of random open-source codebases more easily.

I think the root of the problem is that software is being written to be more complex than it could/should be, so the solution is to encourage reducing complexity.

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

#40

Post by nickpsecurity »

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…

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.

Post reply on HN