¿Programación de la puesta de sol? - página 7
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
¿Qué estás discutiendo conmigo ahora? ¿Que el programador se ha convertido gradualmente en un desarrollador, con un aumento del número de herramientas y requisitos de las tareas?
No lo he negado.
Me limité a hacer algunas preguntas que se desprenden lógicamente de sus tesis.
Sólo hacía algunas preguntas que se desprenden lógicamente de sus tesis.
Bueno, sí, cada industria se desarrolla y sigue su propio camino. Incluido el desarrollo de software. Aquí hay una buena definición de la wiki, por cierto:
Eldesarrollo de software es el proceso de concebir, especificar, diseñar,programar,documentar,probar ycorregir errores que implica la creación y el mantenimiento deaplicaciones,marcos de trabajo u otros componentes de software.
Se utiliza desde hace unos 30 años. Usted describe una tarea muy especializada y la extrapola a toda la clase de tareas de desarrollo. El desarrollo visual existe desde hace mucho tiempo, tanto parcial como totalmente automatizado. Esto no niega en absoluto la necesidad de desarrollar otras clases de tareas o incluso tareas resueltas por entornos visuales, a las que se aplican mayores requisitos de rendimiento, por ejemplo. Porque cualquier universalismo se convierte tarde o temprano en un monstruo.
Supongamos que tienes razón. Veamos ejemplos de tareas que no pueden:
1. descomponer en objetos.
2. representar objetos como conjuntos de parámetros y relaciones.
3. Ensamblar los objetos con herramientas visuales.
Si no es difícil, pon ejemplos de esas tareas.
Te responde para trollear, no para entender algo, no pierdas el tiempo - Peter y Fedoseyev son dos de los representantes más brillantes de mql sandbox, que no quieren salir de él.
Cada vez que surge una pregunta que no puedes responder y te hace ver que tus puntos son insostenibles, es trolling. Es curioso.
Bueno, sí, cada industria se desarrolla y sigue su propio camino. Incluido el desarrollo de software. Aquí hay una buena definición de la wiki, por cierto:
Eldesarrollo de software es el proceso de concebir, especificar, diseñar,programar,documentar,probar ycorregir errores que implica la creación y el mantenimiento deaplicaciones,marcos de trabajo u otros componentes de software.
En otras palabras, los programadores (o desarrolladores) no escribían la documentación, no hacían pruebas y no corregían los errores. ¿Y ahora se dedican al diseño?
Digamos que tienes razón. Veamos ejemplos de tareas que no pueden:
1. descomponer en objetos.
2. Representar objetos como conjuntos de parámetros y relaciones.
3. Ensamblar los objetos con herramientas visuales.
Si no le importa, dé algunos ejemplos de esas tareas.
No, Peter. El futuro pertenece a la programación biológica. Se trata aproximadamente de lo siguiente: un hombre se afeita la calva, se le coloca una biomasa activa especial en la cabeza y comienza a pensar intensamente en la tarea que tiene entre manos. Como resultado, en la biomasa depositada en la cabeza, se construyen conexiones neuronales, se forma una especie de ganglios artificiales, correspondientes a los pensamientos que se piensan... Así se crearán las unidades bioinformáticas para los ciborgs. ))) Bueno, ya sabes lo que quiero decir.
1. El desarrollo visual existe desde hace mucho tiempo, tanto parcial como totalmente automatizado.
2. esto no niega en absoluto la necesidad de desarrollar otras clases de tareas o incluso tareas resueltas por entornos visuales a las que se aplican mayores requisitos de rendimiento, por ejemplo.
3. Porque cualquier universalismo se convierte tarde o temprano en un monstruo.
1. Si puedes, dame un enlace para leer sobre ello.
2. ¿Puede desglosar los problemas por clases e indicar específicamente qué soluciones no son susceptibles de ser utilizadas con herramientas visuales?
3. No todo es tan sencillo. Un enorme ordenador de los años 50 cabe en un teléfono móvil, lo que sugiere que el universalismo funciona bien y no está rígidamente ligado al rendimiento. En cualquier caso, la actuación resuelve el problema del universalismo de los monstruos.
Digamos que tienes razón. Veamos ejemplos de tareas que no pueden:
1. descomponer en objetos.
2. representar objetos como conjuntos de parámetros y relaciones.
3. Ensamblar los objetos con herramientas visuales.
Si no es difícil, dé ejemplos de esas tareas.
Calcular números de Fibonacci, crear ciertas reacciones de la UI a las acciones del usuario fuera de un conjunto predefinido, escribir documentación, escribir pruebas unitarias.
Se trata de tareas muy sencillas, pero hay sistemas enormes, por ejemplo, de renderización de imágenes, etc.
Hay muchos, en general.