¿Está muerta la ciencia de la informática? [cerrado]

Pregunta: ¿La ciencia y el arte de CS están muertos? Con eso quiero decir, los requisitos reales para pensar, planificar y resolver problemas de manera eficiente parecen estar alejándose de CS en estos días. El campo parece estar bajando la barrera de entrada para que más personas puedan 'programar' sin tener que aprender a programar realmente.

Antecedentes: soy un recién graduado con una licenciatura en Ciencias de la Computación. Estoy trabajando en una posición inicial en una empresa de tamaño decente en el departamento de TI. Principalmente hago .NET y otras tecnologías de Microsoft en mi trabajo, pero antes de esto hice cosas de Java a través de pasantías y similares. Personalmente, soy un programador de C ++ para mis propios proyectos divertidos.

En profundidad: a través del trabajo que he estado haciendo, me parece que las disciplinas intensas de una ciencia real ya no existen en CS. En el pasado, los programadores tenían que resolver problemas de manera eficiente para que los sistemas fueran robustos y rápidos. Pero ahora, con las tecnologías predominantes como .NET, Java y los lenguajes de secuencias de comandos, parece que la eficiencia y la solidez se han cambiado para facilitar el desarrollo.

La mayoría de los colegas con los que trabajo ni siquiera tienen títulos en Informática. La mayoría se graduó con títulos de Ingeniería Eléctrica, algunos con Ingeniería de Software, incluso algunos que vinieron de escuelas tecnológicas sin un programa de 4 años. Sin embargo, se las arreglan bien sin tener la formación técnica de CS, sin haber estudiado teorías y algoritmos, sin tener en cuenta la posibilidad de crear una solución elegante (solo buscan la solución más fácil y barata).

La compañía nos empuja a usar tecnologías de Microsoft, que eliminan todo el pensamiento real del asunto y lo reemplazan con bibliotecas y herramientas que pueden construir automáticamente su proyecto la mitad del tiempo. No estoy tratando de odiar los idiomas, entiendo que tienen un propósito y lo hacen bien, pero cuando sus empleados no saben cómo funciona una tabla hash y usan los métodos de clasificación incorrectos o ejecutan comandos SQL que son terriblemente ineficientes (pero hacen el trabajo en un tiempo aceptable), parece que se está poniendo más esfuerzo en desarrollar tecnologías que mimetizan a los nuevos 'programadores' en lugar de enseñarles a las personas cómo hacer las cosas bien.

Estoy interesado en hacer programas eficientes y, en mi opinión, hermosos. Si hay una mejor manera de hacerlo, prefiero volver y refactorizarlo que dejarlo pasar. Pero en el mundo corporativo, me empujan a completar tareas rápidamente en lugar de con elegancia. Y eso realmente me molesta.

¿Es esto lo que espero con ansias el resto de mi vida? ¿Todavía hay puestos disponibles para las personas que aman la ciencia y el arte de la CS en lugar de solo el sueldo?

Y en la misma nota, aquí hay una buena lectura si no la has visto antes de The Perils Of Java Schools

Si y no

Buena pregunta, pero mala suposición.

Parece que falta la parte científica de la educación, pero la suposición de que la ciencia estaba allí simplemente para hacer que los programas sean eficientes es errónea.

La ciencia era necesaria para enseñar a las personas cómo definir y resolver problemas.

Lamentablemente, esta parte de algunos currículos de "CS" (¿currículos?) Parece omitirse por completo, reemplazarse por problemas de juguetes con soluciones triviales o conocidas, y tiene la intención meramente de enseñar la familiaridad con las herramientas.

Decepcionante; muchos graduados de la escuela Java tuvieron cambios cortos, nunca se les enseñó cómo descomponer un problema, diseñar un algoritmo, especificar una prueba o incluso depurar de manera efectiva.

¿Está muerta la ciencia de la informática? "..." Soy un recién graduado con una licenciatura en informática. Estoy trabajando en una posición inicial en una empresa de tamaño decente en el departamento de TI .

Honestamente, mis dos centavos: no encontrarás la "ciencia" de la informática trabajando en un departamento de TI en una empresa de tamaño decente, porque es el departamento de TI, no el departamento de CS. Intente volver a la escuela para obtener un doctorado, o trabajar en los departamentos de ingeniería de una empresa cuyo enfoque es la informática (por ejemplo, procesamiento de imágenes, redes de alto rendimiento, sistemas de álgebra informática, aeroespacial, etc.). Aquí es donde encontrará los problemas difíciles e interesantes donde el diseño descuidado [en general] no será tolerado.

