Menéame: comentarios [4029986]

#83 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

--633161-- — Sat, 22 Feb 2025 23:12:15 +0000

#39 Por supuesto, no se me ocurriría hacer un ERP en C o C++

Pero el titular implicaba pedir que no se trabajase en esos lenguajes sin matizar nada más.

Me he hinchado de hacer librerías en ensamblador para COBOL que tiene un manejo pésimo de strings, al menos el que usaban en mi empresa, o para capturar datos de puertos seriales y convertirlos en pulsaciones de teclado o cosillas que necesitaban mucha velocidad cuando solo disponías de un Commodore 64, como el test ese del psicotécnico donde tienes que manejar dos coches a la vez.

Pero no me imagino hacer un programa de nóminas o de contabilidad en un lenguaje de tan bajo nivel.

» autor: --633161--

#82 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

spacos — Sat, 22 Feb 2025 11:42:00 +0000

#81 Que quieres que te diga, si usas un dialecto de c++ recortado como bien dices porque el c++ "normal" es mu tocho, ejem... . De nuevo, que me parece bien que useis C++, pero yo, si pudiera lo evitaria en todo lo que me fuera posible e intentaria pillas placas con sdk mas amigables que C.
de hecho ADA y un dialecto SPARK, se usan para proyectos donde el rendimiento y la seguridad son claves.

» autor: spacos

#81 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

Penetrator — Sat, 22 Feb 2025 08:24:41 +0000

#80 que yo sepa c++ no se usa en microcontroladores justamente por ser demasiado tocho

Pues en mi empresa lo usamos. Y de tocho nada, todo depende de las características de C++ que utilices. De hecho, existe un dialecto de C++, embedded C++, especificamente diseñado para esta clase de aplicaciones, y que básicamente consiste en un subconjunto de C++.

» autor: Penetrator

#80 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

spacos — Sat, 22 Feb 2025 07:50:52 +0000

#79 Si, pero estais perdiendo una burrada en dinero por cada mirocontrolador... Por otro lado que yo sepa c++ no se usa en microcontroladores justamente por ser demasiado tocho. Y plataformas como arduino usan un pseudo C o python asi que tal mal no iran. Placas como rasberry usan python para programar la placa. Supongo que en tu empresa usais microcontroladores donde el fabricante solo te da C como sdk para programarlos. Podrias pedirle si tienen lenguajes alternativos o si se pueden usar sdk alternativos genericos. De todas formas mi experiencia me dice que aquellos que defienden un lenguaje es porque no saben/quieren cambiar nada que lo que ya saben, lo cual es lógico. Pero ya te digo que c se esta convertitiendo en en nuevo cobol y que solo se usa por inercia, probablemente algun tipo de python que compile a nativo o go con adaptaciones acabaran imponiendose...

» autor: spacos

#79 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

Penetrator — Fri, 21 Feb 2025 21:02:07 +0000

#78 El código escrito en C/C++ es infinitamente más mantenible y portable que el ensamblador. Básicamente, C y C++ son el punto medio entre "lenguaje de bajo nivel con excelente rendimiento pero difícil de programar y mantener" y "lenguaje de alto nivel fácil de programamr y mantener pero con rendimiento papupérrimo".

» autor: Penetrator

#78 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

spacos — Fri, 21 Feb 2025 19:00:50 +0000

#77 Sobre costes todo es relativo. Si con lua hago el desarrollo y mantenimiento de forma mucho mas rápida y sencilla tambien ahorro costes. No todo es hardware. Si quieres rendimiento pues programalo todo en ensamblador y tendrás ese rendimiento excepcional que buscas, ahora bien, preparate a mantener ese software. Yo creo que todo es relativo, si tu empresa pone por delante los costes de hardware, pues perfecto, pero ya hay alternativas eficientes que no son C. Ahora recuerdo que plataformas como arduino tienen micropython tambien.

» autor: spacos

#77 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

