mboost-dp1
GitHub Copilot - kvantetativ tilgang
#3
Det er interessant at IBM forsøger at sælge noget sådant.
Men jeg tror ikke på ideen.
At konvertere mellem forskellige sprog er et kendt problem. Fra før AI blev "hot".
For 30 år siden eksisterede der en konverter p2c som kunne konvertere Pascal kode til C kode.
GNUCobol compiler ikke Cobol til binary code men til C kode som så sendes gennem en C compiler.
SharpDevelop er glimrende til at konvertere mellem C# og VB.NET (hvis jeg skal lave et VB.NET eksempel så skriver jeg typisk koden i C# og konverterer og tilretter lidt).
Der eksisterer flere Cobol compilere som oversætter Cobol til Java byte code (og Java byte code kan som bekendt decompiles til Java source code).
Det er givet at man kan oversætte Cobol source kode til Java source kode.
Det kræver ikke engang AI.
Men problemet er ikke Cobol->Java. Problemet er gammel arkitekture->ny arkitektur.
Det er ret formålsløst at konvertere et Cobol program med en terminal GUI for vedligehold af en ISAM fil til et Java program med en terminal GUI for vedligehold af en ISAM fil.
Man vil have en HTML5 frontend og en Java micro-service som vedligeholder nogle tabeller i en RDBMS.
Og jeg tror ikke på AT til at lave den konvertering.
En betragetlig del af sådanne projekter udført af mennesker fejler.
Det er interessant at IBM forsøger at sælge noget sådant.
Men jeg tror ikke på ideen.
At konvertere mellem forskellige sprog er et kendt problem. Fra før AI blev "hot".
For 30 år siden eksisterede der en konverter p2c som kunne konvertere Pascal kode til C kode.
GNUCobol compiler ikke Cobol til binary code men til C kode som så sendes gennem en C compiler.
SharpDevelop er glimrende til at konvertere mellem C# og VB.NET (hvis jeg skal lave et VB.NET eksempel så skriver jeg typisk koden i C# og konverterer og tilretter lidt).
Der eksisterer flere Cobol compilere som oversætter Cobol til Java byte code (og Java byte code kan som bekendt decompiles til Java source code).
Det er givet at man kan oversætte Cobol source kode til Java source kode.
Det kræver ikke engang AI.
Men problemet er ikke Cobol->Java. Problemet er gammel arkitekture->ny arkitektur.
Det er ret formålsløst at konvertere et Cobol program med en terminal GUI for vedligehold af en ISAM fil til et Java program med en terminal GUI for vedligehold af en ISAM fil.
Man vil have en HTML5 frontend og en Java micro-service som vedligeholder nogle tabeller i en RDBMS.
Og jeg tror ikke på AT til at lave den konvertering.
En betragetlig del af sådanne projekter udført af mennesker fejler.
#6
Med hensyn til risiko er den klassiske historie vel TSB.
https://jonstevenshall.medium.com/lessons-from-the...
Med hensyn til risiko er den klassiske historie vel TSB.
https://jonstevenshall.medium.com/lessons-from-the...
#5, #6
Ja, men om 10-20-30 år er den slags kode helt umuligt at vedligeholde.
Det er jo allerede et problem for C/C++. Der er ingen tilbage til at vedligeholde det, og folk der er vokset op med C++17 og senere vil jo aldrig kunne vedligeholde C++ kode der skal kompileres med C++98 eller C++03
COBOL er i et endnu værre situration. Virksomheder betaler allerede formuer* for COBOL konsulenter til at vedligeholde deres oldgamle kode.
Og det blive kun mere dyrt hvert år.
(* vi mangler en udgave af "king's random" på Dansk)
Ja, men om 10-20-30 år er den slags kode helt umuligt at vedligeholde.
Det er jo allerede et problem for C/C++. Der er ingen tilbage til at vedligeholde det, og folk der er vokset op med C++17 og senere vil jo aldrig kunne vedligeholde C++ kode der skal kompileres med C++98 eller C++03
COBOL er i et endnu værre situration. Virksomheder betaler allerede formuer* for COBOL konsulenter til at vedligeholde deres oldgamle kode.
Og det blive kun mere dyrt hvert år.
(* vi mangler en udgave af "king's random" på Dansk)
Claus Jørgensen (9) skrev:
Ja, men om 10-20-30 år er den slags kode helt umuligt at vedligeholde.
...
COBOL er i et endnu værre situration. Virksomheder betaler allerede formuer* for COBOL konsulenter til at vedligeholde deres oldgamle kode.
Cobol har ikke været et sprog som er blevet anbefalet til ny applikationer og et sprog der er blevet brugt i undervisning de sidste 30 år.
Men der er ikke blevet akut mangel på Cobol programmører.
Cobol udviklere får ikke højere lønninger end udviklere i andre sprog. Alle de lønstatistikker jeg har set viser at de tilbage i 10'ene lå nederste trediedel og nu ligger i midterste trediedel. Man skal dog huske på at de fleste Cobol udviklere er senior udviklere, hvilket naturligvis trækker det simple gennemsnit der ikke justerer for ancienitet op.
En af årsagerne er at Cobol er et meget simpelt sprog. Syntaksen virker usædvanelig på mange, fordi det var et af de første sprog og sprog designerne famlede sig frem dengang, men det er ikke svært. Alle kan lære Cobol på ret kort tid.
Så er der et prestige/kræsenheds aspekt. Den typiske danske nyuddannede IT person fravælger nok Cobol fordi det er for gammeldags. Men den typiske indiske nyuddannede IT person er ikke sådan - skaffer Cobol mad på bordet er det OK. Så meget Cobol arbejde laves idag i Indien.
Claus Jørgensen (9) skrev:
Det er jo allerede et problem for C/C++. Der er ingen tilbage til at vedligeholde det, og folk der er vokset op med C++17 og senere vil jo aldrig kunne vedligeholde C++ kode der skal kompileres med C++98 eller C++03
Hmmmm. Mon dog.
Nye C++ versioner tilføjer vel mest d.v.s. fjerner ikke, så de må kende alle de valide konstruktioner.
De kender så også nogle konstruktioer der ikke er valide i de gamle versioner. Men hvis de skal udvikle til C++98 eller C++03, så har de vel adgang til en sådan compiler der venligt men bestemt vil give fejl på alle 11/14/17'ismerne.
De finder vel ud af det.
arne_v (10) skrev:
En af årsagerne er at Cobol er et meget simpelt sprog. Syntaksen virker usædvanelig på mange, fordi det var et af de første sprog og sprog designerne famlede sig frem dengang, men det er ikke svært. Alle kan lære Cobol på ret kort tid.
Lad os tage noget så banalt som variabel erklæringer.
C:
unsigned int a;
int b;
char c[32+1];
Cobol:
01 a pic 9(9) comp.
01 b pic s9(9) comp.
01 c pic x(32).
Set med moderne øjne er Cobol syntaksen obskur.
Men det er jo ikke svært at lære.
Når man har grinet færdig kan man lære det lynhurtigt!
Claus Jørgensen (13) skrev:
C++ har så mange "side effects" og special cases som folk åbenbart skal kende til for at kunne skrive det effektivt. Så du kan ikke vedligeholde en 20år kodebase hvis du ikke har erfaring med den slags kode.
Mit scenario var at folk skrev auto og C++ compileren gav dem fejl og de efter at havde lavet den fejl nogle gange lærte at undlade brug af auto.
Men du tænker på et scenarie hvor folk er vant til unique_ptr, får compiler fejl, skifter til gammeldags pointer, glemmer delete og ender op med en memory leak?
#15
Hvis det bare var at kompileren gav fejl, hvorfor er C++ udviklere så så bange for at opdatere deres kompilere?
Som jeg har forstået det så hvis du tager et C++03 program og kompilere det på C++20 så er der en faktisk risiko for at koden fejler tilfældigt ved RUNTIME, ikke compile-time.
Hvis det bare var at kompileren gav fejl, hvorfor er C++ udviklere så så bange for at opdatere deres kompilere?
Som jeg har forstået det så hvis du tager et C++03 program og kompilere det på C++20 så er der en faktisk risiko for at koden fejler tilfældigt ved RUNTIME, ikke compile-time.
Og der er jo også nonstandard behaviours (https://learn.microsoft.com/en-us/cpp/cpp/nonstandard-behavior?view=msvc-170) som mere eller mindre er "ancient knowlegde"
#17
Nu er jeg ikke C++ ekspert, men jeg har svært ved at tro at et korrekt C++ 03 program altså et program som er garanteret til altid at virke af C++ 03 standarden vil fejle hvis compilet med en C++14/17/20 compiler.
Jeg har meget nemt ved at tro at et C++ program med undefined behavior eller implementation specific behavior som tilfældigvis virkede med en bestemt C++ 03 compiler kan fejle hvis compilet med en anden evt. nyere (C++14/17/20) compiler. Sådan er det jo. Og C++ specielt gamle versioner af standarden har mange tilfælde af undefined behavior og implementation specific behavior.
Nu er jeg ikke C++ ekspert, men jeg har svært ved at tro at et korrekt C++ 03 program altså et program som er garanteret til altid at virke af C++ 03 standarden vil fejle hvis compilet med en C++14/17/20 compiler.
Jeg har meget nemt ved at tro at et C++ program med undefined behavior eller implementation specific behavior som tilfældigvis virkede med en bestemt C++ 03 compiler kan fejle hvis compilet med en anden evt. nyere (C++14/17/20) compiler. Sådan er det jo. Og C++ specielt gamle versioner af standarden har mange tilfælde af undefined behavior og implementation specific behavior.
#18
Den liste er en liste af standard C++ features som MS implementation ikke understøtter.
Det kan give fejl hvis kode skifter fra ikke-MS compiler til MS compiler.
Den første giver compile fejl, så ikke noget stort problem. Jeg tror ikke at den tredie har nogen praktisk betydning. Men den anden og den fjerde vil ændre opførsel, hvis skift fra 100% standard compiler til MS compiler.
Og udvikleren er i god tror hvis vedkommende koder efter standarden.
Så ikke godt at MS compiler afviger fra standarden.
Den liste er en liste af standard C++ features som MS implementation ikke understøtter.
Det kan give fejl hvis kode skifter fra ikke-MS compiler til MS compiler.
Den første giver compile fejl, så ikke noget stort problem. Jeg tror ikke at den tredie har nogen praktisk betydning. Men den anden og den fjerde vil ændre opførsel, hvis skift fra 100% standard compiler til MS compiler.
Og udvikleren er i god tror hvis vedkommende koder efter standarden.
Så ikke godt at MS compiler afviger fra standarden.
Hvilket var min pointe.arne_v (19) skrev:Og C++ specielt gamle versioner af standarden har mange tilfælde af undefined behavior og implementation specific behavior.
Om 10-20-30 år vil folk ikke kende til disse specifikke behaviours, og så har du et (stort) problem
Det er hvorfor kode, kompilere og teknologi generelt skal opdateres løbende, og ikke som big-bang engang hvert tyvende år.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund