Tratemos de utilizar las analogías más paralelas posibles a la “ciencia” (lo que hace la física, la química, la biología, etc.) y a la “ingeniería” (lo que hace la ingeniería civil, eléctrica, mecánica, bio, etc.).
Y también busquemos superposiciones interesantes. Por ejemplo, hacer puentes es “muy ingeniero”, pero una vez que se hace un puente, manifiesta “fenómenos” y los científicos pueden estudiarlo para hacer modelos que se manifiesten como los fenómenos. Herb Simon (tanto el Premio Turing como el Premio Nobel) escribió un excelente libro llamado “Las ciencias de lo artificial” que vale la pena leer.
Hoy en día es difícil hacer un “buen puente” sin ciencia profunda e ingeniería profunda, y algo de computación profunda, porque definitivamente queremos simular nuestra comprensión / modelos de puentes tanto para la edificación como para el éxito y la seguridad. Y a partir de estos mejores modelos, obtendremos mejores perspectivas sobre cómo diseñar y construir mejores puentes.
- ¿Vale la pena hacer un Máster en CS si tienes un BS / BA en CS? ¿Qué pasa si no tienes un BS / BA en CS?
- ¿Qué es mejor, CS en MSRIT o mecánico en Manipal (rama principal)?
- ¿Son los algoritmos de redes neuronales?
- ¿Por qué alguien preferiría una transmisión confiable regular sobre una transmisión confiable uniforme?
- ¿Cuáles son los casos documentados conocidos en los que un gato que camina por el teclado causó una interrupción importante en el servicio en línea o en el sistema informático?
Para agregar una nota histórica aquí, un acto temprano de la informática real sucedió cuando John McCarthy necesitó un lenguaje de programación para programar su interfaz de usuario “Advice Taker” a finales de los años 50, y quería que tuviera una forma matemática. Para hacer esto, hizo un modelo de computación y lo escribió como un comienzo en “Una teoría matemática de la computación”. Esto fue “muy ciencia” ! Steve Russell dijo: “Ese es un programa. Si lo programara, tendríamos un nuevo idioma ”. Como dijo McCarthy, “¡Lo hizo, y nosotros lo hicimos!”. El resultado fue Lisp, y también fue un “mejor puente” de lo que se estudió: el modelo sugirió formas mucho mejores de pensar sobre la programación que cómo FORTRAN lo hizo.
Supongamos que inventamos un lenguaje de programación y nos gustaría evaluar nuestro diseño lo antes posible en el proceso. Una forma de expresar el diseño es como modelo: es una especie de “teoría”. A diferencia de las matemáticas regulares, generalmente hay demasiados grados de libertad para las técnicas de prueba clásicas, pero podemos sacar mucho provecho de poder ejecutar nuestra teoría.
En este punto, hagamos una pausa para pensar en lo que estamos haciendo. Por un lado, estamos en algo muy parecido al proceso CAD-> SIM-> FAB que tienen las buenas disciplinas de ingeniería (y supongamos que tenemos herramientas poderosas similares para nuestro dominio). Podemos ver que la parte “FAB” del proceso para hacer que un lenguaje sea útil involucra muchos tipos diferentes de optimización para adaptarse a máquinas existentes, otros sistemas, etc. (muchas cosas). Esto es muy similar a lo que se debe hacer en el mundo físico para FAB: muchas cosas importantes importantes. Ahora, ¿qué podría ser “SIM”? ¿Qué tal hacer que nuestro lenguaje modelo CAD se ejecute lo más directamente posible en una supercomputadora para que podamos escribir programas serios (incluidos los en tiempo real) para ver cómo nos gusta nuestro lenguaje? (Tenga en cuenta que si hemos definido la semántica de nuestro lenguaje de una buena manera en la parte CAD, entonces nuestras herramientas deberían poder ejecutar más o menos directamente y simular el modelo).
Por otro lado, estamos muy interesados en los aspectos de “informática” de nuestro diseño. Si nos gusta la definición de Al Perlis (el primer ganador del Premio Turing): “la informática es la ciencia de los procesos” (¡se refería a todos los procesos!), Entonces nuestro CAD-> SIM nos permitirá investigar profundamente los fenómenos de proceso de nuestro diseño (¡y realmente necesitamos hacerlo!). Por ejemplo, poder programar sistemas paralelos complejos es una de las claves para progresar en el futuro, y los problemas están lejos de ser solo problemas de ingeniería: también son de naturaleza profundamente científica.
En resumen, no somos muy buenos en informática, pensando en informática o haciendo informática. Necesitamos obtener mejores diseños examinados y mejorados mucho más rápido. Para hacer esto, necesitamos tener una fase intermedia de “simulación” y las herramientas para acompañarla en cada proyecto que valga la pena hacer. Y tener esto sugerirá muchos proyectos que deberíamos estar haciendo pero que simplemente no podemos ver.
