Torben Mogensen

Oracles sprogudvikler om kæmpe Java-omstilling: Vi er meget langt i processen

intet sprog til seriøs forretningsmæssig brug havde automatisk håndtering af hukommelsen, mener sprogudvikleren.

Det er nu ikke helt rigtigt. APL, som netop bliver brugt til forretningssoftware, havde automatisk lagerhåndtering helt fra starten i 1960erne. LISP (specielt Common LISP) blev også langt før Java brugt til forretningssoftware.

Java var i starten reelt en blanding af Simula67 (som havde automatisk lagerhåndtering) og C++, så jeg vil ikke kalde det specielt revolutionerende. Just-in-time oversættelse var også tidligere brugt (under andre navne) i LISP og Smalltalk, så heller ikke dette var noget nyt. Og f.eks. Pascal havde længe været oversat til en abstrakt maskine (P-code), så heller ikke dette var nyt.

Reelt var det nye verifikation af bytekoden inden kørsel, og det er også en klar fordel for sprog, der køres i browsere. Men det har mere med JVM end Java at gøre, omend JVM var designet specifikt til Java (hvilket har givet nogle problemer senere, både for support af andre sprog og for videreudvikling af Java).

Men Java er på vej i den rigtige retning: Værdityper, pattern matching, lambdaudtryk, parametrisk polymorfi, osv. -- alle længe kendt fra funktionssprog, og de klassiske objektorienterede elementer bliver i større og større grad sat i skammekrogen (som artiklen også nævner), omend de stadig understøttes af hensyn til bagudkompatibilitet. Men det havde nok været bedre for alle, hvis Sun i sin tid havde satset på noget, der i højere grad lignede Standard ML (som næsten hver udvidelse af Java har trukket ideer fra).

1. juni kl. 11:25
Python ankommer i browseren med hjælp fra Anaconda

Morten Kvistgaard skrev: Der er sikkert flere...

JavaFX

4. maj kl. 10:09
MitID - et spørgsmål om tillid

Jeg vil helt klart også vælge kodeviseren frem fo appen, når jeg bliver beordret over på MitID. Enhver app kan hackes, og ved at have kodeviseren et andet sted end telefon og computer, mindskes risikoen for at en tyv kan få alle de nødvendige dele på en gang.

24. marts kl. 11:04
Java rejser til Valhal, hvor værdityperne gror

selvom ML ramte rigtigt på mange punkter så fejlede man da sproget blev (stort set) pure functional.

Jeg vil ikke kalde SML ret "pure". Der er mutable arrays, imperativ i/o, exceptions, osv., der ikke passer med en ren funktionel tilgang. Den primære begrænsning er, at variable ikke er mutable. Men en variabel kan være en (immutable) reference til en mutable celle, der kan opdateres. Det tillader kopiering af variable i closures i stedet for at skulle tilgå dem via referencer. Altså værdiidentitet i stedet for adresseidentitet.

