Interessante e Humor - página 4550
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
Nenhuma outra razão para além de RIDDICKS? :-)
E que tal isto?
2024, por volta de Abril. Há um utilizador na rede com uma legenda sob o seu avatar
"Qualquer trabalho de joelhos, levantar de joelhos, pôr de joelhos".
e o que é que isso tem de errado?
erro 130
O representante do corretor alega que a culpa é do programador
e o cliente está a exigir que corrijamos o "bug" no código.
erro 130
O representante do corretor diz que a culpa é do programador.
e o cliente exige a correcção do "bug" no código.
Bem, isso é realmente mais divertido.
;)
.
Opinião: a programação orientada para objectos é um desastre de triliões de dólares
De acordo com muitos, OOP é a jóia da coroa da ciência informática. A solução perfeita para a organização do código. O fim de todos os problemas. A única forma verdadeira de escrever programas. Dado a nós pelo verdadeiro Deus da programação.
Mas não é. As pessoas começam a sucumbir sob o peso das abstracções e de um gráfico complexo de objectos modificáveis ao acaso. O tempo e a energia preciosos são desperdiçados a pensar em abstracções e padrões de design em vez de resolver problemas do mundo real. Muitas pessoas criticam a programação orientada para objectos, incluindo programadores de software muito proeminentes. Mesmo o próprio inventor deste paradigma é conhecido pelas suas críticas ao OOP moderno.
////
Opinião: as funções na programação são um desastre de triliões de dólares
Todos os códigos devem ser escritos numa só peça!
E... As matrizes não devem ser utilizadas, apenas variáveis; caso contrário, o programador estará fora de controlo.
E agora que estamos a acabar com o OOP, devemos regressar aos sistemas operativos de tarefa única. Afinal de contas, um programa que funciona em paralelo e independentemente é também um objecto de programa. Não deve ser possível executar várias instâncias de um programa - isto é k a t a s t r o d a
E isto... https://ru.wikipedia.org/wiki/Список_фобий - é tempo de acrescentar outro - oopofobia.
Por falar em aves...
Outra vantagem do OOP abre-se quando se tem de passar muitos parâmetros para uma função. Uma coisa pequena, mas ainda assim.
Opinião: as funções na programação são um desastre de triliões de dólares
Todos os códigos devem ser escritos numa só peça!
E... Não pode utilizar matrizes, apenas variáveis; caso contrário, o programa estará fora do controlo do programador.
E agora que estamos a acabar com o OOP, devemos regressar aos sistemas operativos de tarefa única. Afinal de contas, um programa que funciona em paralelo e independentemente é também um objecto de programa. Não deve ser possível executar várias instâncias de um programa - isto é k a t a s t r o d a
E isto...https://ru. wikipedia.org/wiki/Список_фобий - é tempo de acrescentar outro - oopofobia.
Está a escrever disparates, é como se não tivesse lido até ao fim.
Nunca ninguém escreveu numa só peça: a programação funcional é funcional porque requer a divisão do texto em funções. O ideal de uma função é que ela deve caber TODO o seu texto no ecrã.
Arrays e mais além sempre existiram, muito antes do OOP.
Os SO multitarefa apareceram no início da década de 70.
Hoje em dia, em R (apenas não conheço outro), a execução paralela de múltiplas instâncias funcionais é padrão na programação funcional. Além disso, pode correr apenas pedaços de código em paralelo - eu próprio o utilizo. Mas como gerir um "objecto" em paralelo é uma questão, não me consigo lembrar, muito provavelmente não se consegue.
E por último.
Abra a documentação µl e veja o índice - a lista de funções.
Por falar em aves...
Outra vantagem do OOP abre-se quando se tem de passar muitos parâmetros para uma função. Uma coisa pequena, mas ainda assim.
Em R não há problema em passar parâmetros: pode passá-los um a um, pode agrupá-los em mais complexos de diferentes tipos, pode passar uma função como parâmetro, pode passar o ambiente (incluindo tipo de CPU, versão do SO...) no qual o programa vai ser executado, como parâmetro.
Acabar de ler o artigo.
Está a escrever disparates; é como se não tivesse lido até ao fim.
Nunca ninguém escreveu numa só peça: a programação funcional é funcional porque requer a divisão do texto em funções. O ideal de uma função é que ela deve caber TODO o seu texto no ecrã.
Arrays e mais além sempre existiram, muito antes do OOP.
Os SO multitarefa apareceram no início da década de 70.
Hoje em dia, em R (apenas não conheço outro), a execução paralela de múltiplas instâncias funcionais é padrão na programação funcional. Além disso, pode correr apenas pedaços de código em paralelo - eu próprio o utilizo. Mas como gerir um "objecto" em paralelo é uma questão, não me consigo lembrar, muito provavelmente não se consegue.
E por último.
Abra a documentação em µl e veja o índice - a lista de funções.
Ainda nem sequer comecei a lê-lo. Leia todos os autores com um telhado aparafusado - o leitor vai cair.
Então já existiam matrizes antes, e depois?
Então e se nos anos 70 aparecesse um sistema operacional multitarefa? O OOP existia ainda antes. Multitarefa significa que o sistema operativo carrega o mesmo programa na memória uma segunda (e terceira... etc.) vez, a mesma coisa que é feita no OOP.
Tu-dunn! Se não soubermos mais nada além de R... de que é que podemos falar?