7 ms·

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 ro

by sja 11y ago

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?

mintplant 11y ago
Try the README: https://github.com/akkartik/mu/blob/master/Readme.md 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.cc 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, these source files are C++ code for the compiler, not an example of Mu code.) The author also has a blog post up here: http://akkartik.name/post/mu http://akkartik.name/post/mu
- deleted 11y ago
  [deleted]
- akkartik 11y ago
  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 http://akkartik.name/post/wart-layers
ktRolster 11y ago
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.
- akkartik 11y ago
  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 http://akkartik.name/post/wart
  - ktRolster 11y ago
    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.
    - akkartik 11y ago
      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.
      - 11y ago
akkartik 11y ago
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.
- btrask 11y ago
  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!
  - akkartik 11y ago
    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.

by sja 11y ago

mintplant 11y ago

Try the README: https://github.com/akkartik/mu/blob/master/Readme.md 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.cc 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, these source files are C++ code for the compiler, not an example of Mu code.) The author also has a blog post up here: http://akkartik.name/post/mu http://akkartik.name/post/mu

deleted 11y ago
[deleted]
akkartik 11y ago
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 http://akkartik.name/post/wart-layers

ktRolster 11y ago

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.

akkartik 11y ago
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 http://akkartik.name/post/wart
- ktRolster 11y ago
  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.
  - akkartik 11y ago
    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.
    - 11y ago

akkartik 11y ago

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.

btrask 11y ago
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!
- akkartik 11y ago
  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.