"¿Todavía hay puestos disponibles para las personas que aman la ciencia y el arte de CS en lugar de solo el sueldo?

Sí, absolutamente, pero probablemente no en los departamentos de TI de empresas medianas.

Si eres programador, no te consideres un "científico de la computación"; los informáticos son los que crean la próxima generación de computadoras, algunas de las cuales siguen siendo ciencia ficción hasta que se obtenga la combinación correcta de materiales, miniatuización y teoría computacional. Son solo el comienzo de la tubería. Las personas que desarrollan software aquí y ahora son "ingenieros de software"; toman las teorías y las herramientas, a veces superponiendo la teoría práctica y las herramientas del mundo real para aprovechar el poder en potencia de esta compleja pieza de magia electroinica y hacer que haga lo que queremos. Esa es, a su vez, una especialización del campo de la "ingeniería informática", que toma las teorías de los científicos informáticos y las aplica, hardware y software, a soluciones electrónicas para usuarios finales del mundo real.

Esto es, OMI, donde los negocios se encuentran con la teoría. En este tipo de casos, el viejo adagio "el enemigo de lo mejor es lo suficientemente bueno" se puede cambiar fácilmente para leer "el enemigo de lo suficientemente bueno es mejor". Considerándose un "ingeniero" en lugar de un "científico", y poniendo lo que hace en paralelo con otras disciplinas de ingeniería, pone de relieve las diferencias.

Digamos que un cliente acude a usted, un ingeniero civil / estructural, y le pide que construya un puente. El puente debe abarcar 20 pies, sostenerse y una tonelada de carga, debería durar 10 años con mantenimiento de rutina, y lo quieren en un mes por $ 20,000. Esas son tus limitaciones; cumplir con los mínimos sin exceder los máximos. Hacer eso es "lo suficientemente bueno" y te da el sueldo. Sería una ingeniería deficiente para usted construir el Puente Golden Gate, superando con creces tanto las especificaciones de diseño como el presupuesto en varios órdenes de magnitud. Por lo general, terminas comiendo los excesos de costos y pagando multas por excedentes de tiempo. También sería una mala ingeniería para usted construir un puente de cuerda con el peso de 5 hombres adultos a pesar de que solo cuesta $ 1000 en tiempo y materiales; no obtienes buenas críticas y testimonios de clientes,

De vuelta al software, supongamos que tiene un cliente que necesita un sistema de procesamiento de archivos creado para digerir los archivos que ingresan y poner la información en el sistema. Quieren que se haga en una semana y tiene que manejar cinco archivos al día, alrededor de 10 MB de datos, porque ese es todo el tráfico que obtienen actualmente. Tus preciadas teorías en gran medida salen por la ventana; su tarea es crear un producto que cumpla con esas especificaciones en una semana, porque al hacerlo también cumple con el presupuesto de costos del cliente (ya que los materiales son generalmente una gota en el cubo para un contrato de software de este tamaño). Pasar dos semanas, incluso diez veces la ganancia, no es una opción, pero lo más probable es que tampoco lo es un programa construido en un día que solo puede manejar la mitad del rendimiento, con instrucciones de tener dos copias en ejecución.

Si crees que este es un caso marginal, estás equivocado; Este es el entorno diario de la mayoría de los usuarios. El motivo es el ROI; Este programa inicial no cuesta mucho y, por lo tanto, se amortizará rápidamente. Cuando los usuarios finales lo necesitan para hacer más o ir más rápido, el código se puede refactorizar y escalar.

Esa es la razón principal detrás del estado actual de la programación; La suposición, confirmada por toda la historia de la informática, es que un programa NUNCA es estático. Siempre deberá actualizarse y eventualmente será reemplazado. Paralelamente, la mejora constante de las computadoras en las que se ejecutan los programas permite una menor atención a la eficiencia teórica y una mayor atención a la escalabilidad y la paralelización (un algoritmo que se ejecuta en tiempo N cuadrado, pero que se puede paralelizar para funcionar en N núcleos) parece lineal y, a menudo, el costo de más hardware es más barato que el de los desarrolladores para diseñar una solución más eficiente).

