I think I understand what the author is trying to get at here (The gardening metaphor clicked with me in particular). The question asked is, "Why are functions not like programs?". For example...
- Why do programs get their own processes, but not functions?[0]
- Why can't I load and use any function from any package in my program at any time? Or run it from my shell? Genera had this.
- Why are functions organized into files?[1] you can have multiple functions in a file, which implies that they are somehow related. This creates structure, which is often unnecessary or downright confusing. The structure can only be hierarchical (files of functions or directories with files of functions). If I change the definition of a function somewhere (e.g. a REPL), it's textual representation will grow out of sync with the actual implementation. Smalltalk didn't have this.
- Why do we only ship collections of functions (programs)?[2]
- Why should all the functions in my program be written in the same language? And why is doing otherwise a pain in the ass everywhere except for Lisps?
This, to me, sounds like a lot of invisible coupling. We don't question it because it's always been this way, but I strongly believe (without having much data to prove it), that this prevents interoperability, and makes programs more bloated by increasing redundancy. I like to think that rather than reinventing "functions and function calls" or "the UNIX command line" the author described what OOP was supposed to be when it was just being rolled out in the 70s at Xerox PARC.
The project in OP addresses none of these, except maybe the bit about languages, but it did bring up an interesting point. For me, anyway.
[0] This one's easy, the process overhead on UNIX systems is a few kilobytes so you can't have everything be a process. In e.g. Erlang you can spawn a bajillion processes at will, so it's not that big of a deal. Still, AFAIK Erlang makes a process per actor rather than function.
[1] During development, I mean. You'd obviously need to put them into text files at some point. Making a Github repo and dumping a new Smalltalk image into it every day is not the way to develop software. Unless... \s
[2] scrapscript.org has an interesting take on this, where every expression (a "scrap") is content-addressable and can be replaced with it hash. They then store these expressions in "scrapyards" over IPFS. You could pull the same expression from different timeframes with built-in syntax. I think it's quite interesting.
HN really needs to introduce some rules regarding twitter links. Not everyone can access them, not everyone wants to, but they're increasingly prevalent on the front page.
It may just be a matter of where they live. I got used to sending money in btc to my grandmother because the countries we live in currently happened to be at war with each other and bank transfers were not an option.
- Why do programs get their own processes, but not functions?[0]
- Why can't I load and use any function from any package in my program at any time? Or run it from my shell? Genera had this.
- Why are functions organized into files?[1] you can have multiple functions in a file, which implies that they are somehow related. This creates structure, which is often unnecessary or downright confusing. The structure can only be hierarchical (files of functions or directories with files of functions). If I change the definition of a function somewhere (e.g. a REPL), it's textual representation will grow out of sync with the actual implementation. Smalltalk didn't have this.
- Why do we only ship collections of functions (programs)?[2]
- Why should all the functions in my program be written in the same language? And why is doing otherwise a pain in the ass everywhere except for Lisps?
This, to me, sounds like a lot of invisible coupling. We don't question it because it's always been this way, but I strongly believe (without having much data to prove it), that this prevents interoperability, and makes programs more bloated by increasing redundancy. I like to think that rather than reinventing "functions and function calls" or "the UNIX command line" the author described what OOP was supposed to be when it was just being rolled out in the 70s at Xerox PARC.
The project in OP addresses none of these, except maybe the bit about languages, but it did bring up an interesting point. For me, anyway.
[0] This one's easy, the process overhead on UNIX systems is a few kilobytes so you can't have everything be a process. In e.g. Erlang you can spawn a bajillion processes at will, so it's not that big of a deal. Still, AFAIK Erlang makes a process per actor rather than function.
[1] During development, I mean. You'd obviously need to put them into text files at some point. Making a Github repo and dumping a new Smalltalk image into it every day is not the way to develop software. Unless... \s
[2] scrapscript.org has an interesting take on this, where every expression (a "scrap") is content-addressable and can be replaced with it hash. They then store these expressions in "scrapyards" over IPFS. You could pull the same expression from different timeframes with built-in syntax. I think it's quite interesting.