synonyms

[Mark Wieder]

On 07/04/2017 01:02 AM, Mark Waddingham via use-livecode wrote:

>>>> For a problem placed before any three coders, you will find at least 
>>>> four different solutions. Limiting the language limits the ways in 
>>>> which a problem may be thought of - that's the basis of the 
>>>> linguistic relativism, and it applies to programming languages as 
>>>> well as to natural languages.
>>
>> Of course.
> 
> Although I think Mark's original statement is conflating two things - 
> there is the *abstract* method of solution, and the *concrete* rendering 
> of the solution.

Well, yes and no.
I'm arguing for allowing the concrete solution in support of the 
abstract solution (see below).

> 
> In most cases you might get 'four different solutions' - however it is 
> more than likely that at least half of them will be the same if you 
> strip away all the concrete baggage (i.e. syntax, variable names, choice 
> of array of string-list etc.). Simply because abstractly there tends to 
> be far fewer ways to solve any one given problem (in computing at least) 
> than there is concretely, as computers think about things in a specific 
> way (which often is nothing like how humans do on an average day-to-day 
> basis).

Aside from the folding of several similar solutions into a single one as 
far as the computer goes (and I have no dissension there, nor any real 
need for any synonyms at that much of a context-free level), I think 
that allowing for more synonyms in the language allows at a human level 
(abstracted from the ones and zeros of the computer) for a more creative 
approach to viewing possible solutions to any given problem. So that a 
faster or more elegant or more functional or... solution may arise that 
may not have come about without the natural-language associations of the 
synonym(s). For instance, "is" may evoke associations that "=" does not, 
and vice versa. For me "<>" evokes BASIC and I tend to think more 
linearly, where "is not" has different connotations, as does "!=", even 
if they all condense to the same machine code.

For the same reason, I use "switch" constructs more than nested or 
sequential "if"s when possible, partly because they're easier for me to 
read afterwards and therefore easier to maintain, but also because they 
impact my thought processes differently, even though they become the 
same machine code as far as the silicon is concerned.

-- 
  Mark Wieder
  ahsoftware at gmail.com