Penetrator — Fri, 21 Feb 2025 18:38:39 +0000

#76 ¿Para que quieres que rinda?

Pues, por ejemplo, para poder ponerle el micro menos potente (y por lo tanto más barato) posible. En mi empresa ocurre constantemente. Si hay que meter un micro en una placa electrónica siempre se va al menos potente posible, porque aunque la diferencia de precio entre ese y el inmediatamente superior sea pequeña, al multiplicar ese coste por miles de placas te sale una burrada de dinero.

Lisp puede compilarse, pero tiene recolector de basura. No sé si es opcional o no, pero si no lo es entonces tampoco sirve para aplicaciones en tiempo real, que es para lo que se suelen usar los microcontroladores.

» autor: Penetrator

#76 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

spacos — Fri, 21 Feb 2025 18:30:26 +0000

#75 ¿Para que quieres que rinda?, si te funciona para lo que quieres, pues ya está (que es lo que hacen los fabricantes). Si no te gusta lua tienes tambien lisp:
www.ulisp.com/show?3M

Hay alternativas, es querer usarlas.

» autor: spacos

#75 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

Penetrator — Fri, 21 Feb 2025 18:18:40 +0000

#73 Lua es un lenguaje interpretado, igual que Java. Dudo muchísimo que su rendimiento en un microcontrolador se acerque siquiera al de C o C++.

» autor: Penetrator

#74 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

DORO.C — Fri, 21 Feb 2025 16:14:27 +0000

.....

» autor: DORO.C

#73 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

spacos — Fri, 21 Feb 2025 16:01:22 +0000

#58 Para microcontroladores ya hay alternativas, por ejemplo:
eluaproject.net/
Que es en lua. La idea es querer. No se trata de que c/c++ sea mejor, se usa por inercia y comodidad. No hay nada inerente en el lenguaje c/c++ que lo haga especial para microcontroladores, solo que es lo que se ha usado siempre...

» autor: spacos

#72 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

barcelonauta — Fri, 21 Feb 2025 14:55:34 +0000

Rust es el grafeno de los lenguajes de programación. Hasta en la sopa.

» autor: barcelonauta

#71 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

Penetrator — Fri, 21 Feb 2025 14:15:38 +0000

#70 Yo me refiero a los punteros inteligentes, que tienen un impacto en el rendimiento casi nulo.

Los shared pointers tienen un pequeño impacto porque tienen que realizar el conteo de referencias cada vez que se crean o destruyen, pero los unique pointers son gratis, no afectan al rendimiento para nada.

» autor: Penetrator

#70 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

rafaLin — Fri, 21 Feb 2025 14:05:56 +0000

#20 Pero el rendimiento sufre mucho, no sé si con Rust pasará lo mismo.

Yo trabajé programando en C una red neuronal (hace 25 años, antes de que se pusiera de moda), la diferencia entre hacerlo en C o C++ era abismal (probamos otros lenguajes, pero nada podía competir con C). Optimizamos las multiplicaciones de matrices y la gestión de memoria todo lo posible, pero lo que dio mejor resultado fue cambiar la gestión de multitarea del propio Linux, quitándole todas las protecciones para que fuera mucho más rápido, conseguimos que el entrenamiento pasara de 2 meses a 2 semanas.

» autor: rafaLin

#69 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

musg0 — Fri, 21 Feb 2025 12:57:54 +0000

#65 Asumía que se entendería que estoy hablando de programar todo un programa o sistema operativo en ensamblador, y no sólo partes críticas. Intenta portar Linux a tantos sistemas como en los que funciona si se hubiera hecho TODO en ensamblador de 386, por ejemplo. Imposiblemente costoso.
Como ejemplo de que algo parecía buena idea en su día, pero resultó no serlo tanto me gusta el emulador zsnes, programado íntegramente en ensamblador. En su día era lo mejor porque era rapidísimo y su "competidor", el snes9x, era más lento. Ahora zsnes está prácticamente muerto y snes9x además de estar portado a muchas máquinas tiene muchas mejoras que hacen la emulación más perfecta sin tener que meter parches según el juego que se esté ejecutando como hacía zsnes

