Vocabulário adequado para ajudar programadores iniciantes

Encontro-me ajudando programadores iniciantes com relativa frequência; explicando por que o código deles não funciona quando perguntam, sugerindo soluções e coisas do gênero. As pessoas que estou ajudando têm uma educação formal em programação a partir de um módulo de primeiro ano, em Java, mas sinto que não consigo me comunicar muito bem com elas.

Por exemplo: alguém pode escrever uma função, mas não entender por que ela não é executada, sem perceber que se esqueceu de chamá-la. Se eu usar frases como "(make a) call (to) the function/it"e "pass it the.."ficar com uma aparência em branco.

Meu processo normal seria encontrar algum lugar no código em que eles chamam uma função do idioma e dizer que eles podem chamar suas próprias funções da mesma maneira que chamaram essa outra função. Às vezes, até isso fica com uma aparência em branco.

Existem outras peças de vocabulário mais adequadas para (melhor?) Ajudar os programadores iniciantes? Ou isso não é uma questão de comunicação?

Eles terão que aprender os termos adequados eventualmente, quanto mais cedo melhor.

Use-os corretamente e explique-os sempre que receber um olhar vazio. Apenas tente enviar os sinais certos, que não há problema em perguntar sobre qualquer coisa que eles não entendam - as únicas perguntas estúpidas são aquelas que você não faz.

Em geral

Quando uma pessoa não entende você, você tem duas alternativas:

1. Adapte o vocabulário de acordo com o que a pessoa sabe ou não,

2. Explique à pessoa os termos que ela não entende.

O primeiro caso funciona bem quando a pessoa já conhece bem o vocabulário técnico, mas não o suficiente, ou não em seu domínio.

Por exemplo, você pode usar o termo método em C # ou Java, e a pessoa que trabalha principalmente com alguma outra linguagem não entenderia esse termo. Você explicará que, em C # ou Java, o método está se referindo ao que chamamos de função (por exemplo, em C), e que não existe função em C # ou Java . No PHP , por exemplo, existem métodos e funções e têm um significado diferente . Se a diferença for muito dolorosa para a pessoa, você falará sobre funções por uma questão de simplicidade.

No seu caso preciso, dificilmente você pode escolher o primeiro: "fazer uma chamada para a função" não pode ser reformulado de maneira mais simples. Uma chamada é uma chamada. Você não pode simplificar mais isso.

Isso significa que você deve escolher a segunda maneira: explicar à pessoa cada termo técnico.

1. Aponte a pessoa para um dicionário ou Wikipedia, que funcione muito bem para conceitos e terminologia básicos.

   Eu escolheria isso para termos comumente usados . Por exemplo, prefiro convidar a pessoa a ler a Wikipedia para entender o que é polimorfismo ou o que é covariância e contravariância. Esses termos já são explicados muito bem, portanto, não é necessário reinventar a roda aqui.

2. Ou explique com suas próprias palavras .

   Eu escolheria isso para termos específicos ao contexto e / ou aceitando uma ampla gama de definições . Por exemplo, a Wikipedia não é muito útil para entender a visão da Microsoft de computação em nuvem, e eu prefiro me explicar o que é nuvem para alguém que trabalhará em um aplicativo Windows Azure.

No seu caso particular

As pessoas com quem você está falando não possuem os conceitos e termos mais básicos usados ​​na programação. Eles não podem continuar sem aprender esse vocabulário básico , porque não conseguem se comunicar : não sabem ler livros sobre programação ou blogs, não conseguem ouvir seus colegas e nem mesmo podem fazer perguntas. Sites da Stack Exchange, pois ninguém vai entender o que está perguntando.

No seu caso, em vez de procurar um vocabulário adequado, eu passaria alguns dias ou semanas ensinando a eles alguns conceitos básicos de programação e os termos mais usados . Depois de alguns dias, você poderá conversar com eles sem precisar " constantemente desenhar-lhes desenhos e usar metáforas envolvendo gatos e cães" .

Em vez de funções , comece com sub - rotinas . Diga a eles que um programa é apenas uma lista de instruções, uma receita para informar ao computador como fazer alguma coisa. E que está sendo executada uma instrução após a outra (com a possibilidade de dar alguns passos em paralelo, mas mais sobre isso depois).

