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

51–60 of 66 posts

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

#51

Post by enqk »

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…

I would also agree that function is the wrong name.

Procedure however might be a good enough name, less connoted than Recipe.

Quoting the Elements of Programming by Alexander Stepanov:

"A Procedure is a sequence of instructions that modifies the state of some objects; it may also construct or destroy objects."

With the definition of Object as:

"An Object is a representation of a concrete entity as a value in memory"

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

#52

Post by akkartik »

dman wrote: post #28

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.

That's a good idea. Might http://akkartik.github.io/mu/html/010vm.cc.html [1] be such a big-picture map? Let me think about how to improve it; I haven't touched it in a while. Further suggestions most welcome.

[1] Colorized version of https://github.com/akkartik/mu/blob/379244666c/010vm.cc

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

#53

Post by akkartik »

ktRolster wrote: post #49
akkartik wrote: post #44

Earlier quoted context omitted.

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…

How did you get into such issues? Were there classes where you got started, or was it all on the job?

I think I'm not concerned so much about inheriting a codebase with lots of threading errors. It's more about a codebase that's almost perfectly right, but where I'm scared to change anything because I don't have a big-picture model of the concurrency in my head..

Do you have any code samples I can try to learn from? For example, I'm not sure how you would move lock/unlock pairs to the top of a file from different functions/scopes. Unless you were doing some sort of literate programming as well?

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

#54

Post by dman »

akkartik wrote: post #52
dman wrote: post #28

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.

That's a good idea. Might http://akkartik.github.io/mu/html/010vm.cc.html [1] be such a big-picture map? Let me think about how to improve it; I haven't touched it in a while. Further suggestions most welcome. [1] Colorized version of https://github.com/akkartik/mu/blob/379244666c/010vm.cc

I was thinking something much simpler. If you were writing a book about Mu what would be the definitions you would print on the back inner cover? A table with two columns - first column being a term and the second column containing its description in one or two sentences.

Could you elaborate on the target audience for the doc you linked to? I am unable to make out whether that doc is intended for serious programmers in other languages coming across Mu for the first time or whether its intended for new comers to programming.

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

#55

Post by dman »

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…

I think the reason why people (I put myself into this camp as well) prefer directories for organization is because there is an entire ecosystem built around them. Backing up, recursive search, exploring via ui, programmable access, programmatic access using language of ones choice are all choices available to the user. Code organization isnt the only place this shows up, organizing music and photos has similar semantics - apps which try to do the organization via higher level metadata rarely put in the engineering effort to come up with robust solutions for all the above use cases I cited abode.

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

#56

Post by dman »

akkartik wrote: post #43
userbinator wrote: post #39

Earlier quoted context omitted.

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

While working on large code bases I have often (in half jest) wished for the concept of a runtime performance tax on code that is engineered poorly. Some variants of this could be a. Imposing an exponentially increasing programmatic sleep on functions based on their length. b. Repeated database / filesystem / network requests for identical resources multiple times in a program should again incur a slowdown.

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

#57

Post by akkartik »

dman wrote: post #54
akkartik wrote: post #52

Earlier quoted context omitted.

That's a good idea. Might http://akkartik.github.io/mu/html/010vm.cc.html [1] be such a big-picture map? Let me think about how to improve it; I haven't touched it in a while. Further suggestions most welcome. [1] Colorized version of https://github.com/akkartik/mu/blob/379244666c/010vm.cc

I was thinking something much simpler. If you were writing a book about Mu what would be the definitions you would print on the back inner cover? A table with two columns - first column being a term and the second column containing its description in one or two sentences. Could you elaborate on the target audience for the doc you linked to? I am unable to make out whether that doc is intended for serious programmers…

Yeah the intended audience is existing C++ programmers coming across Mu for the first time. For teaching programming I mostly imagine I'll be doing it in person. Mu isn't yet ready for learning programming unassisted.

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

#58

Post by ktRolster »

akkartik wrote: post #53
ktRolster wrote: post #49

Earlier quoted context omitted.

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

How did you get into such issues? Were there classes where you got started, or was it all on the job? I think I'm not concerned so much about inheriting a codebase with lots of threading errors. It's more about a codebase that's almost perfectly right, but where I'm scared to change anything because I don't have a big-picture model of the concurrency in my head.. Do you have any code samples I can try to learn from?…

  > How did you get into such issues? Were there classes where you got started, or was it all on the job?
I took the usual college classes dealing with concurrency (in my school it was in the OS class), but it took several years in the industry to really feel confident with threads (it took less time to feel confident with networking). I wrote down my knowledge (for what it's worth) in this book: http://www.amazon.com/dp/0996193308

  >  I'm not sure how you would move lock/unlock pairs to the top of a file from different functions/scopes.
That solution might not work in every case. It worked in the particular case I was referring to.

  > It's more about a codebase that's almost perfectly right, but where I'm scared to change anything because I don't have a big-picture model of the concurrency in my head..
Hmmmmm, that's an interesting question. Usually when the codebase is written, the person who wrote it had an idea in his head that, "this is how things will be locked to avoid problems." I try to figure out what that idea was.

Sometimes there is like a critical 'zone,' where a thread acquires the lock when it enters, and releases when it leaves. For example, it could acquire the lock when it enters a class method, and releases it when it leaves the class. Then the class becomes the critical zone.

Maybe learning to think of 'critical zones' is the most important skill to understanding the big picture?

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

#59

Post by akkartik »

ktRolster wrote: post #58
akkartik wrote: post #53

Earlier quoted context omitted.

How did you get into such issues? Were there classes where you got started, or was it all on the job? I think I'm not concerned so much about inheriting a codebase with lots of threading errors. It's more about a codebase that's almost perfectly right, but where I'm scared to change anything because I don't have a big-picture model of the concurrency in my head.. Do you have any code samples I can try to learn from?…

> How did you get into such issues? Were there classes where you got started, or was it all on the job? I took the usual college classes dealing with concurrency (in my school it was in the OS class), but it took several years in the industry to really feel confident with threads (it took less time to feel confident with networking). I wrote down my knowledge (for what it's worth) in this book: http://www.amazon.com/…

Yeah, I'm familiar with the notion of critical section, and ideas like Ada's monitors, though my understanding is mostly theoretical.

I'm glad I kept the conversation going so I could find out about your book. Purchased.

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

#60

Post by slang800 »

nickpsecurity wrote: post #40
akkartik wrote: post #31

Earlier quoted context omitted.

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. T…

I'm not sure if a term like "tasks" / "jobs" / "actions" makes more sense. You wouldn't necessarily separate each thing that a program does into a new thread... Functions are for separating each body of work, while threads represent a path of execution through a process. In this way multiple lines of execution are intertwined to form a process, just as real threads are intertwined to form a rope... It's not a very good metaphor, but I can't think of a better one.

In Ada, "tasks" makes sense, but only because it is an abstraction that makes use of threads while managing all memory access and separation from the rest of the process.

Post reply on HN