» autor: musg0

#68 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

--712564-- — Fri, 21 Feb 2025 11:10:20 +0000

#62 Solo una cosa, supongo que eso depende mucho de los objetivos, para una aplicación de móvil igual puedes tener mucha sobrecarga de código para hacerlo seguro.

Si quieres exprimir el rendimiento de algo, es fácil que tengas que hacer "guarradas", y lo pongo entre comillas porque no creo que realmente estén bien o mal, simplemente son fuentes de problemas, pero lo considero malo en sí mismo.

Esto me recuerda a que supuestamente los chinos sacan mayor rendimiento a las tarjetas de nvidia porque pasan de su API.

» autor: --712564--

#67 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

--712564-- — Fri, 21 Feb 2025 11:06:57 +0000

#1 Según se mire es lo mismo que hacemos en diseños físicos, redundancia, margenes de seguridad, etc.

» autor: --712564--

#66 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

Penetrator — Fri, 21 Feb 2025 10:25:42 +0000

#60 Porque el problema se está enfocando mal. Los unique pointers tienen que estar fuera de A y de B, y luego cada uno tendrá una función para hacer el set del puntero del otro. A y B trabajarán internamente con punteros normales sin tener que preocuparse por liberar la memoria, y quien haya creado a A y B será quien los destruya realmente.

» autor: Penetrator

#65 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

unaiur — Fri, 21 Feb 2025 09:47:22 +0000

#18 Es completamente falso eso de que no compensa programar en ensamblador.

No te darás cuenta, pero hay montones de código en ensamblador para acelerar ciertos algoritmos usando todos los recursos de las CPUs populares. Por ejemplo, ejecutar expresiones regulares, compresión, hashing, cifrado, cálculos matemáticos avanzados… busca un poco y verás que el ensamblador sigue ofreciendo una ventaja entre el 500% y el 10000%.

Incluso si utilizas Python o Java, por debajo hay decenas de miles de líneas de ensamblador para optimizar los algoritmos críticos.

» autor: unaiur

#64 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

unaiur — Fri, 21 Feb 2025 09:30:54 +0000

#61 Rust tiene el mismo problema.

» autor: unaiur

#63 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

unaiur — Fri, 21 Feb 2025 09:28:35 +0000

#42 Soluciona el problema de la seguridad. Un memory leak no es un problema de seguridad por si solo, un programa que solo tenga errores de memory leak no es inseguro. Aunque es susceptible a ataques de denegación de servicio, no revela datos ni permite tomar el control de la máquina.

Si intentas escribir pasado el final de un std::vector o std::array tienes una bonita excepción si activas el address sanitizer (-fsanitize=address tanto en g++ como en clang).

Además clang-tidy detecta muchos de esos casos antes de mezclar el cambio en el repositorio Git.

» autor: unaiur

#62 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

unaiur — Fri, 21 Feb 2025 09:08:48 +0000

#31 new/delete/malloc/realloc/free y compañía deberían estar prohibidas en cualquier proyecto software que valore mínimamente la seguridad.

Pero eso no significa que solo puedas usar memoria de la pila. Tienes make_unique / make_shared que reservan de forma segura memoria heap y que liberan la memoria cuando ya no se necesita. Y por supuesto, todos los contenedores de la biblioteca estándar y de boost.

Respecto a tu ejemplo, cualquier analizador estático de medio pelo detecta ese error. Clang-tidy lo hace.

» autor: unaiur

#61 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

tierra_del_hielo — Fri, 21 Feb 2025 09:07:57 +0000

#59 pues ahí tienes ejemplos donde no sirven. Y las referencias circulares las puedes crear sin darte cuenta.

Estar pendiente de si necesitas shared_ppinter o weak_ptr es una fuente de errores. Es mucho menos propenso a errores tener un garbage collector que solucione esto por ti.

