Código de redação em russo. Prós e contras de um programa desse tipo. - página 3
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
1. Quantos anos você tem programado?
2. Você já tentou (para si mesmo) escrever um programa em russo?
A questão é: o estereótipo existe e não somos reféns dele?
É uma questão de atitude. Eu prefiro escrever em inglês porque é mais conveniente para mim em todos os sentidos. Apoiador, conciso, confuso, comunicativo.
Eu diria mesmo que sua relutância em escrever em inglês é um estereótipo, alimentado por uma falta de vontade de aprender inglês adequadamente.
Se as variáveis externas estiverem em russo, você pode encontrar ?????? se não houver fonte no sistema, por exemplo, no servidor.
1C - sim, o russo é de alguma forma mais familiar lá. Mas em outros idiomas somente em inglês (uma vez no final dos anos 90 tentei o Visual Basic "russo", desde então eu mesmo me curei).
Bem, você também pode escrever em russo no OOP.
Qual é a essência do corte na rejeição do OOP?
A essência do OOP é que o programador pode definir o escopo das variáveis. Se você ignorar isso, o que você ganha com isso?
Você tem que usar constantemente novos contadores e novas variáveis, porque você não controla mais o escopo.
Os nomes têm que ser escritos por mais tempo com sufixos e prefixos.
Você perde a capacidade de reutilizar o código (um dos pilares do OOP).
Isso não é tudo, é claro, mas em resumo.
Qual abordagem você prefere?
E, a propósito, se você estiver desenvolvendo um programa em vez de apenas digitar texto, a capacidade de transformar é importante. Com o OOP, você só precisa reescrever uma bíblia. Com outras abordagens, você deve modificar o programa inteiro.
Você também pode escrever em russo usando o OOP. Eu concordo. No entanto, tenho minhas próprias reivindicações em relação ao OOP. A eficácia reivindicada deste método foi completamente refutada em minha prática e eu rejeitei esta abordagem como ineficaz. Realmente, o OOP permite "humanizar" uma linguagem de programa, mas a enche de entidades desnecessárias de que a máquina não precisa em absoluto. Acontece ainda mais - estas entidades não são realmente necessárias para um ser humano e pode-se passar sem elas. Você está falando sobre o escopo das variáveis? Organize suas variáveis em uma matriz tridimensional global. Chame cada campo desta matriz de uma classe, e cada fileira de campos, digamos uma enumeração. Localizar o valor de cada variável seria muito fácil, assim como acessá-la...
Temos de pensar na transformação... Há uma idéia de fazer um mecanismo de software universal, que funcionará com um núcleo lógico. As cadeias lógicas serão prescritas no núcleo. O motor usará o kernel para acessar funções através de seus índices. Isto será muito fácil de transformar.
Veja o C++ avançado. É como se esta linguagem de programação já tivesse adquirido sua própria gíria. Provavelmente não há outra linguagem que tenha uma tal confusão de entidades. Se você fizer alguma pesquisa e deixar apenas o essencial nela, ela diminuirá por várias vezes. Consequentemente, se tornaria mais compreensível e acessível para a maioria das pessoas. Entretanto, tenho a sensação de que alguém não quer que esta linguagem se torne compreensível e acessível a todos e, portanto, a complica imensamente...
Muitas características estão dispostas em C++. Ainda é a linguagem principal do sistema e para poder escrever o que você quiser, várias características foram preservadas nele.
Do ACMe ao OpenCL e gerenciamento de roscas.
Se você quer OPO puro, bem-vindo ao C#.
O tópico inicial provavelmente não entendeu completamente os benefícios do OOP, ao contrário do método de programação de procedimentos adotado anteriormente. Antes do método processual, os programas eram escritos utilizando operadores de salto incondicional. E os programas escritos de tal maneira eram muito difíceis de depurar e de traçar a lógica de seu trabalho, eles eram até chamados de "prato de esparguete".
O princípio da minha abordagem é o seguinte:
1. indexamos chamadas a funções de software. Dividimos as funções em si naquelas que verificam eventos (funções lógicas, - retornar sim/não), funções processuais (funções executivas), e funções computacionais.
2. Criar o núcleo lógico sob a forma de uma matriz tridimensional global. Prescrevemos nele índices de funções lógicas em uma determinada hierarquia (divisão pela importância dos eventos que eles verificam: eventos globais e locais). Criamos uma espécie de perímetro desses eventos no campo do kernel.
3. Indexamos as funções processuais e computacionais nas extremidades das cadeias lógicas.
4. Crie um mecanismo lógico que faz loops ao redor dos eventos do perímetro no núcleo na freqüência do timer e chama as funções necessárias através de seus índices.
5. A reconstrução do programa consistirá apenas na reconstrução de cadeias lógicas específicas ou na construção de novas cadeias.
11 além do uni.
É claro.
Uma questão de atitude. Prefiro escrever em inglês, pois é mais conveniente para mim em todos os sentidos. Apoio, brevidade, busca de mal-entendidos, comunidade.
Eu diria mesmo que sua relutância em escrever em inglês é um estereótipo, alimentado por uma falta de vontade de aprender inglês adequadamente.
Eu li Dostoevsky em inglês. Esse não é o ponto em absoluto... Para mim, o russo é mais fácil de programar em um nível genético.
Não há problema, o 47º cromossomo é poder.
O OOP foi criado pelas pessoas mais inteligentes, os professores. Eles passaram anos afinando e modificando-o para adequá-lo às necessidades dos programadores, de modo que seria mais conveniente escrever programas.
O OOP da MQ também é refinado em termos de segurança de código.
Quer se tornar um profeta da nova religião? Não há problema, afinal é a sua hora.