4 ms·

> You can't parametrise a function using only global scoping. So then we ended up with both a stack and this global table lookup thing. Exactly. So, just write

> You can't parametrise a function using only global scoping. So then we ended up with both a stack and this global table lookup thing. Exactly. So, just write your functions so they don't use parameters (expect for persistence of the program). In fact, you can bypass functions all together. It also makes it a lot easier define and visually represent behavior. > Another reason we weren't really satisfied with any of the hierarchical models because they required making lots of choices about ordering in the hierarchy that weren't really relevant to the actual problem being solved. Hmm. Interesting. Could you give some examples? I would think that the hierarchy would be built out organically as you build out your program. Unless the hierarchy is actually just data that the program manipulates. Then, I could see it as an issue. But if the hierarchy is your program it should just grow organically. > We don't have a solid plan for handling reuse but we haven't actually felt the pain yet From a hierarchical standpoint, re-use (I'm guessing code re-use) is really about being able to change context by moving or executing part of your hierarchy (since a program is just a hierarchical composition of objects) in another part of your hierarchy. This is a little more difficult but can be done implementing another scoping mechanism.

jamii 12y ago
> So, just write your functions so they don't use parameters (expect for persistence of the program). In fact, you can bypass functions all together. It also makes it a lot easier define and visually represent behavior. I don't really understand what you are proposing. Can you describe how you would write a simple program (say a todo list) without parametrised functions? It works for Eve because its collection/query -oriented rather than value-oriented - we can express operations on arbitrary-length data without parametrisation. Even so, we expect to need it as we start to write bigger programs. > Hmm. Interesting. Could you give some examples? A good parallel that I use a lot is with file-systems. Picture your grandmother trying to decide whether http://jokideo.com/wp-content/uploads/2013/05/Funny-cat-and-baby.jpg http://jokideo.com/wp-content/uploads/2013/05/Funny-cat-and-... belongs in the funny-cat folder or the funny-baby folder. Similarly, I often end up stuck in functional languages trying to decide whether I should have a map from employers to lists of contractors or from contractors to lists of employers. If I choose the former and I later need to find over-employed contractors the code will be really awkward. If I choose both I have to write extra code to maintain the relationship. The big innovation of relational databases was the idea that you just directly model the employer-contractor relationship and you can later add contractor->employer or employer->contractor indexes without having to change any of your code. That's the big appeal of http://en.wikipedia.org/wiki/Data_independence http://en.wikipedia.org/wiki/Data_independence . The more I write code in relational languages, the more I notice how much of my time in other languages is spent trying to figure out where to put stuff and how to get at it later. Huge swathes of advice on design and maintainability are just working around this problem that relational databases (mostly) nailed decades ago.

jamii 12y ago

> So, just write your functions so they don't use parameters (expect for persistence of the program). In fact, you can bypass functions all together. It also makes it a lot easier define and visually represent behavior. I don't really understand what you are proposing. Can you describe how you would write a simple program (say a todo list) without parametrised functions? It works for Eve because its collection/query -oriented rather than value-oriented - we can express operations on arbitrary-length data without parametrisation. Even so, we expect to need it as we start to write bigger programs. > Hmm. Interesting. Could you give some examples? A good parallel that I use a lot is with file-systems. Picture your grandmother trying to decide whether http://jokideo.com/wp-content/uploads/2013/05/Funny-cat-and-baby.jpg http://jokideo.com/wp-content/uploads/2013/05/Funny-cat-and-... belongs in the funny-cat folder or the funny-baby folder. Similarly, I often end up stuck in functional languages trying to decide whether I should have a map from employers to lists of contractors or from contractors to lists of employers. If I choose the former and I later need to find over-employed contractors the code will be really awkward. If I choose both I have to write extra code to maintain the relationship. The big innovation of relational databases was the idea that you just directly model the employer-contractor relationship and you can later add contractor->employer or employer->contractor indexes without having to change any of your code. That's the big appeal of http://en.wikipedia.org/wiki/Data_independence http://en.wikipedia.org/wiki/Data_independence . The more I write code in relational languages, the more I notice how much of my time in other languages is spent trying to figure out where to put stuff and how to get at it later. Huge swathes of advice on design and maintainability are just working around this problem that relational databases (mostly) nailed decades ago.