Does Sensetalk's rich set of reserved words help or hinder programmers?

Interesting article on Linked In today by David Knott, CTO UK Government, got me thinking about those of us programming in SenseTalk who don’t have English as our primary language and have to learn the idiom:

" Is programming a computer more like language or more like maths?

Neither, it turns out. In recent research, neuroscientists at MIT conducted brain scans of programmers while they were trying to solve problems, and discovered that, rather than engaging the language centres of the brain, they engaged a system known as the multiple demand network, usually used for complex problem solving.

Programming languages, it seems, are not the same as ordinary languages. This is not new news. In the earliest days of programming, when Grace Hopper was inventing high level languages, she and her team sent versions of their code to their bosses in French and German. The bosses sat up and paid attention: was it possible that their computers had suddenly learnt to speak foreign languages? Of course, that was not the case: the vocabulary of the programming language was entirely arbitrary: as long as the compiler could recognise the symbols and convert them into machine code, then they could be whatever the team wanted them to be. The team chose English words because they made it easier to understand (and because they were English speakers), but it was simple to tell the compiler to look for different symbols.

The difference between programming languages and human languages, despite their superficial resemblance, can be an obstacle to people learning to code for the first time, or for people using tools which resemble programming languages, such as spreadsheet macros or low code platforms.

When we speak to humans, precision is useful but not mandatory. Our speech is often very imprecise: circular, allusory, full of hesitation and digression. Yet other people can figure out what we mean: they interpret, and empathise, and fill in our gaps. By comparison, a compiler or code interpreter is brutally unforgiving. We cannot indicate vaguely what we mean: we must spell it out in excruciating detail, and any mistake is punished with error messages or bugs. Computers are frustrating because they do what we say rather than what we mean. " …

Read the rest of the article here:- The language illusion, doubled

Hello,
This resonates with the challenge non-native English speakers might face when navigating programming idioms in languages like SenseTalk . Precision and structure in code contrast sharply with the fluidity of human communication, making computers rigid interpreters that demand exact instructions.

1 Like

Hello,

This is a fascinating discussion, and David Knott’s points resonate deeply, especially when considering the experience of non-native English speakers learning programming languages like SenseTalk. Let’s break down the key takeaways and how they relate to SenseTalk:

  1. Programming vs. Natural Language:

MIT Research: The finding that programming engages the “multiple demand network” rather than language centers is crucial. It highlights that programming is primarily a problem-solving activity, not a linguistic one.
Arbitrary Vocabulary: Grace Hopper’s anecdote underscores the arbitrary nature of programming language vocabulary. While English words are often used for readability, they are essentially symbols that the compiler interprets.
Implications for Non-Native Speakers: This means that the “English-ness” of SenseTalk (or any programming language) is a superficial layer. The underlying logic and problem-solving remain consistent, regardless of the user’s native tongue.
2. Precision and Rigidity:

Human Language vs. Compiler: The contrast between the flexibility of human language and the rigidity of compilers is a significant hurdle. Humans can infer meaning from imprecise language, while compilers demand absolute precision.
Error Messages and Bugs: This rigidity can be particularly frustrating for non-native English speakers who may struggle with the nuances of English error messages or find it difficult to articulate their logic in precise English.
SenseTalk’s Readability: SenseTalk’s design aims for readability, which can be beneficial. However, even with a more natural-language-like syntax, the underlying requirement for precision remains.
3. SenseTalk and Non-Native English Speakers:

Learning the Idiom: While SenseTalk’s syntax is designed to be more approachable, non-native English speakers still need to learn the specific idiom and vocabulary of the language.
Conceptual Understanding: The focus should be on understanding the underlying programming concepts (variables, loops, conditionals, etc.) rather than memorizing English words.
Resource Availability: Providing resources in multiple languages or with clear, visual explanations can significantly aid non-native English speakers.
Community Support: A supportive community where users can ask questions and share solutions in their native languages can be invaluable.
Error message interpretation: Clearer error messages, and perhaps the ability to change error message language, would be very useful.

Best Regards