» autor: tierra_del_hielo

#60 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

tierra_del_hielo — Fri, 21 Feb 2025 09:04:59 +0000

#57 eeeh... No, tienes exactamente el mismo problema con unique pointer en una referencia circular.

Es una lata poner código por aquí pero si con un print en los constructores y otro en los destructores se puede demostrar. Te he encontrado un ejemplo en stackoverflow:
stackoverflow.com/questions/77322229/how-do-unique-ptrs-prevent-the-cy

» autor: tierra_del_hielo

#59 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

unaiur — Fri, 21 Feb 2025 08:59:32 +0000

#42 si necesitas referencias circulares, hay clases para representar grafos o listas circulares. También tienes weak_ptr. En el peor de los casos, tienes un memory leak, que puede conducir a una denegación de servicio, pero no expone datos ni permite el control remoto.

» autor: unaiur

#58 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

Penetrator — Fri, 21 Feb 2025 08:59:16 +0000

#54 Se sigue usando C/C++ porque no hay nada comparable en cuanto a rendimiento y compatibilidad. Intenta meterle un intérprete de Python a un microcontrolador y me lo cuentas.

» autor: Penetrator

#57 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

Penetrator — Fri, 21 Feb 2025 08:54:37 +0000

#56 Se puede hacer perfectamente utilizando unique pointers y sin memory leaks. Lo que pasa es que hay que tener cuidado de que los dos objetos se destruyan a la vez, porque si no sería posible que el otro siguiera usando un puntero ya eliminado.

» autor: Penetrator

#56 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

tierra_del_hielo — Fri, 21 Feb 2025 08:47:29 +0000

#53 objeto A contiene una referencia a objeto B. Objeto B contiene una referencia a objeto A.

Eso es una referencia circular. Si usas shared pointers con una referencia circular, vas a tener un memory leak.

ChatGPT te puede generar un código para que lo simules si quieres.

» autor: tierra_del_hielo

#55 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

turuleto — Fri, 21 Feb 2025 08:10:12 +0000

"los Estados Unidos se han tomado la programación es una cuestión de seguridad nacional: hace un año, la Oficina del Director Nacional de Ciberseguridad (ONCD) de los EE.UU. emitía un informe instando a los programadores a migrar hacia 'lenguajes de programación seguros en memoria'"

Hace un año.
¿Por qué genbeta saca un artículo ahora, qué ha ocurrido?
Portada en MNM.

» autor: turuleto

#54 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

spacos — Fri, 21 Feb 2025 08:01:16 +0000

#21 Lo que no entiendo es porque hay que seguir con una tecnologia obsoleta cuando podemos usar mejores lenguajes. ¿que sentido tiene seguir usando C/C++, sino es para código legacy? ES como ponerme a usar Cobol porque si. Que seguro que han mejorado el Cobol actual para que cumpla con los estandares actuales, pero no tiene sentido.
Yo creo que muchos programadores han invertido tiempo y esfuerzo en aprender un lenguaje mastodontico y ahora no quieren tirar por la borda ese dinero/esfuerzo. Y como ya he dicho, tambien estan los projectos ya hechos en c/c++ que hay que mantenerlos... Para mi c/c++ es el nuevo cobol...

» autor: spacos

#53 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

Penetrator — Fri, 21 Feb 2025 07:57:21 +0000

#40 #42 No entiendo muy bien a qué te refieres con lo de las referencias circulares. Si te refieres a que dos objetos comparten un mismo puntero, los shared pointers te lo solucionan.

» autor: Penetrator

#52 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

spacos — Fri, 21 Feb 2025 07:55:40 +0000

#31 Solo tener que leer ese trozo de código me da ganas de no volver a programar nunca mas. Vivan los nuevos leguajes !!!. A ver si pasamos página ya de una vez...

» autor: spacos

#51 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

tierra_del_hielo — Fri, 21 Feb 2025 07:50:32 +0000