SML er ikke fejlfrit -- der er dele af syntaksen, der ikke er så pæn, og der mangler understøttelse af tråde (der er varianter af SML, f.eks. Concurrent ML, der gør) og Unicode. Og standardbibliotekerne er ikke super store. Men grundstrukturen er pæn og kan implementeres effektivt fordi man ikke skal tage hensyn til snavns såsom adresseidentitet og virtuelle metodekald. Og så er typesystemet sundt til forskel fra det i Java (og C# for den sags skyld).

27. januar kl. 09:58
Java rejser til Valhal, hvor værdityperne gror

Den nye form for identitet for værdityper minder meget om den, der ses i funktionelle sprog såsom Standard ML: To objekter er ens, hvis deres felter er ens, selv om de ligger på forskellige adresser. I ML er det envidere transparent, om felterne ligger samlet i lageret eller ej, så det er op til compileren at beslutte det. For små felter giver det mening at have dem samlet, men store felter kan med fordel lægges et andet sted end resten af objektet, og hvis der er tale om en rekursiv type, så skal rekursive felter ligge et andet sted for at undgå eksplosion af størrelsen og for at tillade deling.

Jeg vil som sædvanlig, når der snakkes om udvidelser af Java eller C#, citere Bob Harper: "Over time every language evolves to look more and more like Standard ML".

26. januar kl. 10:15
Java rejser til Valhal, hvor værdityperne gror

Jeg vil tro, at compleren sørger for at aligne valuetypede objekter på cachelinjegrænser, så hele objektet ligger i samme cachelinje (hvis det ikke fylder for meget). Dermed bliver hele objektet hentet ind i cachen så snart et felt hentes.

26. januar kl. 10:08
Revolutionen vi har ventet på

Det er lidt sent at fange pointerfejl på køretid, selv om det er bedre end aldrig.

Sprogene bør laves, så det er umuligt at lave pointerfejl, da alle sådanne ville blive fanget på oversættelsestidspunktet af typesystemet -- eller slet ikke forekomme fordi pointere på forhånd (dvs. at det ikke først checkes på køretid) er begrænset til at blive oprettet og fulgt (med offsets inden for det allokerede), og det de peger på først fjernes, når der ikke er flere pointere til dem. Sidstnævnte kan gøres med garbage collection eller ved at typesystemet holder øje med ejerskab og levetid (som i Rust eller med regionsinferens).

Jovist, det er rart at kunne oversætte C, men det kan man også gøres ved at lade compileren indsætte checks hver gang, man følger eller opdaterer en pointer, så man statisk kan garantere, at man holder sig inden for grænserne af allokeringen. CHERI er reelt bare hardwaresupport, der garanterer at sådanne checks laves inden pointeroperationer, så man statisk er sikker på, at snavns opdages -- dog med køretidschecks som omkostning). Men det ville være bedre helt at kunne undvære at skulle lave sådanne checks på køretid (uanset om hardwaresupport nedsætter tidsforbruget og sikrer, at de rent faktisk laves). Det vil kræve maskinsprog med typer, der kan sikre pointer-safety INDEN et program køres, uden at skulle lave checks på køretid). Inden brugerkode eksekveres, bliver det checket for typekorrekthed (af et program, der er typechecket inden det lægges i operativsystemet). Der kan være behov for, at koden annoteres med information, der gør verifikation nemmere (proof-carrying code).

25. januar kl. 17:34
Mange eller få fejl ?

Og hvis man fortsætter sådan så ender fremtidige software releases typisk med at blive "små hop på stedet". Små udvidelser der ikke flytter det helt store.

I de fleste tilfælde ville jeg være udmærket tilfreds med nye releases, der blot reducerer mængden af fejl uden at tilføje nye features. Meget software lider af galloperende featuritis.

19. januar kl. 10:57
Mange eller få fejl ?

Tony Hoare sagde til sin Turing Award lecture

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

Min fornemmelse er, at langt det meste kommercielle software er i den sidste kategori.

Han sagde også

The real value of tests is not that they detect bugs in the code, but that they detect inadequacies in the methods, concentration, and skills of those who design and produce the code.

hvilket heller ikke lyder helt ved siden af.

17. januar kl. 10:46
Mange eller få fejl ?

Jeg så engang en metode til at estimere antallet af uopdagede fejl:

Sæt to hold til at lede efter fejl i et bestemt antal timer. X fejl bliver fundet af hold A, Y fejl bliver fundet af hold B, og Z fejl bliver fundet af begge hold. Ud fra en antagelse om, at sværheden af at finde fejl er normalfordelt (nogle få er nemme at finde, nogle få er meget svære at finde, men de fleste ligger midt imellem), kan man ud fra de tre tal estimere antallet af fejl, som ingen af de to hold har fundet. Groft sagt, jo flere fejl, der kun bliver fundet af af hold, jo flere uopdagede fejl er der. Jeg husker dog ikke formlen.

Der er nok ret stor usikkerhed i resultatet, men som et nulestimat fungerer det nok meget godt.

17. januar kl. 10:37
DR's 2 timers historie om danske computerspil

Det er min opfattelse at de fleste godt ved det og at amigaens død mest af alt var forsaget af idiotiske/egoistiske beslutninger.

Udover de skatteteknikse problemer, PHK nævnte, så valgte Commodore også at satse på DOS-PCer i stedet for at videreudvikle Amigaen. På det marked var Commodore kun en af mange, og deres PCer var ikke noget særligt.

