Java har ikke længere samme dominans inden for programmering som tidligere. Især Python og Javascript har snuppet tronen på flere målinger for sprogs popularitet.
Men sproget er stadig det foretrukne valg til forretningsprogrammering i mange industrier, og bedømt på det store antal aftapninger af open source-udgaven Openjdk, er der ikke tegn på, at Java er på vej ud af døren lige foreløbig.
- emailE-mail
- linkKopier link
Fortsæt din læsning
- Sortér efter chevron_right
- Trådet debat
Ved et usundt typesystem forstås, at man kan komme i en situation, hvor et udtryk på kørselstidspunktet viser sig at have en anden type, end typesystemet indikerede ved oversættelsestidspunktet. Dette kan i C# ske ved at erklære et array af giraffer , gemme en reference til det i en variabel af typen “array af dyr” og herefter indsætte et objekt af typen tiger i array vha. denne variabel.
Jeg er helt enig i, at det sjældent giver praktiske udfordringer ved brug af C#. Samme kovariante opførsel for arrays er tilladt i Java.
Array-varians i C# er usundt. Endnu en dårligdom man kopierede fra Java for lettere at kunne køre Java kode på CLR.
Det må du forklare nærmere. Jeg er enig i at der er problemer - nok nærmere af performance grunde. Jeg mener ikke man kan sammenligne med Java. Og at det skulle gøre typesystemet usundt forstår jeg ikke - det er ikke et problem man render ind i i dagligdagen fordi arrays i praksis er indpakket.
Nu skal man altså tage "popularitets" målinger med et vist gran salt.Især Python og Javascript har snuppet tronen på flere målinger for sprogs popularitet.
At der er søgt meget på et sprog, eller det er det mest adspurgte på Stackoverflow, er ikke nødvendigvis fordi det er populært, men fordi der er mange der (er tvungne til) bruger det.
Således tror jeg ikke Javascript er specielt populært, tværtom (elendig typing og bizar casing), men det er nu engang en nødvendighed for at lave funktionalitet på et website - men hvis det i stedet havde været Brainfuck der var nødvendigt, så ville det jo også ryge til tops på Stackoverflow.
Man kan vel egentlig vende den om og sige, des mere besværligt et sprog er, des flere spørgsmål på Stackoverflow.
Array-varians i C# er usundt. Endnu en dårligdom man kopierede fra Java for lettere at kunne køre Java kode på CLR.
Array-varians i C# er usundt. Endnu en dårligdom man kopierede fra Java for lettere at kunne køre Java kode på CLR.
Tja, men Javas valg giver rigtig god mening. Java er lavet ud fra en inspiration af C (og C++) og ikke noget som helst andet. Det er imperativt og objektorienteret med funktionelle muligheder. C (og C++) var trods alt de mest udbredte sprog overhovedet i 1995. Specielt til emerging embedded var C kongen (nogen der husker Echelon?). Så med det target der var oprindeligt for Java, er det ikke så underligt.
At der så senere (snart 30 år after the fact) sidder nogen og beklager sig over at Java ikke ligner Standard ML det er helt skudt ved siden af. Det kunne man godt. Man kunne godt have lavet et sprog der lignede et andet sprog som ingen benytter, men var det så blevet en success? Næppe.
Java er (ligesom JacaScript) en kæmpe success i industrien, og Standard ML er det nok i undervisningen. Men det er sådan set ligegyldigt. Det er super fedt at der udvikles på sproget og at der tilføjes nye features som gør programmerne "bedre" (for hvad er bedre egentlig?, det er altid et trade off, noget andet bliver så ringere).
For dem med hang til det funtionelle kan man benytte Frege på JVM, det er der absolut intet i vejen for.
PS: Jeg er ikke helt med på hvad du har imod Javas arrays?
og C# for den sags skyld
Hvad er der usundt ved typesystemet i C#? Jeg er med på at det ikke helt så avanceret som hvad man ser andre steder, men usundt? Type systemet i Java blev en skandale da de lavede generics men C# / .Net er helt anderledes.
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).
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.
I lang tid var guidance på C# fronten at en valuetype (struct) skulle være max 16 bytes. Men den guidance var baseret på .NET's barndom. For 10 år siden fandt jeg at man fint kunne få god performance ud af 128 byte structs hvis man bare er omhyggelig. .NET Jit compileren er faktisk ret god til at optimere skidtet når den får muligheden. Med omhyggelig kodning fik man en performance der kun lå 10-15% under C++. Men der kræves at man ved hvad man laver.
Den nye form for identitet for værdityper...
Valhalla kunne have sparet rigtigt meget tid hvis Gosling ikke havde fucket op fra start. Identity, hashvalue og synchronization er ikke nyttige attributter for de fleste "objekter". Men Gosling valgte at en reference var det samme som identity og derfor kom det ud alle steder. Hans brug af == operatoren til at sammenligne identity var idiotisk. C# kopierede de tåbelige ting.
Da man opdagede fejlen skulle man have indført "light classes". Klasser uden ovennævnte attributter. Det havde gjort introduktion af value types meget nemmere og havde krævet minimale omskrivninger af koden.
"Over time every language evolves to look more and more like Standard ML".
Men hverken C# eller Java er på vej til at bliver pure functional. Og det bliver de aldrig. Så selvom ML ramte rigtigt på mange punkter så fejlede man da sproget blev (stort set) pure functional. Der problemer der løses bedst med functional programming og andre problemer der løses bedst med imperative programming.
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".
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.
Engang blev AR kaldt "syrerock", men prøv at lytte til den her!
Derfor er moderne CPU’er udstyret med deres egen hukommelse, L1-, L2- og L3-cache, så afviklingsmiljøet kan hente en ordentlig klump data fra heapspace i et hug, i stedet for at fordele byrden over mange små langsomme indlæsninger.
Vil man lave en "prefetch"-mekanisme? Den liniære PF er nornalt god, men begynder man at kunne cache explicit åbner man potentielt for trashing, som kan have uheldig følger.
Men lad os håbe, det hjælpe Java med IKKE at være 40% langsommere end fx compileret C++!
Hidtil har det oversete "emulator paradoks" (=lille VM) hjulpet lidt.