#45 en principio no hay consecuencias si sobrepasas el array por poquito. Con algo de suerte podrás ver el contenido de otra variable y con menos suerte verás basura.

» autor: tierra_del_hielo

#50 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

Penetrator — Fri, 21 Feb 2025 07:38:23 +0000

#31 1. En C++ moderno es perfectamente posible trabajar con el heap sin usar new, delete, malloc y free. De hecho, es lo más recomendable.
2. Ese código ni siquiera compila.
3. En el caso de que fuera sintácticamente correcto, es bastante probable que un analizador estático sea capaz de detectar el problema.

» autor: Penetrator

#49 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

donchan — Fri, 21 Feb 2025 07:27:13 +0000

#48 ¿Qué le ves a C++ que no tenga Rust?

Lo único que le veo yo es que puedes usarlo con menos restricciones, lo que lo hace preferible para videojuegos, pero Rust da mayor seguridad, lo que lo hace preferible para OS y cosas críiticas.

» autor: donchan

#48 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

chavi — Fri, 21 Feb 2025 07:19:09 +0000

#47 Es que es de lo que habla la mayoría...

Yo siempre he mantenido que Rust en todo caso puede suplir a C, pero no a C++

» autor: chavi

#47 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

donchan — Fri, 21 Feb 2025 07:16:02 +0000

#44 He acabado por caer. Cuando he dicho C, estás interpretando "C y C++". No solamente tú. Qué curioso.

» autor: donchan

#46 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

donchan — Fri, 21 Feb 2025 07:03:14 +0000

#44 Pues claro que la que tú reservas. ¿Has visto los otros comentarios sobre los smart pointers?

» autor: donchan

#45 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

chavi — Fri, 21 Feb 2025 06:57:59 +0000

#40 Sin consecuencias, no.

Es algo con lo que se debe tener cuidado, si.

» autor: chavi

#44 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

chavi — Fri, 21 Feb 2025 06:55:13 +0000

#10 No es cierto. En C++ solo tienes que liberar tu la memoria que tu reservas. Normalmente los objetos se crean en el Stack

» autor: chavi

#43 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

MajorBonner — Fri, 21 Feb 2025 00:18:31 +0000

Uno de los proponentes lo explica claro en este video: www.youtube.com/watch?v=RXJKdh1KZ0w&t=17s

» autor: MajorBonner

#42 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

tierra_del_hielo — Fri, 21 Feb 2025 00:17:10 +0000

#26 los unique_ptr y shared_ptr son una solución incompleta al problema de liberar la memoria. Son incompletas porque no soportan las referencias circulares.

Fuera de liberar la memoria. Tampoco soluconan el desbordamiento en vectores/arrays.

» autor: tierra_del_hielo

#41 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

MajorBonner — Fri, 21 Feb 2025 00:15:51 +0000

No es ninguna sorpresa. Como hay mucha gente qualificada en C++ algunos se puenen a buscar otro lenguage porque [meter excusa aqui]. Yo creo que el nombre lo dice todo, algunos tienen la mente oxidada (rusted). La de empresas que han cascaron intentando cambiar technologia es larga. Un gobierno no es una startup y no estamos hablando de websites ni sitios sociales. Esto seran los que en su momento lo habrian querido hacer en J++

» autor: MajorBonner

#40 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

tierra_del_hielo — Fri, 21 Feb 2025 00:12:32 +0000

#21 los punteros inteligentes tienen sus limitaciones. Por ejemplo con las referencias circulares se pueden formar un memory leak si usas únicamente smart pointers.

Pero el problema no es solo los memory leak, sino los accesos a memoria. En C++ puedes desbordar un array sin consecuencias, pudiendo acceder a basura o... Contenido de otra parte de la memoria. Y debido a eso, muchos proyectos han tenido agujeros de seguridad gigantescos.

» autor: tierra_del_hielo

#39 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

