Interés y Humor - página 4550
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
¿y qué hay de malo en ello?
error 130
El representante del corredor afirma que es culpa del programador
y el cliente nos exige que arreglemos el "error" en el código.
error 130
El representante del corredor dice que es culpa del programador.
y el cliente exige que se solucione el "error" en el código.
Bueno, esa es una forma más divertida de hacerlo.
;)
.
Opinión: la programación orientada a objetos es un desastre de un billón de dólares
Según muchos, la POO es la joya de la corona de la informática. La solución perfecta para organizar el código. El fin de todos los problemas. La única forma verdadera de escribir programas. Nos lo ha dado el verdadero Dios programador.
Pero no lo es. Las personas empiezan a sucumbir bajo el peso de las abstracciones y de un complejo grafo de objetos modificables y separables al azar. Se pierde un tiempo y una energía preciosos pensando en abstracciones y patrones de diseño en lugar de resolver problemas del mundo real. Mucha gente critica la programación orientada a objetos, incluidos desarrolladores de software muy destacados. Incluso el propio inventor de este paradigma es conocido por sus críticas a la OOP moderna.
////
Opinión: las funciones en la programación son un desastre de un billón de dólares
Todo el código debe estar escrito de una sola pieza.
Y... No se deben utilizar matrices, sólo variables; de lo contrario, el programador estará fuera de control.
Y ahora que estamos eliminando la POO deberíamos volver a los sistemas operativos de una sola tarea. Al fin y al cabo, un programa que funciona en paralelo y de forma independiente es también un objeto de programa. No debería ser posible ejecutar varias instancias de un mismo programa - esto es k a t a s t r o f a .
Y esto... https://ru.wikipedia.org/wiki/Список_фобий - es el momento de añadir otra - oopofobia.
Hablando de pájaros...
Otra de las ventajas de la POO se abre cuando hay que pasar muchos parámetros a una función. Una cosa pequeña, pero aún así.
Opinión: las funciones en la programación son un desastre de un billón de dólares
Todo el código debe estar escrito de una sola pieza.
Y... No puede utilizar arrays, sólo variables; de lo contrario, el programa quedará fuera del control del programador.
Y ahora que estamos eliminando la POO deberíamos volver a los sistemas operativos de una sola tarea. Al fin y al cabo, un programa que funciona en paralelo y de forma independiente es también un objeto de programa. No debería ser posible ejecutar varias instancias de un mismo programa - esto es k a t a s t r o f a .
Y esto...https://ru. wikipedia.org/wiki/Список_фобий - es el momento de añadir otra - oopofobia.
Estás escribiendo tonterías, es como si no hubieras leído hasta el final.
Nadie ha escrito nunca en una sola pieza: la programación funcional es funcional porque requiere dividir el texto en funciones. El ideal de una función es que debe caber TODO su texto en la pantalla.
Las matrices y más allá siempre han existido, mucho antes de la POO.
Los sistemas operativos multitarea aparecieron a principios de los años 70.
Hoy en día, en R (no conozco otro), la ejecución en paralelo de múltiples instancias de funciones es estándar en la programación funcional. Además, puedes ejecutar sólo trozos de código en paralelo - yo mismo lo uso. Pero cómo ejecutar un "objeto" en paralelo es una pregunta, no puedo recordar, lo más probable es que no se puede.
Y por último.
Abra la documentación de µl y mire el índice, la lista de funciones.
Hablando de pájaros...
Otra de las ventajas de la POO se abre cuando hay que pasar muchos parámetros a una función. Una cosa pequeña, pero aún así.
En R no hay ningún problema con el paso de parámetros: puedes pasarlos uno a uno, puedes agruparlos en otros más complejos de diferentes tipos, puedes pasar una función como parámetro, puedes pasar el entorno (incluyendo el tipo de CPU, la versión del SO...) en el que se va a ejecutar el programa, como parámetro.
Termina de leer el artículo.
Estás escribiendo tonterías; es como si no hubieras leído hasta el final.
Nadie ha escrito nunca en una sola pieza: la programación funcional es funcional porque requiere dividir el texto en funciones. El ideal de una función es que debe caber TODO su texto en la pantalla.
Las matrices y más allá siempre han existido, mucho antes de la POO.
Los sistemas operativos multitarea aparecieron a principios de los años 70.
Hoy en día, en R (no conozco otro), la ejecución en paralelo de múltiples instancias de funciones es estándar en la programación funcional. Además, puedes ejecutar sólo trozos de código en paralelo - yo mismo lo uso. Pero cómo ejecutar un "objeto" en paralelo es una pregunta, no puedo recordar, lo más probable es que no se puede.
Y por último.
Abra la documentación sobre µl y mire el índice: la lista de funciones.
Ni siquiera he empezado a leerlo. Lea a todos los autores con un tejado jodido: el lector se caerá.
Antes había matrices, ¿y qué?
¿Y si un sistema operativo multitarea apareciera en los años 70? La OOP existía incluso antes. La multitarea significa que el sistema operativo carga el mismo programa en memoria una segunda (y tercera... etc.) vez, lo mismo que se hace en POO.
¡Tu-dunn! Si no sabemos nada más que R... ¿de qué podemos hablar?
En R no hay ningún problema con el paso de parámetros: puedes pasarlos uno a uno, puedes agruparlos en otros más complejos del mismo tipo, puedes pasar una función como parámetro, puedes pasar el entorno (incluyendo el tipo de CPU, la versión del SO...) en el que se va a ejecutar el programa como parámetro.
Termina de leer el artículo.
Aha... Al fin y al cabo, se puede agrupar...
Esos trozos de OOP que son comprensibles son buenos, ¿no? Y los que no son claros son malos, ¿no?