5 ms·
TIME Since time is the most limited human resource, maybe the best metric for the most powerful language would be that programming language which, overall, sa
by gibsonf1 19y ago
TIME
Since time is the most limited human resource, maybe the best metric for the most powerful language would be that programming language which, overall, saves the most time in creating, maintaining, and improving a program. Using "saving time' as the standard of value, PG's use of fewer nodes and less lengthy names both help in creating programs with less time, so ARC seems to be right on.
I intuitively like the lengthier names in CL for readability, but at the end of the day, you still have to not only know them all through memorization, you also have to know the order of parameters and keys, which is not consistent among all functions/macros in CL. So having shorter names to memorize, and more importantly fewer, would definitely save time in the learning stage.
The question I don't know the answer to is how fast can ARC be changed, maintained, and improved, but I'm guessing this will also be faster.
- davidw 19y agoSounds like a good way of measuring things, although I harbor some doubts as to the conflicts inherent in "creating" vs "maintaining", with Perl being the whipping poster boy for throwaway code.
- andreyf 19y agoTIME Agreed. These are all correct ways of defining the same thing (the "power" of languages), and we need to pick whichever is useful depending on what we're trying to do. If we're trying to put a precise measure on the power of a language, PG's treelength seems to do the job perfectly. But how do we design a language which would create programs with the smallest tree length, or which would take the least time to write it? To answer this, it's best to consider how easily our basic mental structures can be expressed in the language. The concept of sets, lists, map, and reduce exist in our lives whether we know program or not. If a language contains or lets us easily express other embodied mental structures such as relations, tags, partitions, etc. easily, it will be more powerful than languages which don't.
- bayareaguy 19y agoI think the problem with the Power=Work/Time approach for programming languages is you can never get people to agree on how to measure Time. Whose time? What does it include?