¿Los ingenieros de software realmente necesitan saber cosas de bajo nivel? [cerrado]

A medida que se desarrollan lenguajes de programación de alto nivel como C #, Java, etc., muchas personas afirman que serán una alternativa a los lenguajes como el lenguaje ensamblador y C / C ++, que le brinda acceso y control al hardware de la computadora, porque los programadores deben enfocarse en crear el programa y resolver problemas, no perder el tiempo tratando con la computadora para que funcione. A medida que el hardware continúa mejorando, la diferencia de rendimiento entre C / C ++ y Java no será significativa, y los grandes juegos podrían programarse en un lenguaje como Java.

Esa es la idea general que resumo brevemente después de mirar este tema en Internet. ¿Crees que se hará realidad en un futuro cercano? ¿Eso significa que todo lo que aprendemos sobre cosas de bajo nivel ya no es práctico para la industria del software? ¿Eso significa que el lenguaje ensamblador y C / C ++ serán relevantes solo para los ingenieros eléctricos, ya que serían los únicos que necesitan programar sus componentes eléctricos?

---

¿Cuánto aprendizaje es suficiente? Si aprendemos demasiadas cosas de bajo nivel, eventualmente nos orientaríamos más en ingeniería eléctrica o si aprendemos demasiadas matemáticas, podríamos estar aprendiendo a ser matemáticos, no programadores. Solo quiero saber si las cosas de matemáticas que aprendí (tomé un curso de matemáticas que cubre el material similar a este libro (usaron diferentes libros de texto): Matemáticas discretas y su aplicación) son realmente tan útiles como nuestro conjunto de habilidades de programación. Muchos ejercicios de matemática pueden tomarnos la mayoría de las horas para hacerlo, y si lo toma en serio, tendrá menos tiempo para estudiar programación. En nuestro foro de gamedev, incluso las matemáticas y la física solo tienen una sección, ya que se compara con las de programación.

En este momento acabo de empezar a leer "El arte de la programación de computadoras". Las matemáticas solo se cubren en aproximadamente la cuarta parte del libro, pero el ejercicio es difícil para nosotros, no matemáticos. Incluso esas matemáticas "elementales", ¿las usamos tanto en nuestra carrera? Algunas personas probablemente me dirían que leer el libro TACOP es una pérdida de tiempo y probablemente debería dedicar tiempo a algo más práctico, a pesar de que el libro se trata de programación (un poco más académico en comparación con el libro explica cosas similares). Pero creo que el autor hizo un gran esfuerzo y esfuerzo para producirlo. Incluso puede escribir el conjunto completo de 5 libros, mientras que nosotros, el público, solo tenemos la misión de leerlo. Por qué no?

Interesante pregunta. Soy un programador de C ++ desde hace mucho tiempo que ahora trabaja en C # (con un poco de C ++ no administrado para el trabajo crítico de rendimiento), y históricamente he tenido que agregar un poco de código de ensamblaje ocasional, generalmente por razones de rendimiento.

Algunos puntos en la preparación de una respuesta a la pregunta:

• En aras de su comparación, sugiero que la distinción principal entre los lenguajes que menciona, C # y Java, del otro conjunto, Assembly, C / C ++, es que los primeros usan un tiempo de ejecución administrado para proporcionar recolección de basura. Existen otras diferencias (p. Ej., Portabilidad binaria, tamaño del marco y portabilidad), pero a medida que busca comparar las diferencias de rendimiento, este es un (¿?) El principal contribuyente.

• Assembly, C y C ++ están lejos de ser igualmente de "bajo nivel". Creo que tiene razón al asociar los lenguajes de ensamblaje y C con desarrolladores de hardware / firmware / controlador, pero C ++ generalmente se usa en un nivel superior y todavía es de uso intensivo , aunque claramente C # / Java lo están eliminando de acuerdo con TIOBE índice.

• En el nivel C ++, agregaría Objective-C, ya que es más parecido a C ++ que C # / Java. Finalmente, señalaría que con la adición de shared_ptr <> y otras características de administración automática de recursos, estos idiomas tienen soporte para algo cercano a la recolección de basura.

De acuerdo con su pregunta principal: ¿Realmente los ingenieros de software realmente necesitan saber cosas de bajo nivel?

Mi respuesta: sí

Razones:

