5 ms·

That's part of why I focus on code size. Length is an external constraint. If you start looking at code thinking "what is the lower bound on how long this has t

by andreyf 19y ago

That's part of why I focus on code size. Length is an external constraint. If you start looking at code thinking "what is the lower bound on how long this has to be?" you're one step from discovering the new operator that will make it that short. Paul: Give us a peek into your head... how do you go about discovering new operators? Do you go to set theory or algebra books for inspiration, or look over lots and lots of code with an open mind? Also, how do you decide if a new operator that ought to be something "easily added" or a part of the language? remove-if-not seems to be something in the former category.

pg 19y ago
That is a good question. I plan to write about that one day. I'm not entirely sure. I think the process is mainly negative: I look at code that feels bad, in the sense of being unneccessarily long. If you remove the unnecessary bits, what's left is a call to the new operator. One specific heuristic I have is that I love things that make it possible to put functionality into actual functions that can then be passed as arguments, rather than having it stuck in the middle of a loop. Programs are easier to rearrange that way. So : notation for composition and [..._...] for closures are double wins. They're not only shorter, but also encourage the use of functional arguments. Maybe triple wins, actually, because they both get rid of variables, which is an especially good way to make programs shorter. You have to iterate, because sometimes a new operator will make it possible to define more new operators that compress code further. Occasionally a big piece of code just collapses, like cotton candy in your mouth. I put stuff in the language if I use it a lot in applications. A lot of the operators in arc.arc are on probation, because they seem like they might be useful, but I haven't actually used them much so far.

by andreyf 19y ago

pg 19y ago

That is a good question. I plan to write about that one day. I'm not entirely sure. I think the process is mainly negative: I look at code that feels bad, in the sense of being unneccessarily long. If you remove the unnecessary bits, what's left is a call to the new operator. One specific heuristic I have is that I love things that make it possible to put functionality into actual functions that can then be passed as arguments, rather than having it stuck in the middle of a loop. Programs are easier to rearrange that way. So : notation for composition and [..._...] for closures are double wins. They're not only shorter, but also encourage the use of functional arguments. Maybe triple wins, actually, because they both get rid of variables, which is an especially good way to make programs shorter. You have to iterate, because sometimes a new operator will make it possible to define more new operators that compress code further. Occasionally a big piece of code just collapses, like cotton candy in your mouth. I put stuff in the language if I use it a lot in applications. A lot of the operators in arc.arc are on probation, because they seem like they might be useful, but I haven't actually used them much so far.