tierra_del_hielo — Fri, 21 Feb 2025 00:03:15 +0000

#15 si claro, pero eso es un nicho concreto.

» autor: tierra_del_hielo

#38 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

bitman — Thu, 20 Feb 2025 23:58:40 +0000

Dentro de 30 años pedirá programadores de C/C++ para mantener código antiguo que en su día no se portó a otros lenguajes seguros. Será el nuevo Cobol

» autor: bitman

#37 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

M_S_X_ — Thu, 20 Feb 2025 23:39:08 +0000

#35 Eso que digo lo hace la IA más tonta del mercado a día de hoy

» autor: M_S_X_

#36 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

jaramero — Thu, 20 Feb 2025 23:04:01 +0000

#34 cobol a nivel de transacciones sigue siendo una roca.

Luego ves que necesitas un popurrí de tecnologías de diferentes compañías para conseguir lo mismo, pero cada una con su ciclo de deprecación, sus licencias e incompatibilidades que sobre el papel no sale a cuenta.

Copilot no sé si es compatible, pero generar rutinas de cobol a golpe de prompt sería otra nueva juventud para este vetusto lenguaje.

» autor: jaramero

#35 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

phyrian — Thu, 20 Feb 2025 22:45:23 +0000

#33 Y con que programas la IA?

Creo que ademas ya hay lo que dices, creo que se llamaba SONAR

» autor: phyrian

#34 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

phyrian — Thu, 20 Feb 2025 22:45:01 +0000

" gran parte del software crítico aún depende de tecnologías con décadas de antigüedad, como C y C++."

Estos aun no se enteraron de Cobol en los bancos jjj

» autor: phyrian

#33 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

M_S_X_ — Thu, 20 Feb 2025 22:38:12 +0000

Sería más sencillo que una IA analizara el código y marcara/arreglara los potenciales riesgos, que al final son dos o tres casos:
Punteros sin inicializar, asignación a variables de cadenas sin comprobar la longitud y conversión de tipos de datos inseguros.

» autor: M_S_X_

#32 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

Ludovicio — Thu, 20 Feb 2025 22:37:35 +0000

#4 Yo lo estoy aprendiendo. Es horrible

» autor: Ludovicio

#31 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

Setis — Thu, 20 Feb 2025 17:41:55 +0000

#30
Ya, que solo usas el stack. Como los años 80.
```
* MyStruct bang() {
MyStruct ms[5];
* MyStruct result = &ms[4];
result ++;
return result;
}
```
Me sorprendería si el analizador estático puede detectar eso.

» autor: Setis

#30 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

unaiur — Thu, 20 Feb 2025 17:17:53 +0000

#29 yo uso el analizador estático de CLang y los workflows de GitHub para impedir que cualquier desarrollador mezcle código que no sigue las directrices, incluido usar malloc, new, delete, free…

» autor: unaiur

#29 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

Setis — Thu, 20 Feb 2025 11:31:35 +0000

#25 Avísanos cuando puedas acotar en C++ las zonas inseguras, en lugar de asumir que todo el código es inseguro.

» autor: Setis

#28 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

donchan — Thu, 20 Feb 2025 09:55:18 +0000

#21 Hay métodos más allá, como usar SPARK sobre ADA. Aunque, de hecho, no hay nada que impida que se haga algo así sobre Rust también.

» autor: donchan

#27 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

soberao — Thu, 20 Feb 2025 07:26:53 +0000

#23 E imponiendo estándares corporativos para que el desarrollo y la dirección de ese software lo decida una corporación y sus intereses económicos.

» autor: soberao

#26 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

unaiur — Thu, 20 Feb 2025 05:05:51 +0000

#10 En C++ moderno lo hace unique_ptr, shared_ptr o cualquiera de los containers de la biblioteca estándar. Hay analizadores estáticos de código para comprobar que no se usa el sistema de manejo de memoria de C y el resultado es tan seguro como Rust.

» autor: unaiur

#25 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