• Incluso cuando use C # / Java, es probable que se encuentre con entidades de marco que requieren una administración de recursos explícita y / o problemas de gráficos de memoria "anclados" en cualquier aplicación no trivial. Debe comprender cómo funcionan estos sistemas para evitar y depurar estos problemas de manera efectiva.
• Las plataformas móviles tienen recursos más limitados, y aunque hay soporte para versiones limitadas de Java y .NET en algunos, el dominio actual de iOS y Objective-C sugiere una vida renovada por mucho tiempo.
• Rendimiento: cada vez que llegue a un muro de rendimiento, es probable que deba caer en un fragmento de código compilado de forma nativa para evitarlo.
• Soporte heredado: cada vez que necesite interoperabilidad para obtener acceso a una función no expuesta (todavía) en el código administrado, deberá hacer lo mismo.

Buena pregunta, pero no veo que los idiomas no administrados desaparezcan en el corto plazo.

• Ya es el caso de que alguien legítimamente no aprendería y no entendería la funcionalidad de nivel inferior, y aún sería un desarrollador muy productivo y valioso.
• Que nadie necesitará aprender o comprender la funcionalidad de nivel inferior, que siempre sería una pérdida de tiempo, nunca será el caso.

Como en cualquier disciplina de ingeniería, hay muchos pasos para el producto final, todos los cuales son importantes, requieren experiencia y son valiosos. En ingeniería de software en particular, tenemos muchas capas de abstracción. Todos son necesarios, y nadie puede ser un experto en todos ellos.

Dicho esto, necesitamos más desarrolladores de C # / Java / Ruby que los desarrolladores de Assemby / C. Para nosotros, los desarrolladores de "nivel superior", es útil comprender más sobre lo que sucede "bajo el capó" y nos hará mejores desarrolladores. Pero también muchas otras cosas . Como desarrollador de .NET, por ejemplo, hay tanto que puedo aprender que me hará más productivo, que estudiar nuestro lenguaje intermedio (mucho menos C ++ / C / Assmebly), aunque muy útil, a menudo tiene que pasar a un segundo plano.

Puede ganarse la vida hoy como programador sin conocer las cosas de bajo nivel. Creo que solo te hace un mejor programador para saberlo.

Sin embargo, mantener un alto nivel de competencia con las cosas de bajo nivel es cada vez menos importante. Quiero decir, no he hecho nada en asamblea en 20 años y probablemente necesitaría un repaso serio antes de poder volver a ser productivo, pero los conceptos generales de cómo funcionan las cosas a ese nivel todavía son parte de mi conciencia y encuentro Es útil de vez en cuando, incluso cuando se trabaja en idiomas de nivel superior.

No lo creo, los desarrolladores de kernel siempre necesitarán cosas de bajo nivel. Tampoco hace daño entender cómo funciona todo; si comprende fundamentalmente qué está haciendo realmente el código que está escribiendo, aprenderá a escribir un código mejor. Creo que eliminar las cosas de bajo nivel es una idea horrible, ya que este pensamiento abstracto es útil a veces, pero en realidad puede ser un obstáculo si desea que el problema se resuelva de la mejor manera. Por ejemplo, entender que cuando concatena cadenas realmente está creando cadenas nuevas es importante, pero si no comprende cómo se implementaron las cadenas, puede concatenar y esperar los 5 minutos que tarda su programa en ejecutarse. Este es un excelente artículo sobre cosas como esta: http://www.joelonsoftware.com/articles/fog0000000319.html

Esto depende de en qué esté trabajando realmente el ingeniero de software. Es posible tener una carrera productiva, feliz y rentable sin tener que tocar nada de bajo nivel ahora, pero eso no es todo trabajo de programación. Para que haya sistemas operativos y compiladores, debe haber ingenieros que trabajen en sistemas operativos y compiladores, y deberán conocer C, C ++ y el lenguaje ensamblador de su máquina.

El rendimiento también puede importar. Mi computadora portátil actual es aproximadamente un millón de veces más potente que la primera computadora de mi casa, y la ejecución del software aún puede llevar tiempo. Todavía puedo retrasarme en los videojuegos. Por supuesto, los videojuegos se ven mejor, porque cada uno de más de un millón de píxeles en la pantalla puede recibir uno de millones de colores (en lugar de mil posiciones de caracteres en blanco y negro, con algunos de los caracteres utilizados para gráficos ) Dudo que obtengamos un aumento mil veces mayor en la potencia de la computadora en el futuro cercano, y si lo hacemos, espero que sea utilizado por un software cada vez más complejo.