Además de eso, existe el principio muy simple de que cada línea de código de desarrollador es algo más que puede salir mal. Cuanto menos escribe un desarrollador, menos probable es que lo que escribe tenga un problema. Esto no es una crítica de la "tasa de errores" de nadie; Es una simple declaración de hecho. Es posible que sepa cómo escribir un MergeSort hacia atrás y hacia adelante en 5 idiomas, pero si usa solo un identificador en una línea de código, todo el Sort no funciona, y si el compilador no lo captó, podría llevarlo horas para depurarlo. Contraste eso con List.Sort (); está ahí, es eficiente en el caso general y, aquí está lo mejor, ya funciona.

Por lo tanto, muchas de las características de las plataformas modernas y los principios de las metodologías de diseño modernas se construyeron con esto en mente:

• OOP: cree datos y lógica relacionados en un objeto, y donde sea que el concepto de ese objeto sea válido, por lo que es el objeto o una derivación más especializada.
• Plantillas preconstruidas: un buen 60% o más de código es un sintaxis sintáctico y lo básico para que el programa muestre algo en la pantalla. Al estandarizar y generar automáticamente este código, reduce la carga de trabajo del desarrollador a la mitad, lo que permite un aumento de la productividad.
• Bibliotecas de algoritmos y estructuras de datos: al igual que en lo anterior, puede saber cómo escribir una pila, una cola, QuickSort, etc., pero ¿por qué tiene que hacerlo, cuando hay una biblioteca de código que tiene todo esto incorporado? No volvería a escribir IIS o Apache porque necesitaba un sitio web, entonces, ¿por qué implementar un algoritmo QuickSort o un objeto de árbol rojo-negro cuando hay varias implementaciones excelentes disponibles?
• Interfaces fluidas: en la misma línea, es posible que tenga un algoritmo que filtre y clasifique los registros. Es rápido, pero probablemente no sea muy legible; a su desarrollador junior le tomaría un día comprenderlo, y mucho menos hacer el cambio quirúrgico necesario para clasificar en un campo adicional en el objeto de registro. En cambio, las bibliotecas como Linq reemplazan una gran cantidad de código muy feo, a menudo frágil, con una o dos líneas de llamadas a métodos configurables para convertir una lista de objetos en objetos filtrados, ordenados y proyectados.

Me parece que estás haciendo TI y no CS y eso no debería implicar que CS está muerto. CS no está muerto, es solo que la mayoría de los trabajos están en desarrollo de software. Como la mayoría de los estudiantes de CS aprenden a programar, generalmente terminan contratados como programadores y no como informáticos. Los trabajos de informática son minúsculos en comparación con los trabajos de programación. Incluso podría hacer una aplicación compleja utilizando técnicas informáticas, pero en mi opinión (y no me gustan las respuestas de opinión porque son subjetivas), eso cae en el campo de la ingeniería que en el campo de los científicos.

Además, el código hermoso y elegante está en el ojo del espectador , pero para la mayoría de las empresas / gerentes, tener un diseño lo suficientemente bueno a tiempo es mucho más importante que un código hermoso pero nunca termina a tiempo.

Por último, está el mundo real y lala-land. Desafortunadamente, recibimos el cheque de pago del primero, y ahí es donde entra la "ciencia / arte" del desarrollo de software sobre cómo producir alta calidad de software con limitaciones de tiempo / presupuesto. Sentí el mismo tipo de sentimientos que tienes al comienzo de mi carrera. Siempre quise crear "lo mejor", pero pronto me di cuenta de que "lo mejor" no es el diseño más eficiente o elegante, sino el más rentable.

En primer lugar, te equivocaste. "pensar, planificar y resolver problemas de manera eficiente" no es ciencia, es ingeniería. La ciencia es mucho más sobre explorar nuevos campos. Y, en realidad, en el mundo académico, a la gente le importa mucho menos la eficiencia del código, mucho menos que a la industria. En la academia se trata más de pruebas de conceptos, etc.

No, lo que está describiendo es que se requiere un conocimiento menos profundo para el desarrollo de software. Lo que podría ser cierto, si los requisitos fueran los mismos. Pero hoy en día, se espera que el ingeniero de software sepa cómo lidiar con subprocesos múltiples, computación distribuida, escalado, etc. Se espera que sepan cómo liderar el proyecto de manera eficiente. La mayor parte de esto no estaba en los planes de estudio hace unas décadas.

