¿La codificación es más difícil que las matemáticas?

Fui profesor asistente de matemáticas en un momento, pero ahora soy ingeniero de software. Trabajar con código ha sido generalmente más fácil.

Debe tener en cuenta que ambas actividades varían en una escala de extremadamente fácil a casi imposible, por lo que no es posible dar una respuesta absoluta a “lo que es más difícil”. La gente hace matemáticas muy fáciles a veces. Algunas personas hacen una codificación que es casi imposible.

Sin embargo, hay algunas circunstancias que tienden a facilitar el trabajo con código. Gran parte del trabajo de software más desafiante es difícil solo porque alguien ha creado un área de desastre. El ego a veces lleva a los ingenieros de software a escribir código que es inusualmente complicado. Sin embargo, dicho código suele ser demasiado difícil de mantener. Los buenos ingenieros de software intentan mantener su código más simple. El usuario también suele considerar que algunas de las características más simples de su producto son las más útiles. Por supuesto, existen desafíos con el desarrollo de dispositivos simples, pero de un tipo diferente. Entonces, cuando las cosas van bien, a menudo, como ingeniero de software, puede evitar los tipos de trabajos más difíciles.

Por el contrario, muchas de las cosas más difíciles de hacer en matemáticas son perfectamente naturales. Nadie tuvo que deslizarse para dificultarlo. A menudo, lo que lo dificulta es que uno tiene que tener la idea correcta para progresar. Incluso si la idea correcta no es tan difícil de resolver, una vez que la tenga, encontrarla puede llevar mucho trabajo. Las matemáticas también tienden a ser más abiertas en el extremo difícil de la escala.

En el extremo inferior, hay actividades en ingeniería matemática y de software que no se le pagará por hacer, porque son tan fáciles que se automatizan. Si hay que agregar muchos números, no lo hará; una computadora lo hará.

Sin embargo, algunas tareas de ingeniería de software relativamente básicas no son muy fáciles de automatizar. La gente trata de reducir la cantidad de código “repetitivo” necesario, pero si lees a los desarrolladores de software que describen sus trabajos, a menudo los escuchas describir que tienen que escribir una gran cantidad de código que es sencillo pero no lo suficientemente sencillo para alguien haber escrito una herramienta automatizada para hacerlo por ellos. Los desarrolladores senior a veces intentan filtrar las tareas más fáciles y hacer que los desarrolladores junior las hagan, pero esto solo funciona hasta cierto punto. Todavía hay momentos en los que necesito agregar una casilla de verificación a un panel, o algo similar, y también podría hacerlo. Hay pruebas automatizadas que deben escribirse, no porque sean complejas, sino porque son simples y, sin embargo, verifican dos veces alguna propiedad básica que se supone que tiene el código que están probando. Del mismo modo, uno necesita documentar o explicar lo que está haciendo, lo que puede no ser lo más fácil del mundo, pero es más una cuestión de mantener una buena comunicación que una gran complejidad.

En matemáticas, hay una cierta cantidad de “tareas domésticas” fáciles, como cuando escribe un documento y tiene que verificarlo por errores simples como escribir [matemáticas] v_i [/ ​​matemáticas] en lugar de [matemáticas] v_j [/ matemáticas] que no Actualmente no se automatiza tan bien. Sin embargo, parecía tomarme menos tiempo.

Cuando se trata de tareas de software muy mundanas, a veces se introduce una nueva forma de dificultad, a saber, la presión del tiempo. En lugar de hacer fácilmente algo como agregar una casilla de verificación a un panel, es posible que le digan que mantenga su cuota de elementos de panel por hora o algo similar a eso. Es una buena idea mantenerse alejado de los trabajos en los que se aplica este tipo de presión de tiempo para llevar el nivel de dificultad a un nivel preasignado.

¡No deberías necesariamente querer tener un trabajo fácil! Mientras la dificultad no sea artificial, es probable que tener algunas dificultades intelectuales en su trabajo lo haga más interesante. Los desafíos de un trabajo no siempre son lo que aparecen en la superficie. (Por ejemplo, ‘Soulcraft’ rinde homenaje al trabajo de un día honesto).

Es realmente difícil responder a una pregunta tan abierta. Como explicaron otros, realmente depende. Quisiera señalar un par de puntos al respecto.

La informática es esencialmente una rama de las matemáticas. Muchas personas que tienen educación secundaria no se dan cuenta, porque el tipo de matemáticas que estudias en la escuela se trata principalmente de números y funciones numéricas, especialmente en el campo continuo. La matemática es mucho más general que eso e incluye álgebra abstracta (más o menos similar a la teoría de conjuntos), representación y lógica del conocimiento, números discretos y funciones discretas, topología. La informática se ocupa mucho de estos temas. La programación en sí misma no es más que definir estructuras abstractas de álgebra.