Si bien la mayor parte del software empresarial continuará siendo escrito en lo que es más rápido de producir y fuera de la puerta, que generalmente no es C, seguirá habiendo mucho espacio para los expertos en C y C ++.

"Con el hardware sigue mejorando, el rendimiento entre C / C ++ y Java no será significativo, y los grandes juegos podrían ser programados en un lenguaje como Java".

No creo que esa declaración sea correcta en el corto plazo. Siempre hay un éxito en el código administrado debido a las comprobaciones realizadas detrás de escena. Tampoco se trata de mejorar el hardware, ya que el hardware mejora, al igual que las aplicaciones que se espera que se ejecuten en ellos. Un sistema que está escrito en código nativo debe tener una interfaz para el código administrado. Hay un golpe de rendimiento que ocurre cuando se cambia entre los dos.

Sin embargo, solo un porcentaje generalmente pequeño de aplicaciones realmente necesita este código optimizado. La mayoría de las aplicaciones de línea de negocios están bien con cualquier código administrado, .net, java, etc. No significa que las aplicaciones que lo necesiten hagan el cambio pronto. Sin embargo, el ensamblaje escrito a mano ahora se usa mucho menos, ya que los compiladores optimizadores de C / C ++ son tan buenos. Sin embargo, recientemente hubo un sistema operativo escrito completamente en ensamblador, por lo que algunos todavía lo están haciendo. También es bastante importante en el campo de la seguridad.

Sin embargo, yo diría que para ser un desarrollador realmente bueno, uno debe entender lo que está sucediendo en un nivel bajo. Ayuda a solucionar algunos problemas difíciles, especialmente cuando se llama a código nativo.

Creo que conocer algunas cosas de bajo nivel es muy útil para la depuración, como, por ejemplo, con la programación Embebida, la mayor parte se hace con C, sin embargo, al depurar el ensamblaje de conocimiento para ese Micro controlador particular es extremadamente útil.

Cuando se inventaron las computadoras, solo unas pocas personas sabían cómo usarlas. Ahora, casi cualquier hogar en un país rico tiene 1 o más computadoras que pueden ser utilizadas por la persona promedio. Muchas personas comunes tienen trabajos trabajando en computadoras diariamente. La persona promedio tiene la capacidad de usar una computadora, pero aún necesitamos programadores.

Del mismo modo, el programador promedio no necesita saber o programar regularmente en lenguaje ensamblador. Esto es tanto una condición de habilidades comercializables como un saludo a lo lejos que hemos llegado en el mundo de la tecnología. Las empresas necesitan computadoras para automatizar las tareas. Por lo tanto, los programadores que pueden programar en .NET / Java tienen una gran demanda.

Las tareas que pueden automatizarse serán automatizadas. No todas las tareas pueden ser automatizadas. No toda la automatización es perfecta. Entonces, ¿es importante el ensamblaje? Por supuesto. ¿Es necesario ser un "programador"? Por supuesto no.

Hmmm, realmente disfruto aprendiendo cosas de bajo nivel.

Quizás no sea el símil más preciso, pero para mí es como aprender las maquinaciones dentro de un automóvil. Puede que no sepa cómo funcionan todas las piezas entre sí, pero es divertido saber que hay un motor, un cigüeñal, cilindros, diferenciales, grúas, frenos, aceite, combustión, refrigeración, y luego fricción, estrés, calor, fuerzas, ciencia: termodinámica, física, mecánica de fluidos ...

Tal vez no sea muy útil (no podré arreglar un automóvil sabiendo todo esto), ciertamente no es profesionalmente práctico, pero, bueno, divertido. L'art pour l'art: la connaissance pour la connaissance.

Creo que una regla práctica es: cuanto más rápido deba ser, menor será el nivel necesario.

Por lo tanto, su juego de disparos en primera persona con uso intensivo de gráficos, o su sistema algorítmico de comercio de FX, todavía tienen un nivel bastante bajo (C ++, etc.) porque la velocidad es la clave. ¿Pero la aplicación web que escupe un informe de ventas a tiempo? Demonios, podrías escribir eso en Sinclair BASIC, y aún sería aceptable.