No creo que lo que haya dicho sea exactamente correcto, pero de todos modos tiene algo de sentido. Específicamente, creo que con el tiempo, la informática y la ingeniería de software se han distanciado.

La ingeniería de software (como otras ingenierías) se trata de aplicar la ciencia para construir productos, resolver problemas, etc. La informática se trata principalmente de la investigación de algoritmos y (aunque esta parte a menudo se olvida algo) cómo implementar esos algoritmos (al menos en un sentido teórico - por ejemplo, quizás tratar todas las máquinas PRAM como equivalentes).

Teniendo esto en cuenta, creo que la razón detrás de la bifurcación se hace evidente: la mayoría de los problemas algorítmicos involucrados en algo como un sitio web típico ya se han resuelto, la mayoría de ellos, hace mucho tiempo. Quizás lo más importante es que la mayoría de ellos se han resuelto lo suficientemente bien como para que el desarrollador web promedio, el problema haya desaparecido casi por completo. Por ejemplo, hacer actualizaciones atómicas en bases de datos distribuidas definitivamente no es una tarea trivial, pero un desarrollador web típico simplemente escribe algo de SQL y no tiene idea (o preocupación) sobre la cantidad de investigación que tomó para descubrir cómo hacer el trabajo confiablemente

Hubo un tiempo en que era esencialmente imposible separar la informática de la ingeniería de software. Se habían resuelto tan pocos problemas que escribir incluso un programa relativamente trivial requería investigar los fundamentos. Si deseaba hacer algo tan simple como ordenar un grupo de datos a fines de los años 50 o principios de los 60, era muy probable que tuviera que hacer un análisis de sus datos e intentar diseñar un algoritmo que se ajusta lo mejor posible a lo que se necesitaría para clasificar esos datos en particular; ni siquiera se conocían tantos algoritmos de clasificación como hoy, e incluso los algoritmos que se conocían no se conocían tan bien como lo son hoy .

Sin embargo, 50 años de investigación y desarrollo han valido la pena: la mayoría del desarrollo típico puede usar no solo algoritmos conocidos, sino implementaciones preescritas. La mayoría de los problemas típicos se pueden resolver de manera bastante razonable basándose en el conocimiento existente (e incluso en las implementaciones existentes) de algoritmos.

Sin embargo, eso no significa que la informática esté muerta: todavía hay más algoritmos para investigar y las personas que investigan en ellos. Sin embargo, sí significa que la mayor parte de la investigación es más especializada y solo es probable que se aplique a áreas bastante especializadas. Probablemente también haya una mayor "brecha" entre la adquisición y la aplicación del conocimiento. En un momento, descubriste una mejor manera de clasificar en el proceso de escribir un programa de clasificación, y fue escrito en código real casi de inmediato. Ahora, mucha ciencia de la computación se dedica a cosas como cómo usar un número esencialmente infinito de procesadores, lo que probablemente será útil algún día, pero incluso las tribus primitivas no contarían los núcleos duales en mi computadora como "muchos" ... :-)

El desarrollo de software y la informática no son lo mismo, y descubrí que la mayoría de mis compañeros de clase en un B.Sc. El programa Comp Sci se sintió frustrado por esto.

Pienso en el software como un producto de la informática ... como las pinturas son un producto del arte visual.

Creo que la mayoría de las personas con títulos de CS son contratados para realizar trabajos de desarrollo de software, especialmente en las primeras etapas de sus carreras. Creo que mucha gente en este rol se queda allí y no va más allá.

Creo que la diferencia comienza a aparecer cuando aparecen nuevos problemas o paradigmas o cuando "juntarlos" no es lo suficientemente bueno. ¿Quién construye los nuevos marcos o lenguajes? ¿Quién se sienta y explica los detalles de un nuevo motor de física? ¿Quién usa la teoría de grafos / transformaciones de grafos para calcular algunos ciclos por iteración de rendimiento de un algoritmo?

Terminaré donde comencé, aceptando que hay muchos científicos informáticos en roles de desarrollo / ingeniería de software, tal vez no estén a la altura de su potencial.

Parece confundir la informática con la programación y el desarrollo de software en general. Los dos no son lo mismo, ni siquiera cerca. Independientemente de lo que digan nuestros títulos, la gran mayoría de nosotros somos programadores, no informáticos. A menos que esté involucrado activamente en la academia a un alto nivel, apuesto a que realmente no tiene idea de lo que está sucediendo en informática.