Si CS te da miedo porque eres / no eras tan bueno en matemáticas en la escuela, considera que podrías ser mejor en este tipo de matemáticas (y me gusta mucho más, como a mí).

Los programadores (en su mayoría) no han sido codificados desde la década de 1950. La codificación codificaba las instrucciones del ensamblador en código máquina binario. Luego se inventaron los ensambladores simbólicos porque la codificación se podía automatizar, eliminándola. Todavía se podría decir que la codificación toma una especificación más abstracta de un programa y la traduce a ensamblador, pero luego nos dimos cuenta de que también podría automatizarse, por lo que inventamos lenguajes y compiladores de alto nivel.

Incluso antes de eso, las computadoras eran personas que seguían las instrucciones que los ‘ataúdes’ les habían dado. Esto se hizo particularmente en Bletchley Park en la Segunda Guerra Mundial al descifrar el código alemán Enigma (¡eso fue críptico!) Por WRENS que eran mujeres en la Royal Navy. Por lo tanto, la informática no tiene nada que ver con la electrónica, por lo que cualquier dificultad que surja de la electrónica no debería ser evidente en la programación. De hecho, son aquellos que dicen que deberíamos estar ‘codificando cerca del metal desnudo’ (lo que sea que eso signifique) quienes se equivocaron completamente. Bletchley Park (Turing) inventó el Bombe para automatizar y acelerar el proceso de descifrar el código (en realidad, eso era lo que ayudaban los ataúdes, no las computadoras). Y Tommy Flowers desarrolló nuevamente la ‘computadora’ Colossus para acelerar el proceso. Pero esa es la razón por la cual la electrónica es tan buena, porque ahora podemos hacer cosas millones (miles de millones) de veces más rápido. Pero la electrónica no se suma a la potencia computacional.

Entonces, realmente lo que hacemos ahora es programar, no codificar.

Tampoco debería gustarnos el término codificación porque implica transformarlo en algo críptico. Bueno, toda la idea de los HLL y los compiladores es que la fuente (texto o gráficos) del programa no es críptica, sino que comunica claramente nuestras intenciones del programa a los demás.

Pero tal vez esté pensando en algunos idiomas que tomaron prestada la sintaxis HLL, pero no el espíritu. C viene a la mente ya que tomó prestada la sintaxis de ALGOL, pero no entendió de qué se trataba HLL en un nivel semántico más profundo. Entonces, tal vez la gente todavía piense en escribir en C como codificación.

La programación se trata realmente de resolver problemas, no de generar instrucciones para una máquina o de hacer referencia a ubicaciones de memoria (punteros en C).

Tampoco existen las matemáticas. Como el profesor estadounidense Julius Sumner-Miller solía decir que no es matemática, es matemática, pero luego no es matemática, es matemática CON una ‘S’. (¿Por qué es así, profesor?)

Ahora los principios de programación son razonablemente sencillos. La programación estructurada (en el sentido original, no en los diagramas tontos, el sentido del marketing) se trataba de la verificación del software. Esto también se conocía como Hoare Logic:

Lógica de Hoare – Wikipedia

La programación estructurada requiere unidireccional y unidireccional de las cosas. Si bien eso no significa completamente que no haya gotos, significa usarlos en un sentido muy restringido. Estos sentidos restringidos realmente se asignan a muy pocas estructuras de control: secuencia, ramificación condicional, bucle, recursión (con recursión tampoco necesitamos estrictamente bucles). Entonces no necesitamos gotos en absoluto. El último caso de evitar mucho anidamiento debido a la comprobación de errores puede manejarse mediante mecanismos de excepción.

Todos los programas se pueden escribir de manera elegante y eficiente con estas muy pocas construcciones. La programación de esta manera ‘ayuda’ a mantener la programación simple. Pero surgen grandes proyectos, y los programadores (por razones principalmente dudosas, como ‘libertad’) tienden a romper estas restricciones (creo que principalmente porque no las conocen o no las entienden). Esto dificulta la programación, especialmente si necesita mantener o depurar el ‘código’ de otra persona. A veces, el mantenimiento se convierte en la decodificación del ‘código’ que alguien más ha producido, pero como he dicho, la programación no debe ser sobre ‘codificación’, sino sobre especificaciones claras.

En cuanto a las matemáticas, como han dicho otros aquí, ese es un tema mucho más amplio.