unaiur — Thu, 20 Feb 2025 05:00:19 +0000

#22 Hasta que llegas a los bloques “unsafe”. Rust es tan inseguro como C++ moderno.

» autor: unaiur

#24 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

Findeton — Thu, 20 Feb 2025 02:43:18 +0000

#18 Claro, siempre puedes usar unsafe { ... } y meter ahí lo que quieras.

» autor: Findeton

#23 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

mcfgdbbn3 — Thu, 20 Feb 2025 01:34:57 +0000

#4: El acceso seguro: un procesador que no sabes cómo está hecho, una memoria RAM que tampoco sabes cómo es, una placa madre que no sabes si no tiene algún chip demasiado cotilla, una interfaz de red que no sabes si todo lo que hace lo conoce el procesador... A mí me da la risa ya con todo esto de la seguridad. ¿Para qué, si luego te lo llenan de puertas traseras?

» autor: mcfgdbbn3

#22 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

eltoloco — Wed, 19 Feb 2025 23:32:51 +0000

#1 hay infinidad de lenguajes compilables a código máquina. Pero es que además hoy en día existe Rust, sustituto directo de C/C++ y con un manejo de memoria totalmente seguro.

» autor: eltoloco

#21 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

drstrangelove — Wed, 19 Feb 2025 23:22:46 +0000

#10 En C++ hace eones que no hay que liberar memoria, los punteros inteligentes lo hacen automáticamente al acabar el scope.

Los señoros de la Casa Blanca no sé qué clase de asesores tendrán, pero vaya tela...

» autor: drstrangelove

#20 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

Penetrator — Wed, 19 Feb 2025 22:20:05 +0000

#10 En C++ eso ya existe desde hace un porrón de años.

» autor: Penetrator

#19 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

--633161-- — Wed, 19 Feb 2025 18:32:24 +0000

#18 Bueno, yo soy de otra época, lo mismo tienes razón.

» autor: --633161--

#18 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

musg0 — Wed, 19 Feb 2025 18:22:59 +0000

#15 Rust y probablemente cualquier lenguaje similar tiene un modo no seguro, así que si de verdad es necesario hacer algo a mano y controlar la ejecución del código al 100% lo pueden activar en ese trozo de código y pasarse a modo manual.
También el hardware cada vez es más potente y los compiladores más inteligentes (o por lo menos pueden probar diferentes métodos de optimización mucho más rápido que una persona y detectar cual es más rápido), así que al igual que ya no compensa programar directamente en ensamblador y nadie se rasga las vestiduras porque los sistemas operativos estén programados en C o haya Python y Java para sistemas empotrados, porque se prefiere la versatilidad de programar una vez y compilar y ejecutar en hardware diferente, en un futuro se podría ver normal que los sistemas operativos estén programados en Rust si de verdad hace que los sistemas sean más seguros que si están programados en C y la ¿pequeña? pérdida de rendimiento compensa

» autor: musg0

#17 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

musg0 — Wed, 19 Feb 2025 17:58:46 +0000

Venía con el cuchillo preparado debido al titular clickbait, pero lo que dice el artículo es bastante lógico y racional. Tampoco sé hasta qué punto depende CISA de la Casa Blanca, pero es como si en titular dijeran "Moncloa pide..." como si lo hubiera dicho el mismo presidente y luego resulta que los que han hecho el informe son científicos del CSIC

» autor: musg0

#16 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

Setis — Wed, 19 Feb 2025 16:25:10 +0000

#1 Ya veo que aquí se viene a comentar sin leer el artículo. En el artículo mencionan Rust, que no tiene gigas de overhead.

» autor: Setis

#15 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

--633161-- — Wed, 19 Feb 2025 15:23:14 +0000

#13 Pero, creo, siempre harán falta programadores que sean puedan tocar el bare metal y poder escribir drivers, kernels y demás con un lenguaje que no les ponga límites.

» autor: --633161--

#14 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

