That happened to me early on, because earlier versions of Arc were written in CL. Within a month or so I found some CL operators intolerably verbose. And yet I'd been using CL for 15 years and had never had a problem with them. That was an interesting data point about how much one gets used to the language one uses. So much so that external constraints (e.g. counting tokens) are needed to force one to come up with ideas for improvements.
One funny thing is that I was not even used to one thing: a let just to bind one local at the head of a function really bugged me, so I would use &aux to avoid it.
But yeah, just a few weeks of arccing and I realized I was hitting myself in the head with a hammer and decided to stop, or rather, how much surprisingly nicer it was to just superabbreviate and de-parens the obvious.
Of course I try not to use LET (I think there is a tax on it) but I was doing a DSL which was always starting by picking a random entity that then got re=used a few times, so I was in Letville unless I wanted to go nuts and code-walk in my DSL.
> a let just to bind one local at the head of a function really bugged me, so I would use &aux to avoid it.
> Of course I try not to use LET (I think there is a tax on it)
In Cadence Skill, the lisplike we use in the office, 'let does have a tax to it when using lexical bindings; environments were pretty hefty objects and using 'let in a loop would generate a lot of them as garbage (the language implementation doesn't even have tail call opts!). I ended up using @optional (approximately equal to &optional) for some variables in time-constrained code, which helped reduce environments.
