Minha abordagem. O núcleo é o motor. - página 19
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
Muito bem. Digamos que estou convencido.
Em princípio, compreendi tudo isso por muito tempo. E eu concordo com isso. Entretanto, ao mesmo tempo, prefiro minha própria abordagem. Por quê?
Há uma razão em particular:
DESENVOLVIMENTO DE PROGRAMAS.
//---------------------------------------
A que velocidade o programa se desenvolverá com o OOP e com minha abordagem? Qual abordagem é mais favorável ao crescimento e à complicação dos mecanismos?
Concluí que minha abordagem + língua nativa no código (60% russo e 40% do inglês), dão um crescimento rápido máximo do programa.
Precisamente este crescimento rápido é o que eu preciso. Não escavar nos detalhes. Não apenas pairando sobre cada linha de código. Não é uma abordagem profissional.
Eu queria que o programa se desenvolvesse rapidamente e se tornasse mais complexo. Esses mecanismos seriam criados para desempenhar as funções a eles atribuídas. Rápido e fácil.
Para que você pudesse acrescentar novas características com algumas linhas de código.
Minha abordagem é superior à do OOP na solução desta tarefa em particular.
Por que você acha que sua metodologia permite um desenvolvimento rápido e fácil? Até agora eu vejo o oposto. Sobre o tema da complicação, concordo. Seu código é realmente difícil de entender.
Por que você acha que sua metodologia torna o desenvolvimento rápido e fácil? Concordo com a complicação. Seu código é realmente difícil de entender. Até agora, vejo o oposto.
E como estimar a complexidade da criação de uma máquina virtual (motor). Linguagem de marcação. Uma pessoa com uma abordagem ridícula pode criar isso? Mesmo com o OOP.
Quando você entender exatamente o que eu criei com minha abordagem, você entenderá quais oportunidades de desenvolvimento de programas ela oferece. (Eu não quero ser imodesto. É que, caso contrário, você não entenderia).
E como estimar a complexidade da criação de uma máquina virtual (motor). Linguagem de marcação. Uma pessoa com uma abordagem ridícula pode criar isso? Mesmo com o OOP.
Quando você entender exatamente o que eu criei com minha abordagem, você entenderá quais oportunidades de desenvolvimento de programas ela oferece. (Eu não quero ser imodesto. É que você não entenderia de outra forma).
OK, pelo menos você ainda não respondeu à pergunta. Vamos esperar por um código funcional e ver quanto tempo seu entusiasmo dura.
Quando você entender o que eu criei com minha abordagem, você entenderá as oportunidades de desenvolvimento do programa que ele oferece
Bem, o paradoxo é que ninguém pode entender o que você criou ) Exceto você, é claro )
Então o paradoxo é que ninguém pode entender o que você criou ) Bem, exceto você, é claro )
Eu desenhei muitas janelas, fiz um monte de vídeos sobre o construtor, providenciei um motor pronto com janelas, conectei o motor a um programa personalizado sem conhecer seu código. Preparando-se para fazer motores computacionais que assumirão a funcionalidade dos EAs, ainda assim, os programadores de fórum educados não entendem o que eu fiz).
É apenas uma espécie de ironia perversa)
Entretanto, o ramo não se trata do que eu criei, mas sim da abordagem. Mas, é impossível mostrar o poder da abordagem sem demonstrar as conquistas. O público não compreende totalmente as realizações. Isto é normal.
Para compreender as realizações, é preciso imaginar a complexidade do problema original. Vamos responder à pergunta: qual é a complexidade da criação de uma linguagem de marcação?
Para alguém que nunca o fez, pode parecer fácil, mas o que isso realmente requer?
Alguém sabe?
Vamos responder à pergunta: Qual é a dificuldade de criar uma linguagem de marcação?
Para alguém que nunca o fez antes, pode parecer fácil, mas o que é realmente necessário?
Alguém sabe?
Para seu idioma, não é muito. Para um programador, pode-se dizer que é uma tarefa de fim de semana.
Para seu idioma, um idioma pequeno. Para um programador, pode-se dizer, uma tarefa de fim de semana.
Bem, tal resposta eu assumi. No entanto, por que você ainda não criou uma linguagem de marcação? Você tem feito gráficos há muito tempo e não fez um idioma em um fim de semana).
Tanto quanto sei, suas janelas utilizam uma biblioteca gráfica padrão (a julgar pela aparência da mesma).
Quanto tempo você acha que demoraria para criar sua própria biblioteca gráfica a partir do zero?
Por exemplo, o Anatoly levou um ano e meio. E ele também usou o código de outras pessoas. A classe CCanvas, por exemplo.
Mas quanto tempo teria levado para que ele fizesse tudo do zero? Acho que pelo menos dois anos.
Somente a biblioteca, lembre-se. Não é uma linguagem de marcação.
Eu entendo que ainda não chegou à verificação e ao código fonte?
Ainda não. Chegaremos a isso em breve. Primeiro, gostaria de delinear a escala da tarefa na qual a abordagem teve que ser testada.