IBM crolla in Borsa (-13%) dopo l'annuncio di Anthropic: cosa c'entrano Claude Code e COBOL

[pachainti]

Originariamente inviato da Unrue

Si va bene bona, tanto non se ne esce. Saluti

Se ne esce solo se ammetti la realtà.

[TorettoMilano]

Originariamente inviato da TorettoMilano

lato programmazione non mi pronuncio ma lato animazione si raggiungono picchi assurdi.
propongo questa lotta in 3d del finale della prima stagione di naruto.
invece il secondo video é una puntata non uscita (é uscito solo il manga) usando lo stile identico della prima stagione


https://youtu.be/-umcObDG_8E?si=9jyZQKYANW-XkHuT
https://youtu.be/s-VTcz8Nh0s?si=fA6WtHkdsBLcAJsR

sto tizio da solo sembra aver ingranato lato film con IA
https://x.com/isaachorror/status/2025948405625704610

[azi_muth]

Originariamente inviato da Unrue

SI immagino come li hanno usati... Il solito giudice che apre chatgpt usando un modello generico e chiedendogli di scrivere la sentenza. Tipo questo:

https://www.agendadigitale.eu/docume...so-di-firenze/

Più che il giudice è l'avvocato e gli è andata di lusso perchè non c'erano elementi per provare il danno. In caso contrario si sarebbe potuto aprire anche una questione di responsabilità professionale.

Originariamente inviato da Unrue

Quello che ho postato io è un modello specializzato in campo legale, tutt'altra storia.

Sono migliori ma resta il problema della revisione...

[ZeroSievert]

In questo periodo mi sono messo a lavorare su Yocto anche se non é il mio. Per chi non lo sapesse, Yocto é un sistema per generare SO Linux custom per sistemi embedded.
Un progetto Yocto consiste in un mucchio di file di configurazione. É parecchio complesso perché si va dalla configurazione del kernel, al bootloader, ai singoli pacchetti e a cosa deve finire e come nell'SDK e nell'immagine generate. E il tutto gira dentro docker/podman per avere un sistema reproducibile.

Le build richiedono tanto tempo. Sul mio i9 nuovo di pacca, su WSL, ci vuole un'oretta e piú.
Se non conosci bene Yocto é facile fare errori e buttare via giornate. E il problema é che alcuni pacchetti/layer che uso sono poco documentati.

Preso dalla disperazione, a seguito di questa news e di consigli di conoscenti, sto provando claude-cli. Devo dire che il suo sporco lavoro lo fa. É abbastanza impressionante come riesca a capire la struttura del progetto che li dai in pasto.

E mi piace molto anche che cerchi di non stravolgere quello che c'é scritto ma ti proponga modifiche incrementali in formato diff. Ovviamente a volte devi guidarlo perché quel che ti propone non é quel che vuoi. Ma devo dire che mi ha evitato di finire in punti morti che difficilmente avrei superato. Devo dire che per il codice é molto meglio di chatgpt.

[gparlav]

Originariamente inviato da Unrue

Si certo come no. Domanda: tu hai mai lavorato su codici grossi di produzione? Io si, in Fortran, che è l'equivalente del COBOL in campo scientifico diciamo. Se pensi che per metterci le mani basti conoscere il linguaggio e 1 giorno per capirlo ti sbagli di grosso.

Tranquillo, ci ho lavorato diversi anni sui sistemi GROSSI, tutti scritti in COBOL.
La conoscenza del linguaggio è il minore dei problemi. Diciamo che, all'epoca, in meno di 2 anni avevo raggiunto la massima conoscenza tecnica del linguaggio.

Ma, come hanno scritto altri prima di me, dal punto di vista strettamente tecnico, il COBOL è davvero facile da leggere e da strutturare. Non è certo quello l'ostacolo nella comprensione di un programma.

Quello che fa la differenza è capire l'analisi sottostante e cosa deve fare, le interconnessioni con le altre procedure, le strutture dati accedute / scritte. Quando parlo di 1 giorno di lavoro per capire cosa fa quel programma, mi riferisco a quell'attività. Facilitata enormemente dalla facilità sintattica del COBOL. E ne ho fatti diversi. Era normale sviluppare in "coppia", con una persona che scriveva il codice e faceva il primo debugging, mentre l'altra persona faceva il testing di procedura e di integrazione. E' il processo normale negli sviluppi di applicativi che devono avere un alto livello di affidabilità e documentabilità, con "4 eyes principle" applicato ovunque.

Quando ho fatto il paragone con C/C++, l'ho fatto a ragion veduta, dato che ho anche programmato in quei linguaggi, oltre che (poco) in Java e qualcosa in Visual Basic. Sono linguaggi MOLTO più potenti, ma anche MOLTO più ostici. Spesso sovradimensionati rispetto a semplici necessità "Business". E la modalità in "coppia" sopra descritta non sono mai riuscito a farla con un'altra persona. Al limite si riusciva a fare un po' di testing incrociato, segnalando però all'autore i problemi, che solo lui poteva risolvere perchè solo lui riusciva a metterci le mani. E il "4 eyes" andava a farsi benedire.

[gabrieleromano]

l'unica migrazione che temo io è quella dei cervelli (non in fuga...) ma in caduta libera