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

21–30 of 66 posts

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

#21

Post by btrask »

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…

Sure, directories can be used badly (and the Java and Ruby projects I've seen are often very difficult to navigate because so much is the structure of the language, rather than the structure of the project).

But they can also be used well, and the promise of a meaningful directory structure is really appealing.

Here's a question, given all of what I understand about your layered way of structuring code: how easy is it to spin off logical portions of a project? If my project accretes its own HTTP server and I want to turn that into a stand alone library, could I? Would it be possible to "rewrite history" so that the HTTP-related changes never appeared in the layers to start with?

Thanks!

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

#22

Post by akkartik »

btrask wrote: post #21
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…

Sure, directories can be used badly (and the Java and Ruby projects I've seen are often very difficult to navigate because so much is the structure of the language, rather than the structure of the project). But they can also be used well, and the promise of a meaningful directory structure is really appealing. Here's a question, given all of what I understand about your layered way of structuring code: how easy is i…

Yeah, that's a good question. Even though the mu core is at the top directory, there are a couple of apps in sub-directories of their own. To run a single-file mu program you say:

  $ ./mu factorial.mu
To run a more complex app, you just give a directory name rather than a filename:

  $ ./mu edit
Files inside the directory are loaded in numeric order just like at the top level. You can also run just a subset of the layers for the editor:

  $ ./mu test edit/001*
  $ ./mu test edit/00[12]*
  $ ./mu test edit/00[1-3]*
(Notice how the number of tests/dots grows at each layer.)

Since the layers are just regular files there's nothing stopping you from rewriting history as much as you want. That ability was precisely what I built them for.

I've only recently started using directories, so I'm sure there's stuff here I haven't considered. Feedback most welcome.

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

#23

Post by akkartik »

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.

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

#24

Post by vinodkd »

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.

Will do. And yes, I did read your rationale. The intent is not bad, the names probably are.

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

#25

Post by vmorgulis »

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

> Wart's infix operators have only one hard-coded precedence rule: operators without whitespace are evaluated before operators with whitespace.

> n * n-1 # does what you expect

Very good idea!

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

#26

Post by dorfsmay »

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…

Why the comma? Why not

    substract a 3
or even:

    (- a 3)

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

#28

Post by dman »

I think the project would benefit from a Terminology / Definitions section which lists in one table the names and crisp definitions of the concepts being introduced. It appears that you are using non standard terms so having a single list of the terms would allow readers to have that list open when they are reading through the layers.

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

#29

Post by slang800 »

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.

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

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

#30

Post by slang800 »

ktRolster wrote: post #10
FenugreekAcerb wrote: post #7

Earlier quoted context omitted.

Some say (for example Moore) that arithmetic is only a tiny part of programming and don't deserve special syntax (especially with a language that lacks C-style for loops).

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".
Post reply on HN