Puedo decirte que la informática está viva y bien. Tengo que resolver nuevos problemas a diario y encontrar una solución eficaz y elegante para esos problemas. Tengo que usar mis habilidades como ingeniero a diario y usar el conocimiento de mí y mis colegas para resolver esos problemas para nuestro cliente.

No estoy tratando de odiar los idiomas, entiendo que tienen un propósito y lo hacen bien, pero cuando sus empleados no saben cómo funciona una tabla hash y usan los métodos de clasificación incorrectos o ejecutan comandos SQL que son terriblemente ineficientes (pero hacen el trabajo en un tiempo aceptable), parece que se está poniendo más esfuerzo en desarrollar tecnologías que mimetizan a los nuevos 'programadores' en lugar de enseñarles a las personas cómo hacer las cosas bien.

Esto suena como un problema con el empleado y ciertamente no es cierto para todos los programadores.

El hecho de que existan herramientas que hacen que nuestro trabajo sea más fácil no significa que no debamos comprender la tecnología de subrayado, si no lo hacemos, no estamos ayudando a nadie y ciertamente no estamos haciendo nuestro trabajo para resolver los problemas de la manera correcta.

Simplemente no has entendido el problema en cuestión. El problema no es obtener el máximo rendimiento, sino obtener el rendimiento suficiente para que su aplicación responda y sea lo suficientemente rápida. Aprender a programar se trata de resolver el problema, por la menor cantidad de dinero.

Odio decirlo de esta manera, pero cualquier impresión que tenga sobre la muerte de CS es solo su propia preconcepción de lo que un programador "real" debería tener que hacer.

Bueno, muerto o no es discutible!

El hecho es que en la era tecnológica actual, la mayoría de las empresas contratan personas para resolver tareas del tipo de flujo de trabajo del mundo real a través de la automatización del software. No están interesados ​​en qué tan elegante o rápido puede escribir un programa, siempre y cuando permita que el negocio se ejecute más rápido con mayor producción.

los estrés está en más salida en menos tiempo. (Piense en la comercialización de cultivos / alimentos; crecimiento más rápido y más rápido con menos costo). Lo mismo está sucediendo en el mundo tecnológico (la próxima nueva idea).

Recuerde, hoy en día, las cosas se están moviendo más rápido que nunca debido a la cantidad y el acceso al conocimiento que antes. En aquellos viejos tiempos, la producción era pequeña y mejor, las ganancias eran mayores. Ahora, el juego ha cambiado por completo. Basta con mirar las cosas como la calidad del servicio al cliente y, en general, las cosas no duran más.

La elegancia y la eficiencia son importantes para las empresas tecnológicas como Google, etc., mientras que incluso esos lugares no son perfectos, pero puede acercarse a ellos trabajando en una de esas empresas en los próximos años.

Siempre hay un compromiso en la vida. Puede encontrar un trabajo que pague menos, donde tenga todo el tiempo y atención. O bien, elige nadar con el resto de nosotros para pagar mejor e ignorar las cosas que no son perfectas. Cuanto más rápido se dé cuenta de esto, podrá prepararse para el mundo real. No digo que debas ignorar la calidad y la elegancia, sino conocer la dinámica. Serás más feliz :)

En mi opinión, algunas de las cosas más interesantes que podría deparar el futuro se basarán sin duda en la parte científica de la informática, específicamente en la mejora de la visión por computadora / aprendizaje automático y otros algoritmos de sematización. Estos probablemente se impulsarán en la industria (por ejemplo, tome el Microsoft Kinect), pero son problemas tan enormemente difíciles que ciertamente se basarán en la gran cantidad de investigación y progreso realizado en el mundo académico (nuevamente, tome el Microsoft Kinect).

Creo que la programación estándar del día a día es casi tanto un arte como una ciencia, pero ciertamente existen áreas que están profundamente interesadas en los aspectos científicos de la informática. Por ejemplo investigadores para empresas y universidades. Si realmente quieres involucrarte profesionalmente en las ciencias, entonces debes buscar un doctorado. Sin embargo, he encontrado que las partes científicas de mi educación son continuamente valiosas, ¡a pesar de que también necesito confiar en mi lado más creativo en la realidad!

Las personas que no saben lo que están haciendo pueden hackear las cosas con algunas de las herramientas que mencionó, pero generalmente contratan a personas reales de CS para hacer las herramientas, solo tiene que ser más abstracto para realmente esforzarse.