Algumas tarefas são bastante comuns e repetitivas, por isso seria terrível se tivéssemos sempre que anotá-las várias vezes, então escrevemos apenas uma vez e criamos um "programa menor" - uma sub - rotina que pode ser reutilizada por outras partes do programa. Para poder executá-lo mais de uma vez, atribuímos a ele um nome significativo em nosso programa. E então podemos usar esse nome quando queremos executar esse "pequeno programa" como parte de um maior, chamando -o por esse nome.

Chamar uma sub-rotina é como convocar um demônio que sabe como executar essa tarefa, com o nome desse demônio. Então, quando queremos fazer essa tarefa específica em nosso programa, escrevemos "chame o demônio chamado Argoth", e o demônio aparece e faz a tarefa para nós, conforme instruímos a fazê-lo, e depois vai embora e podemos continuar nossa trabalho.

Às vezes, o demônio exige algumas informações adicionais sem as quais ele não pode decidir qual das tarefas executar ou o que realmente queremos dele. Por exemplo, se o demônio deve construir um castelo, ele pode precisar saber onde ele deve construí-lo, ou quão grande , etc. Esses são os argumentos passados ​​ao demônio ... Quero dizer, a sub-rotina, que agora se torna parametrizado .

Parâmetros são aquelas informações que estão faltando, mas são necessárias, para executar a tarefa. Eles mudam o que a sub-rotina pode fazer um pouco. Eles são como espaços em branco na receita que precisam ser preenchidos antes que possamos executá-lo.

Os argumentos , por outro lado, são as informações reais (valores) que fornecemos para esses parâmetros.

Quanto à execução paralela, podemos pensar desta maneira: sempre há alguém (ou algo ) que está executando o programa (a lista de instruções). Ou é outro ser humano (você sabia que "computador" já foi o nome de uma pessoa que estava executando o cálculo?) Ou uma máquina. Um programa é apenas uma lista de instruções, não funciona por si só. Deve haver alguém ou algo que fará o processo computacional(execute essas ações da lista). E, às vezes, essas ações podem ser realizadas em paralelo - podemos distribuir as cópias da lista para várias pessoas e permitir que cada uma faça um conjunto diferente de tarefas da lista, desde que não se interrompam ou não Não é preciso esperar pelos resultados do trabalho de outra pessoa. Isso é multithreading para você;)

Quanto à diferença entre funções e sub - rotinas (também chamadas de procedimentos ), a diferença usual é que uma função está sendo chamada para calcular um determinado valor que ela retorna como resultado de sua execução, enquanto os procedimentos estão sendo executados apenas por diversão;) AKA pelos seus "efeitos colaterais" - apenas pelas operações realizadas na lista.

Mas se a chamada de um procedimento ou função causa algum problema no início, você pode usar outro termo que já foi popular: pular . Pode-se pular para uma sub-rotina, o que significa que você para de executar o que está fazendo no momento e "pula" para outro lugar da lista (ou outra lista) - a sub-rotina - para executar suas tarefas. Então, quando você termina, "pula para trás" - ou seja, volta ao local em que foi interrompido, para poder continuar com a tarefa anterior. A diferença entre chamar e pular é que agora você é o demônio.

Quanto aos métodos mencionados aqui por alguém, ou o fato de que algumas linguagens "não têm funções, apenas métodos" - isso não é correto, porque métodos são funções! - um tipo especial deles: são funções que estão sendo usadas para recuperar algumas informações encapsuladas dentro de um objeto ou operá-las. Eles são um "método de operação com esses dados". O nome veio do paradigma orientado a objetos, no qual os dados são incluídos nos objetos e não podem ser operados diretamente, apenas por funções especiais chamadas "métodos".

Um método é especial de uma outra maneira: ele precisa saber em qual objeto específico ele deve operar / ser chamado (o objeto "this"). É por isso que os métodos geralmente são embelezados com um parâmetro oculto adicional que armazena informações sobre o objeto no qual foi chamado (o ponteiro "this"). Isso complica a maneira como a função está sendo chamada um pouco, mas é um "detalhe de implementação" que um programador não deve se preocupar muito, desde que saiba o que está fazendo.