4 ms·
> 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 ma
by 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.