edición general
14 meneos
78 clics

El gobierno de EE. UU. quiere que los desarrolladores dejen de usar C y C++ [ING]

La Agencia de Seguridad Cibernética y de Infraestructura de Estados Unidos (CISA) y la Oficina Federal de Investigaciones (FBI) anunciaron que estan redoblando sus esfuerzos para persuadir a los fabricantes de software de que abandonen los lenguajes de programación "inseguros para la memoria" como C y C++. El informe sobre malas prácticas de seguridad de productos advierte a los fabricantes de software que desarrollar "nuevas líneas de productos para uso en servicio de infraestructura crítica en un lenguaje inseguro para la memoria como C o C++

| etiquetas: eeuu , desarrolladores , c , c++ , memoria
Todos a Java :-D

No han sido capaces de quitar el COBOL van a poder quitar el C a golpe de decreto. xD
#1 Básicamente a rust, pero lo que dices, si el COBOL sigue ahí...
#2

To address this concern, CISA recommends that developers transition to memory-safe programming languages such as Rust, Java, C#, Go, Python, and Swift.

Yo lo decía en plan de broma, pero ellos lo dicen en serio.
#3 Unos lerdos

Lo que hay es que formar a los profesionales y no darles plazos imposibles
#2 Cobol esta tan bien parido y estructurado que en una tarde se puede generar un intérprete para cualquier plataforma presente y furtura .
Para manejo de datos por lotes , es seguro , robusto y fiable . Que tenga muchos años no indica que sea malo , todo lo contrario .

Rust ...no se ...quizás haga un mejor manejo de la memoria , pero al no tener límites definidos , lo que es una de sus ventajas , también es su talón de Aquiles .

Un lenguaje de programación útil no debe pecar de ser demasiado…   » ver todo el comentario
#8 COBOL está pensado para ser hiper robusto. Al punto que todos los errores son detectados en el momento de compilación. Si consigues compilar, es rarísimo que pueda haber luego algún bug.

C es su antítesis. Está pensado para dar completa libertad y acceso a la máquina, casi como un ensamblador universal. Su propósito es la programación a bajo nivel para un máximo rendimiento.

COBOL es ideal para programas de gestión de datos. C es ideal para SO, drivers, y cualquier cosa sujeta a máxima optimización de los recursos del hardware.

Dicho esto, lo que creo es que el gobierno de EEUU es un analfabeto digital, como nuestros gobiernos, y van soltado paridas como esta.
#11 No lo son , seguramente , pero tampoco tienen la capacidad .

Los movimientos en el mundo del soft provienen de momentos , necesidades y soluciones que beben siempre de momentos anteriores .

Creo que su llamamiento es bueno pero habrá que ver cómo progresa .

La llegada de la IA va a democratizar más el acceso a la programación y a la vez va a crear nuevas oportunidades para que se puedan dar pasos disruptivos a nivel minoritario que se extiendan más rápido .

Si tenemos en cuenta que por…   » ver todo el comentario
#12 #11

Me leo y me imagino que es difícil expresar todo lo que hay en mi cabeza y que me entienda alguien que por ejemplo no haya programado con una libreta y un lápiz durante días .

Ese esfuerzo , el de pensar antes de actuar , el de ahorrar en recursos por que después de tres horas los dedos duelen , el que te obliga a imaginar conceptos y tenerlos bien ordenados y claros en lugar de ir picando teclas sin pensar, se ha perdido y da igual que teclees cobol , c ,asm o Rust por qué no se tiene como concepto el de crear algo robusto desde el principio , se tiene solo el concepto de justificar horas de trabajo con líneas de código .

El problema no es c , ni rust ni java ...es que la programación se ha convertido en algo mediocre
#12 La IA va a ser un turbo en la introducción de Bugs en las aplicaciones
#11 Al punto que todos los errores son detectados en el momento de compilación. Si consigues compilar, es rarísimo que pueda haber luego algún bug.
Menuda trola... xD
#20 No has programado en COBOL en tu vida.
#21 Más que tú
#11

COBOL es ideal para programas de gestión de datos. C es ideal para SO, drivers, y cualquier cosa sujeta a máxima optimización de los recursos del hardware.

Ni de coña. Es un sistema obsoleto, lleno de limitaciones y que sigue ahí porque sus programas tienen más trampas que una pelicula de chinos.
#8

Cobol esta tan bien parido y estructurado que en una tarde se puede generar un intérprete para cualquier plataforma presente y furtura .
Para manejo de datos por lotes , es seguro , robusto y fiable . Que tenga muchos años no indica que sea malo , todo lo contrario .


Tengo la impresión de que no has trabajado con COBOL. Tiene más limitaciones que Feijoo y Abascal juntos.
#2 Rust no puede sustituir a C++
#0 Esto ya tiene unos cuantos meses:
- www.meneame.net/m/actualidad/no-mas-c-c-casa-blanca-pide-dejar-usar-le

Incluso el bueno de Bjarne Stroustrup ya salió en defensa de su churumbel:
- www.meneame.net/story/creador-lenguaje-c-critico-informe-nsa-sobre-len
#9 la respuesta no es sencilla. Hace 20 años todos los que desarrollaban venían de ingenierías, con muy buen conocimiento de arquitectura de computadoras, buena matemática discreta, algorítmica, gente que sabía ensamblador y entendía como funcionaba un procesador.

A día de hoy hay lenguajes y herramientas que te abstraen de todo eso para hacer más accesible la entrada a más personas. Sumado a gente que no tiene conocimientos formales; autodidactas, bootcamps, gente que viene de otros ámbitos laborales etc. Es un caldo de cultivo para el desastre.
#9 complementando a #10: hoy en dia (en general) no se busca que un programa sea fiable, esté bien diseñado, sea eficiente, use el potencial del hardware al maximo, etc, sino que saques una nueva version cada pocos dias para arreglar/tapar los bugs de la anterior. Para eso se usan fameworks que ocupan lo que no está escrito, porque son super generales. Y así te encuentras una aplicación como whatsapp o teams, que ocupan 200 MB cuando deberían ocupar 40.

Ademas que la mayoria de "programadores" tienen una idea extremadamente basica de computadores, redes,...
#13 #10 La cantidad de dependencias que tienen ahora programas hechos con los lenguajes "modernos" es para hacerselo mirar. Ya hubo (y habrá) ataques a la seguridad por ese lado. Y totalmente de acuerdo con vuestros comentarios, antes (20 años para atras) los que se dedicaban a la programacion sabian lo que hacian, si, C/C++ (y otros) eran inseguros, pero quien tocaba eso sabia mucho mas que la mayoria de programadores actuales. Habitualmente tengo que prestar ayuda a programadores, y sinceramente "flipo" con la falta de calidad de hoy en dia ... ah, y los nuevos lenguajes como Golang, son muy faciles de aprender, pero para una buena programacion requieren entender como funcionan internamente (si golang tiene GC)
#22

Y totalmente de acuerdo con vuestros comentarios, antes (20 años para atras) los que se dedicaban a la programacion sabian lo que hacian, si, C/C++ (y otros) eran inseguros, pero quien tocaba eso sabia mucho mas que la mayoria de programadores actuales.


sí, sí ... 20 años ... xD xD xD ¡35 hace que yo programaba en C! De hecho, yo soy de los que sigue dicendo UNIX en lugar de Linux.
#25 Me expresé mal, queria decir 20 años y más para atrás, aunque cuando lo escribia pensaba "buah, 20 años fue hace poco" ... yo tambien soy viejo, pero no tanto para llegar a 35 :-P
#26

A mí me costó su esfuerzo asumir que cuando hablabamos de "20 años atrás" eran los 2000 y no la época del Naranjito. :-D

Dentro de 15 años tendré que pensar que hablamos de los 20 y no de los 2000.
Pues estoy de acuerdo, hace 20 años los programadores sabían lo que hacían. No me quiero ni imaginar la de memory leaks, segmentation faults, null pointers y demás en la era del chatgpt. Que preparen la pasta en memoria ram y CPU que los GC no vienen gratis
#4 Una pregunta, tú crees que hoy e día no saben lo que hacen porque no hay buenos programadores o porque se desarrolla tanto software que con la demanda que hay muchos programadores son de nivel bajo medio. Es decir, en teoría debería haber más buenos programadores que hace 20 años pero claro, hace 20 años no había tantos de perfil bajo. Yo no soy programador eh, la pregunta no tiene ninguna intención de criticar lo que dices. También la cantidad de código y la segmentación debería tener que ver. Equipos mas grandes, supongo que descontrol mayor.
A ver quién tiene cojones a decírselo a Linus.
#6 Linux está de acuerdo con ir migrando el kernel Linux a Rust. De hecho, creo que ya hay módulos.

La inquina la tiene contra C++
#7 Con reservas ...seguramente veremos un kernel totalmente creado en Rust pero no será por parte de Linus ..el lo que da su bendición es a empezar a experimentar .

Seguramente veremos venir ese kernel por otro sitio , quizás un fabricante chino co Huawei haciendo algo alternativo

O quizás Apple , terminando lo que empezó con OSX y teniendo por fin un kernel propio
Lo que hace la ignorancia...
Yo soy viejuno, y barro para lo mío. El caso es que cuando he tenido que programar alguna herramienta para el trabajo he usado C. Es un dolor la gestión de memoria, pero he comparado la misma funcionalidad con Java y Python y la diferencia de velocidad es una animalada, de un par de minutos en C tratando ficheros enormes a más de 24h en Python y un par de horas en Java.
comentarios cerrados

menéame