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

41–50 of 66 posts

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

#41

Post by nickpsecurity »

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.

It's not the same. I can open, process, or skim a directory containing a thousand files without much trouble or CPU activity. Having a thousand files worth of information in one file means I have to run through all that data at once. This has implications in data integrity as well if I'm making changes or worried about bitrot.

So, no, there's a difference. I'll also note that Daniel Bernstein of qmail & NaCl often used a filesystem how some use databases under the philosophy of "Why create new, complex functionality when you have well-tested code that gets the job done?"

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

#42

Post by akkartik »

enqk wrote: post #37

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

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 different functions. So my tests write stuff I want to check in raw numbered locations, and the first 1000 addresses are reserved for tests so that names can never be clobbered.

I looked at Rust's borrow checker for a bit but wasn't smart enough to understand how it works or transplant it easily. I also noticed that it wasn't smart enough to deal with things like doubly-linked lists without reaching for ref-counting. So I figured I'd keep things simple and just use ref-counting for everything. That way I punt on all the complicated static checks in favor of a simple runtime one.

The rule is: new returns shared:address, and get-address and index-address (and maybe-convert) return address. Use shared:address to pass things around between functions, and reserve non-shared addresses only for short-term operations, usually mutations. Since non-shared addresses are not dynamically allocated, there's no possibility of use-after-free so they don't need to be refcounted, and you can copy them around as much as you like.

Use-after-free and related memory corruption is really the only thing I'm concerned about protecting my users from. Memory leaks I plan to have tools for, so that programmers can identify and break them down when memory becomes a concern, but not worry about until then. I call this "zero-developer-cost abstractions" :) It feels less restrictive and more dynamic than Rust.

Edit: I just took a look at your code, and it feels perfectly idiomatic. Nice job. Only issue I found was that you forgot to specify the outputs of find in its header. So its calls end up doing some runtime type-checking. I should probably raise a warning in this situation. Thanks again.

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

#43

Post by akkartik »

userbinator wrote: post #39
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…

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

You've effectively created a sort of portable assembly language

Exactly. The verbosity is mostly because of my teaching project. I think teaching assembly can be just as ergonomic as teaching a high-level language. Indeed, most of us from a generation ago learned programming using assembly. It just needs to get a little more ergonomic.

the solution is to encourage reducing complexity.

Yup. The problem is that human beings have a _terrible_ track record at managing complexity. It's not just every software project ever; think about the creep of bureaucracy in ancient China, or the creep of legislation in ancient Rome. Everytime we've created a repository of rules it's gotten complex (and then gamed by smart operators). I think the problem is that it's very hard to justify removing a rule, so such repositories grow monotonically. The only way to periodically prune unnecessary rules is to first track why you created them in the first place (https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence). Hence: tests! I think they are the great advance bequeathed to the human race by software. And they're far more broadly applicable outside software -- though I have no idea how to do this applying. I wrote up some speculative ideas about it at http://www.ribbonfarm.com/2014/04/09/the-legibility-tradeoff a couple of years ago, but that piece isn't very clear.

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

#44

Post by akkartik »

ktRolster wrote: post #38
akkartik wrote: post #19

Earlier quoted context omitted.

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

Do you really look at every single piece of shared memory? When you inherit a large codebase from someone? How do you reconcile that with having to deliver changes in the first weeks? Everywhere I've been, people half-ass these things, with inevitable bugs. I think you're under-estimating the possibility that you're just a better programmer than me :/

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

#45

Post by akkartik »

ktRolster wrote: post #36
slang800 wrote: post #30

Earlier quoted context omitted.

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.

Each pair of asterisks turned into an empty italic block due to HN's formatting rules. You can see them if you view source :)

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

#46

Post by Someone »

akkartik wrote: post #23
vinodkd wrote: post #20

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

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.

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.

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

#47

Post by akkartik »

Someone wrote: post #46
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.

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.

That's a really good point. I'm going to keep an eye out for this confusion with my next student.

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

#48

Post by enqk »

akkartik wrote: post #42
enqk wrote: post #37

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

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 really like the directions you are exploring, as I've come to very similar conclusions at this point in my career: - being able to modify a system through safe additions - not focusing too much on local details of a system

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

#49

Post by ktRolster »

akkartik wrote: post #44
ktRolster wrote: post #38

Earlier quoted context omitted.

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

Do you really look at every single piece of shared memory? When you inherit a large codebase from someone? How do you reconcile that with having to deliver changes in the first weeks? Everywhere I've been, people half-ass these things, with inevitable bugs. I think you're under-estimating the possibility that you're just a better programmer than me :/

  > Do you really look at every single piece of shared memory?
Yes

  > When you inherit a large codebase from someone?
If the codebase has lots of threading errors, then yes, it's the only way. If it's a large program, it can take months to go through and check every piece of shared memory (and removing threads along the way, removing shared stuff); but the alternative could take years.

In one case, I moved every single lock/unlock to the top of a file so I could quickly see all the locks and unlocks, and that each lock had a matching unlock, even in error conditions.

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

#50

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…

Yeah, the reactions here have been invaluable. It's interesting: I actually got into teaching because I had trouble getting programmers to try Mu out. Most people tend to unconsciously filter out what seems gratuitously new and different. But I'll keep trying.
Post reply on HN