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

11–20 of 66 posts

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

#11

Post by akkartik »

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 increasingly suspicious of all our navel-gazing about syntax. We spend all our time in places like HN thinking about how to make small screenfuls of code look nice, but all that effort hasn't really translated into helping me understand the large-scale structure of random open-source codebases more easily.

Perhaps one way to think about it is that syntax helps insiders keep a codebase in their head. I'm more concerned with ways to help more outsiders import a codebase in the first place. Because people leave and move on, and it's very hard for software projects today to improve once their original authors move on. More on this: http://akkartik.name/post/readable-bad

(I'm susceptible to carpal tunnel, but it hasn't become a bigger issue. I take wrist breaks.)

[1] I can even imagine doing the translation in machine code, so that Mu then becomes self-hosting without needing any of the current stack. I might go down that road..

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

#12

Post by akkartik »

ktRolster wrote: post #9
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?

His idea is that the way to understand a large computer program is by running it, testing it. So he's made (what I understand) a very nice UI for introspection of a running computer program. You can see what is happening while it's running. Designing a programming language is kind of like a 'rite of passage.' I think most of us have at least thought about how to make languages better.

Heh, I've already had my programming language rite of passage[1]. Mu was my attempt to not build yet another language. Hence the lack of syntax.

Thanks for your kind words! I'm gratified that somebody understood what I'm trying to do in spite of my crappy writing skills.

[1] http://akkartik.name/post/wart

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

#13

Post by skewart »

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'm more concerned with ways to help more outsiders import a codebase in the first place."

This. The pain point that mu addresses is huge. I haven't really looked at the project in much depth yet, or played around with it, but I love that you are tackling this issue. I have spent way too much time wandering around a big code base trying to build mental models of what's going on, and thinking to myself the entire time "there's got to be a better way."

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

#14

Post by akkartik »

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 directories that are uneconomic to reorganize. At least a flat directory has a shot at under-promising and over-delivering.

c) Maybe people do it to make the place look neat, they way I used to 'clean my room' by stuffing all my dirty clothes into drawers. But codebases that are messes at a deep level are less likely to be cleaned up if they look clean at a superficial level. And all codebases eventually turn into messes, the way we've done things so far.

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

#15

Post by chipsy »

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…

This kind of consideration has led me down the road towards XML, because it's the syntax that is powerful enough to model documents that bundle a mix of schemas(including source formats with their own idiosyncratic syntax). It is not a syntax anyone wants to type in or read, but that one advantage counts for a lot, given the right problem domain, because it pushes the semantic content to the center.

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

#16

Post by akkartik »

mintplant wrote: post #5
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?

Try the README: https://github.com/akkartik/mu/blob/master/Readme.md It's a new programming language. edit: The source seems to be structured intentionally in a recommended reading order. See the comment at the top of https://github.com/akkartik/mu/blob/master/000organization.c... Layers of code are filled in as you read down the list of files. It's an interesting concept, similar to literate programming. (And FWIW,…

Thanks for figuring all that out and laying it out so clearly!

More details on my flavor of literate programming: http://akkartik.name/post/wart-layers

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

#17

Post by kazinator »

> Imagine a world where you can:

> [...] think of a tiny improvement to a program you use, clone its sources, orient yourself on its organization and make your tiny improvement, all in a single afternoon.

If we alter that to "three programs you use [...] all in a single afternoon", we can plonk that into my resume.

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

#18

Post by ktRolster »

akkartik wrote: post #12
ktRolster wrote: post #9

Earlier quoted context omitted.

His idea is that the way to understand a large computer program is by running it, testing it. So he's made (what I understand) a very nice UI for introspection of a running computer program. You can see what is happening while it's running. Designing a programming language is kind of like a 'rite of passage.' I think most of us have at least thought about how to make languages better.

Heh, I've already had my programming language rite of passage[1]. Mu was my attempt to not build yet another language. Hence the lack of syntax. Thanks for your kind words! I'm gratified that somebody understood what I'm trying to do in spite of my crappy writing skills. [1] http://akkartik.name/post/wart

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 program is run, because you won't be able to test every possible condition in a debugger.

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

#19

Post by akkartik »

ktRolster wrote: post #18
akkartik wrote: post #12

Earlier quoted context omitted.

Heh, I've already had my programming language rite of passage[1]. Mu was my attempt to not build yet another language. Hence the lack of syntax. Thanks for your kind words! I'm gratified that somebody understood what I'm trying to do in spite of my crappy writing skills. [1] http://akkartik.name/post/wart

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 works." This way the reader doesn't have to recreate such situations from scratch. He or she just has to verify the provided situations, or notice a scenario that was missed. That seems like an easier ask from someone new to the project.

(Mu scenarios can't insert context switches yet, but it's planned.)

Perhaps it would help to think of the dichotomy as between the rules and the state space of inputs they handle, rather than between reading and running. Seemingly simple code can often hide surprising subtleties. Why is this line written just like so and not thus? How does everything turn out just right in this one situation? Tests help to record the right questions for the reader to ask.

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

#20

Post by vinodkd »

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.

Post reply on HN