No todos los trabajos de ingeniería de software son iguales . La gente que trabaja en sistemas operativos, compiladores, frameworks, controladores de dispositivos, sistemas integrados y computación científica de alto rendimiento realmente necesita saber 'cosas de bajo nivel'. Las personas que escriben formularios Access CRUD, o carritos de compras PHP para las tiendas Mom and Pop, tal vez no tanto. ¿Qué tipo de ingeniería de software quieres hacer y quieres hacerlo el resto de tu vida?

Mi opinión es que necesita aprender al menos un nivel de abstracción por debajo del nivel en el que trabaja habitualmente. Si trabaja en C / C ++, entonces debería elegir un poco de arquitectura y ensamblaje de la máquina. Si trabaja en PHP, entonces debe comprender HTTP y un poco de C / C ++ o Perl. Si Access es su pan de cada día, entonces será mejor que conozca algo de la teoría RDB, y tal vez un poco sobre COM o .Net. En algún momento de su carrera, eventualmente se detendrá en seco por un problema en un nivel más bajo de abstracción, y necesitará poder comunicarse al menos un poco con alguien que sea un experto en esa área. ¿Puedes "sobrevivir" sin estas cosas? Claro, pero planear "sobrevivir" en un mercado laboral competitivo es peligroso.

Yo mismo trabajo mucho en C # .NET y siempre me he alejado de C, C ++. Recientemente comencé a buscar trabajo y me sorprendió ver cuántos trabajos hay disponibles y requieren experiencia para C, C ++. Inicialmente pensé que C, C ++ se estaban volviendo obsoletos, pero mirando los trabajos disponibles, no parece que ese sea el caso.

Todos los lenguajes administrados que enumeró tienen intérpretes o máquinas virtuales escritas en C / C ++. Sin esos dos, la mayoría de los idiomas administrados o interpretados ni siquiera existirían. Yo diría que subestimas su valor.

Realmente odio la noción misma de un conocimiento "práctico" . Todo lo que aprendes es igualmente práctico. No importa si no va a operar a un nivel de abstracción cercano al hardware, simplemente conocer los conceptos de ese dominio siempre es beneficioso para construir nuevos conocimientos en otro nivel de abstracción. Cuantos más conceptos relacionados conozca, mejor.

Por lo que normalmente hago, C # es un lenguaje de muy bajo nivel, y lo considero algo muy parecido a un hardware. Pero aún creo que incluso mi conocimiento rudimentario y oxidado de la electrónica digital, el diseño de la CPU, etc., es muy útil para todo lo que estoy haciendo.

No, la mayoría no necesita hacerlo. Aunque la práctica de técnicas de bajo nivel le da al desarrollador un mejor conocimiento de lo que podría afectar el ciclo en su conjunto, hoy en día el desarrollador podría aprovechar ese tiempo para estudiar nuevas tecnologías, lo que a su vez requería conocimiento de cosas de bajo nivel para ser desarrollado pero no confiable. en.

En mi opinión, cuando usas una palabra "Ingeniero", te refieres al hombre / mujer que es quien diseña y construye las cosas desde cero. El verdadero problema de un ingeniero de software es resolver un problema, pero ¿qué problema? Es una gran pregunta.

Un desarrollador es diferente de un ingeniero en muchos aspectos. Un "desarrollador" es una persona que generalmente construye cosas en plataformas ya existentes. Desarrolla las plataformas existentes o construye nuevas plataformas heredadas de las antiguas, sin duda utilizando el componente de su sistema principal.

Un desarrollador generalmente piensa desde una perspectiva comercial, no es un científico. :) El desarrollador está más cerca del usuario del sistema, piensa las cosas desde la perspectiva del usuario y, por lo tanto, termina resolviendo los problemas del usuario utilizando la tecnología.

Un ingeniero inteligente. Es científico, resuelve un problema muy genuino. La mayoría de los problemas, qué computadora en sí misma lo tiene como característica. El usuario nunca nos acercamos a ese problema, está encapsulado. Los ingenieros son quienes abandonan sus estudios después de investigar mucho sobre el sistema existente y proponen algo nuevo para resolver el problema, si la solución lo requiere, si su sistema necesita un nuevo idioma, inventan un nuevo idioma porque el sistema existente no es capaz de resolviendo ese problema. Los ingenieros terminaron construyendo un sistema en el cual los desarrolladores construyen su sistema.

De hecho, un ingeniero de software necesita aprender y estar bien versado en cosas de bajo nivel ... :)

Mientras que un desarrollador, depende completamente de su interés. :)