3. januar kl. 10:29
Professor forsvarer milliarddyr udvikling af ejendomsvurderingssystemet

At lave en model, som er dækkende og kan anvendes i næsten alle tilfælde (>99%. 1% ~ 23.000 ejendomme) er kompliceret.

Ja, så man burde have startet med et system til at håndtere de nemme tilfælde (som nok er 90%) og overlade resten til manuel behandling. Når dette system er oppe at køre, kan man efterhånden tilføje flere regler, så man dækker flere tilfælde. Men det er urealistisk, at 100% kan klares automatisk.

Man bør endvidere specificere reglerne i et domænespecifikt sprog, der er læseligt af ikke-programmører, så jurister kan kontrollere reglerne og måske endda tilføje nye regler. Hvis det hele er specificeret i f.eks. C# eller Java, så er det kun trænede programmører, der kan afkode og modificere logikken (og kun ved brug af meget tid).

8. december 2021 kl. 10:54
Sådan snyder spillene spilleren

Jeg snakkede for nogle år siden med en spilprogrammør, der arbejde med AI til NPCer. Han fortalte, at han blev nødt til at skrue ned på, hvor smarte NPCerne var, for ellers ville det blive for svært for spillerne at vinde over dem. Det er måske ikke direkte at lyve overfor spillerne, men at give dem en fordel, der ikke er realistisk.

På et mere seriøst niveau kan jeg frygte, at spillere kan få et urealistisk billede af kamp, sådan at hvis de bliver soldater og sendt i felten, vil de opføre sig dumdristigt og blive skudt på deres første mission. Man må håbe, at soldateruddannelsen giver dem en mere realistisk fornemmelse af egne evner.

6. december 2021 kl. 10:32
Professor forsvarer milliarddyr udvikling af ejendomsvurderingssystemet

Når der er brugt så mange timer på eksterne konsulenter tyder det på, at der har været for få ansatte. Er det igen en konsekvens af ansættelsesstop eller andre effekter, der gør det nemmere at få konsulenter end at ansatte folk?

6. december 2021 kl. 10:17
ITU klar til at skære studiepladser midt i mangel på it-folk: »Kæmpe tab for samfundet«

Alle universiteter i storbyer er bedt om at skære 10% eller flytte ud. Det kan ikke undgå at ramme IT-uddannelser på de andre universiteter også.

2. december 2021 kl. 10:35
Da frk. Klokken var fuld

Det er mærkeligt, at der kan være timetal over 24 og skæve sekunder, når tiderne er indtalt på forhånd.

Jeg kan stort set kun forestille mig en mulighed: Hvis timer, minutter og sekunder er optaget på hver deres glasplade, og nogen har byttet om på dem i afspillemaskinen. Hvis maskinen hvert tiende sekund afspiller to sekunder af timepladen, to sekunder at minutpladen og to sekunder af sekundpladen, så vil en ombytning kunne give meget forkerte svar.

Det kræver så, at pladerne har samme størrelse og afspilningshastighed -- ellers vil ombytning ikke kunne ske eller lyden vil blive for hurtig eller langsom på nogle af elementerne. Hvis hver plade har 120 indspillede lydklip kan det lade sig gøre -- timerne er indspillet fem gange hver, minutterne to gange hver, og sekunderne tyve gange hver (da der kun er klip for hvert tiende sekund).

Jeg kan forestille mig, at pladerne en gang imellem skal renses eller måske tages ud for at skifte lamperne. Ellers ville der ikke være nogen grund til at tage dem ud af maskinen, når denne først er i gang. Og hvis maskinen en gang i mellem skal tages ned for vedligeholdelse kræver det to maskiner, så den ene kan bruges, mens den anden er taget ned. Det giver så seks de glasplader, som Bjarne nævnte.

30. november 2021 kl. 10:44
Dansk succes-udvikler vinder international pris for bedste computerspil

Til alle dem, jeg kender på IO Interactive. Og også dem, jeg ikke kender, i øvrigt. De skal heller ikke glemmes.

30. november 2021 kl. 10:30