donchan — Wed, 19 Feb 2025 15:21:42 +0000

#13 Rust es muy suyo y se tienen que hace las cosas "a la manera de Rust" para evitarse lios.

» autor: donchan

#13 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

soberao — Wed, 19 Feb 2025 14:34:37 +0000

#10 #12 Muchos lenguajes de programación van ligados a escuelas o culturas de programación, que no es más que una línea de pensamiento y una forma de hacer las cosas a la hora de programar. Imponer estos cambios puede suponer tirar a la basura estos métodos y estos libros, como los libros viejos de informática, que si son de Windows se quedan obsoletos rápido, pero si son de lenguajes de programación, de sistemas operativos tipo Unix verás que muchas cosas que pone un libro de los noventa seguían vigentes en unixes de hoy en día hasta la llegada de systemd.
Rust tiene su escuela e irá ganando adeptos pero el resto de paradigmas y formas de ver la programación tienen que tener su sitio y no se puede pretender cambiar lo que ha llevado años construir y perfilar, y que ha llegado hasta hoy por méritos y trabajo.

» autor: soberao

#12 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

--633161-- — Wed, 19 Feb 2025 14:02:31 +0000

#4 Porque lo de programar bien es pedir mucho

» autor: --633161--

#11 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

donchan — Wed, 19 Feb 2025 13:53:47 +0000

#6 Ah, ahora sé en qué están programados esos aparatos que venden para medir el azucar en la sangre sin pinchar.

» autor: donchan

#10 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

donchan — Wed, 19 Feb 2025 13:52:37 +0000

#4 Como comentario porque sí, lo que hace el compilador de Rust es generar automáticamente el código para liberar la memoria cuando pierde su "visibilidad".
En C lo tiene que hacer el programador.

» autor: donchan

#9 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

donchan — Wed, 19 Feb 2025 13:50:33 +0000

#3 Casa blanca oxidada (es una referencia a Rust, es que soy tan malo en esto...)

» autor: donchan

#8 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

j0seant — Wed, 19 Feb 2025 13:48:18 +0000

Lo próximo será pedir que dejen de usar cuchillos y que corten la cebolla con tenedor, pero con cuidado que pincha..

» autor: j0seant

#7 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

blockchain — Wed, 19 Feb 2025 13:41:20 +0000

#3 con Clinton fue el año de la Mancha Blanca bajo el escritorio
Suena parecido, pero no lo es

» autor: blockchain

#6 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

--525604-- — Wed, 19 Feb 2025 13:33:13 +0000

Rust es seguro intrínsecamente, porque no necesita acceder a la memoria. Lo creais o no, la IA integrada se inventa todos los datos, no necesita consultar posiciones de memoria.

» autor: --525604--

#5 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

angelitoMagno — Wed, 19 Feb 2025 13:29:26 +0000

Lo aclaro por si acaso, esto viene de la anterior administración.

» autor: angelitoMagno

#4 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

soberao — Wed, 19 Feb 2025 13:28:47 +0000

Parece que hay que meter a Rust por cojones en todos los proyectos porque permite "acceso seguro a la memoria"...

» autor: soberao

#3 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

malajaita — Wed, 19 Feb 2025 13:23:56 +0000

El año de la Casa Blanca en el escritorio.

» autor: malajaita

#2 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

frankiegth — Wed, 19 Feb 2025 13:21:48 +0000

#1. Al final los sistemas informáticos y su software acabarán siendo "tan seguros" que no habrá quien pueda utilizarlos, o por temas de "requisitos" del propio hardware o por temas puramente de "seguridad".

» autor: frankiegth

#1 La Casa Blanca pidió a la industria que dejara de programar en C/C++: ha tenido que matizar para no pasarse de frenada

Chuache_cientifico — Wed, 19 Feb 2025 13:18:12 +0000

Sin duda es mucho más seguro introducir gigas de overhead en cada llamada a una función que queramos hacer.

» autor: Chuache_cientifico