Universiteter dropper Java - programmeringsspråket raser på popularitets-ranking

[knutinh]

 

Hvorfor kan vi ikke bare spesifisere _hva_ vi ønsker å gjøre på en enkel, kompakt og bugfri måte, og så tar kompilatoren seg av mappingen til vilkårlig hardware (som gjerne skifter flere ganger i en software-snutts levetid).

 

Den eneste måten du oppnår dette på er å bruke et domenespesifikt språk (DSL). Det er tilfeller hvor kompilatoren klarer å bruke SIMD, men enda flere hvor den ikke klarer det. I tillegg kommer til som minnehierakier og optimal cache-utnyttelse, som i det hele gjør det ganske urealistisk å oppnå full ytelse kun fra kompilatorens side.

 

Fortran viser sin alder, også når det kommer til HPC forøvrig.

Forståelsen av at en hammer er best til spikring mens en sag er best til saging synes jeg er lite synlig i slike diskusjoner. "Domene spesifikt" trenger vel ikke å være en binær (enten-eller) egenskap. Forskjellige verktøy kan ha forskjellig anvendelse i forskjellige domener, og det er i prinsippet _mulig_,

men neppe lurt å skrive vaskemaskin-firmware i Excel. Poenget er at det ikke er mulig å lage en swiss army knife som er verdens beste kniv og samtidig best skrujern, neglesaks og whatnot.

 

Når domenet er beregninger på vektorer og matriser så synes jeg at både C og C++ viser tydelig at dette er langt unna deres kjerne-domene. Dette gir seg utslag i barokk kode (statements/kode-kompleksitet som framstår som unødvendig i en ideell verden) og ytelse som er dårligere enn hw er i stand til.

 

Noe av dette kan avhjelpes med bedre kompilatorer (Intel sin er ganske god), bruk av biblioteker til standard-funksjoner og å bruke en ekspert som spesialiserer seg på å jobbe rundt språk og kompilator for bedret ytelse.

 

Jeg gremmes ved hvor mye "fluff" man må pådra seg i C (for ikke å snakke om C++) for å gjøre noe enkelt som det under:

a = (1:16) + 1j*(2:17);b = randn(size(a));c = a + b;

Endret 21. juli 2017 av knutinh

[Gjest Slettet+5132]

 

 

Hvorfor kan vi ikke bare spesifisere _hva_ vi ønsker å gjøre på en enkel, kompakt og bugfri måte, og så tar kompilatoren seg av mappingen til vilkårlig hardware (som gjerne skifter flere ganger i en software-snutts levetid).

Den eneste måten du oppnår dette på er å bruke et domenespesifikt språk (DSL). Det er tilfeller hvor kompilatoren klarer å bruke SIMD, men enda flere hvor den ikke klarer det. I tillegg kommer til som minnehierakier og optimal cache-utnyttelse, som i det hele gjør det ganske urealistisk å oppnå full ytelse kun fra kompilatorens side.

 

Fortran viser sin alder, også når det kommer til HPC forøvrig.

Forståelsen av at en hammer er best til spikring mens en sag er best til saging synes jeg er lite synlig i slike diskusjoner.

 

Når domenet er beregninger på vektorer og matriser så synes jeg at både C og C++ viser tydelig at dette er langt unna deres kjerne-domene. Dette gir seg utslag i barokk kode (statements/kode-kompleksitet som framstår som unødvendig i en ideell verden) og ytelse som er dårligere enn hw er i stand til.

 

Noe av dette kan avhjelpes med bedre kompilatorer (Intel sin er ganske god), bruk av biblioteker til standard-funksjoner og å bruke en ekspert som spesialiserer seg på å jobbe rundt språk og kompilator for bedret ytelse.

 

Jeg gremmes ved hvor mye "fluff" man må pådra seg i C (for ikke å snakke om C++) for å gjøre noe enkelt som det under:

a = 1:16 + 1j*(2:17);
b = randn(size(a));
c = a + b;

 

Du glemmer at det finnes ting som Eigen samt std::complex, som kan forenkle eksempelet over og gjøre det essensielt ekvivalent til Fortran-kode. Fortran har ulemper i objektorienteringen (som ER nyttig i HPC), samt er det mer tungvindt å bruke ting som CUDA fra Fortran.  Template kan også gi deg en "mini DSL", som gjør at utbytting av kode kan gjøres enkelt og ytelsesoptimalt.

[knutinh]

std::complex

 

Hvis man må pepre koden med std::complex, autovector, stl, boost og for-løkker for å gjøre det jeg beskrev over så tyder det på at språket er spisset for noe annet enn det jeg beskrev over. Ikke noe galt med det, de færreste trenger å definere og så addere to komplekse vektorer veldig ofte. Men hvis man ofte gjør det så vil man selvsagt lete etter verktøy som gjør det behagelig.

Fortran har ulemper i objektorienteringen (som ER nyttig i HPC)

Som nevnt så har jeg ingen erfaring med HPC.

 

Min erfaring er at enkelt, rett-fram og lesbar kode har enorm egen-verdi. Og gi programmerere tilgang på et "rikt" språk som C++ med objektorientering og de surrer det til.

 

http://harmful.cat-v.org/software/c++/linus

 

-k

Endret 21. juli 2017 av knutinh

[Gjest Slettet+5132]

 

std::complex

Hvis man må pepre koden med std::complex, autovector, stl, boost og for-løkker for å gjøre det jeg beskrev over så tyder det på at språket er spisset for noe annet enn det jeg beskrev over. Ikke noe galt med det, de færreste trenger å definere og så addere to komplekse vektorer veldig ofte. Men hvis man ofte gjør det så vil man selvsagt lete etter verktøy som gjør det behagelig.

 

Det er greia, det er ingenting som sier at dette må være i språket. På grunn av operatoroverlasting kan man lage slike ting som bibliotek og få ytelse som om det var native i språket. I praktisk bruk er syntaksen ikke veldig forskjellig fra om det hadde vært innebygget i språket. I tillegg kan du med Eigen unngå for-løkker helt og bruke vektorsyntaks somm om det var i MATLAB, se eg. Eigen cheat sheet.

 

Jeg medgir derimot at C++ syntaks generelt er litt obskurt, men jeg vil ikke påstå at det er fordi det mangler innebygget støtte for det i språket.

 

 

 

Fortran har ulemper i objektorienteringen (som ER nyttig i HPC)

 

 

Som nevnt så har jeg ingen erfaring med HPC.

 

Min erfaring er at enkelt, rett-fram og lesbar kode har enorm egen-verdi. Og gi programmerere tilgang på et "rikt" språk som C++ med objektorientering og de surrer det til.

 

http://harmful.cat-v.org/software/c++/linus

 

-k

 

 

La oss ta et veldig enkelt bruksscenario i HPC / Simuleringer: Ulik filformat ved utskrift. Noen ganger vil en skrive til en CSV-fil, andre ganger til HDF5. Ved C++/Objektorientering, kan dette lett løses ved arv og virtuelle metoder. Siden det gjøres på filskrivningsnivå, vil ikke ytelsen lide heller. Uten objektsorientering, blir det litt mer komplisert. Du kan sende en funksjonspeker, men du får problemer med å sende andre data med (eg. filnavn som skal skrives til, ved HDF5 er det mer data som må holdes).

 

Det skal sies at det er mange som misbruker C++ (spesielt med template-bruk), så i den forstand kan jeg være enig med deg, men til HPC er det få gode alternativer.

Endret 21. juli 2017 av Slettet+5132

[zipline]

EDIT: Og jeg har også helt andre prinsipielle problemer med MATLAB. Jeg mener det er et stort problem hvis et programmeringsspråk en lærer på et universitet blir kontrollert av ett firma alene, og det i realiteten (siden Octave henger etter) kun er mulig å bruke språket mot betaling.

 

Derfor er det mye bedre aa bruke R!

Gratis, samt at nye metoder ofte blir implementert vesentlig raskere enn i Matlab. Men om du ikke liker vektorisering, saa har R selvfoelgelig ogsaa den samme svakheten som Matlab, at det blir tregt om du bruker for-loops paa enkle operasjoner.

[knutinh]

...om du ikke liker vektorisering, saa har R selvfoelgelig ogsaa den samme svakheten som Matlab, at det blir tregt om du bruker for-loops paa enkle operasjoner.

MATLAB var suppe-treigt på for-løkker. For 10+ år siden. Mye har blitt endret siden da:

https://se.mathworks.com/products/matlab/matlab-execution-engine.html

"The JIT compilation generates native machine level code that is optimized for the MATLAB code being executed and for the specific hardware platform."

 

I tillegg så har behovet for pre-allokering blitt mye mindre de siste åra.

 

Hvis problemet ditt mapper rent til Blas, FFTW etc så er MATLAB en behagelig tynn wrapper rundt blod-optimaliserte biblioteker.

 

Mange interessante problemer har en "twist" som gjør at de ikke mapper fullt så rent til biblioteker med et endelig antall funksjoner. Da må man evt jobbe litt mer for å få bra ytelse, kompakt kode og lesbarhet. Jeg synes at det er en interessant utfordring som ofte gir bedre innsikt i algoritmen og en bra forberedelse til å porte til produksjonskode.

 

Vektoriser, prealloker, husk column major vs row major, aktiv bruk av redusert presisjon datatyper, sjekk (det rike) settet av innebygde funksjoner. Bruk mex wrapping rundt C/Fortran for de få tingene som mapper dårlig til MATLAB (f.eks. ytelseskritisk custom seriell bit-fikling)

Endret 21. juli 2017 av knutinh

[Dreamspace]

Dersom man skal lære bort praktisk webdev på skolene, så må pensum oppdateres hver 2 år. Teknologien der utvikler seg for kjapt til at de fleste skoler kan henge med - derav en eksplosjon av bootcamps som lærer bort stacks som er i vinden for tiden. Skoler burde fortsette å fokusere på det fundamentale, som de alltid har gjort.

 

Dersom jeg skulle lært noen å programmere, og dekt det mest basic, så hadde jeg brukt følgende språk i rekkefølgen:

- Python (bli vant med å kode - intro programmering)

- C (lære minnehandtering - datastrukturer og algoritmer)

- Python, C++, Java, eller C# (OOP)

- SQL (Fundamental DB)

- HTML / CSS / jQuery / Bootstrap (basic webdev)

- React / Angular + Node (moderne webdev)

- Python + div. Bibliotek (basic data science og visualisering)

 

Den verktøykassen burde dekke minimum for jobber i 2017.(ja, noen vil kanskje også ta med Funksjonelle språk)

Har man stålkontroll på noen av de store multipurpose språka, så tar det ikke lange tiden å lære noe likt. But I digress

 

Python er et flott språk, og enda bedre for nybegynnere. Det viktigste i startfasen er at studentene synes det er morsomt å kode.

[Gjest Slettet+5132]

 

Mange interessante problemer har en "twist" som gjør at de ikke mapper fullt så rent til biblioteker med et endelig antall funksjoner. Da må man evt jobbe litt mer for å få bra ytelse, kompakt kode og lesbarhet. Jeg synes at det er en interessant utfordring som ofte gir bedre innsikt i algoritmen og en bra forberedelse til å porte til produksjonskode.

 

Vel, hvis du liker å bruke mye tid på å passe inn koden i vektoriseringsrammeverk, er det selvfølgelig greit, men for å sitere deg tidligere "Men hvis man ofte gjør det så vil man selvsagt lete etter verktøy som gjør det behagelig." Kanskje du bør titte på Julia?

[scav-]

Det er nesten tragisk at folk snakker om Golang lenger, men noen mennesker liker vel rett og slett språk uten noe reell syntaks og som egner seg best til copy paste kode bedre enn å faktisk skrive kode selv. En skal lete lenge etter et verre språk som tilsynelatende er populært. Javascript er vel det andre.

 

Personlig foretrekker jeg Haskell for alt man skryter av at Golang gjør bra. Bedre språk, bedre GC, bedre syntaks og bedre kompilator.

[spots]

 

JS og Python er kjekt det, men Java er nærmere metallet og lærer folk mer om hvordan en datamaskin faktisk fungerer. Man kan gjerne kvitte seg med Java, men man må undervise i språk på lavere nivåer enn JS/Python også om man skal få gode programmerere

 

Programmer som kjører i JVM kan vanskelig sies å være "maskinnære". Java er et kompilert språk, Python og Javascript interpreterte språk. Men å tukle med cpu-registre og slikt får du ikke lov til i noen av dem.

JVM er jo skrevet i C så vidt jeg vet.

[quantum]

 

 

JS og Python er kjekt det, men Java er nærmere metallet og lærer folk mer om hvordan en datamaskin faktisk fungerer. Man kan gjerne kvitte seg med Java, men man må undervise i språk på lavere nivåer enn JS/Python også om man skal få gode programmerere

Programmer som kjører i JVM kan vanskelig sies å være "maskinnære". Java er et kompilert språk, Python og Javascript interpreterte språk. Men å tukle med cpu-registre og slikt får du ikke lov til i noen av dem.

JVM er jo skrevet i C så vidt jeg vet.

Eh, ja, det er riktig. Og hvilket språk er diverse javascriptmotorer og pythoninterpreter skrevet i tror du? Endret 22. juli 2017 av quantum

[knutinh]

 

Mange interessante problemer har en "twist" som gjør at de ikke mapper fullt så rent til biblioteker med et endelig antall funksjoner. Da må man evt jobbe litt mer for å få bra ytelse, kompakt kode og lesbarhet. Jeg synes at det er en interessant utfordring som ofte gir bedre innsikt i algoritmen og en bra forberedelse til å porte til produksjonskode.

 

 

Vel, hvis du liker å bruke mye tid på å passe inn koden i vektoriseringsrammeverk, er det selvfølgelig greit, men for å sitere deg tidligere "Men hvis man ofte gjør det så vil man selvsagt lete etter verktøy som gjør det behagelig." Kanskje du bør titte på Julia?

Jeg bruker tiden min 1) på å prototype i MATLAB, 2) reimplementere i C og så 3) optimalisere/inline assembler.

 

Jeg tror kanskje at "kode kompleksitet" øker med 10x for hvert av stegene over, så også tiden brukt for å bygge opp tester og fikse bugs.

 

I en slik kontekst så er tiden brukt i MATLAB for å forstå problemstilling og løsning nesten alltid en bra ting. Hvis man grubler på en løsningsbeskrivelse på 1000 linjer så er man mye bedre rustet til å definere en lavnivå løsning på 10000 linjer.

 

Litt av frustrasjonen min var at trinn 1 og trinn 3 over har en naturlig kobling: vektorisering, numerikk. Trinn 2 oppleves ofte som en irriterende omvei.

 

Jeg har sett på Julia, men ikke lenge. En viktig motivasjon for MATLAB for meg er den uovertrufne IDE-en, visualisering, de utallige kokebøkene og eksemplene jeg finner på google og SO.

 

-k

[XTBVR43Z]

Det totale volumet søk går ned i følge figuren. Ingen spiser opp det Java og C går ned. Dette virker lite sannsynlig, er det andre kanaler som søkemotorene ikke fanger opp?

[Vinterskugge]

"på mange universiteter slipper man nå å forholde seg til public static void (String[] args)"

 

Det går raskare å skrive public static void (String... args). Og ofte blir main-metodane kalt direkte av anna kode istf å kun bli kjørt frå kommandolinja, då kan varargs vere praktisk.

 

Den gamle signaturen er sånn sett utdatert.

[Y4BNH49Z]

.. så nå må de forklare forklare hva dette betyr?

 

if __name__ == "__main__:

main()

[Gjest Slettet+5132]

.. så nå må de forklare forklare hva dette betyr?

 

if __name__ == "__main__:

main()

 

Det betyr to syntaxfeil!

[endrebjo]

Jeg har sett på Julia, men ikke lenge. En viktig motivasjon for MATLAB for meg er den uovertrufne IDE-en, visualisering, de utallige kokebøkene og eksemplene jeg finner på google og SO.

 

-k

Det siste året har jeg byttet ut Matlab med Python/Numpy/Scipy for mine signalbehandlings- og algoritmebehov (hovedsaklig RF- og FPGA-greier). Mitt inntrykk er at Python-svarene jeg finner på Google og SO er av høyere kvalitet enn Matlab-svarene på de tilsvarende sidene. Jeg mistenker at dette kan komme av at Matlab-spørsmål også blir besvart gjennom lukket support.

Uansett så er jeg fornøyd med Spyder IDE'en og visualiseringsmulighetene med matplotlib. Matplotlib er riktignok et hakk eller to treigere enn Matlab på store datasett, men jeg klarer stort sett å holde meg under den merkbare grensen. Og hele miljøet du trenger får du gjennom f.eks Anaconda.

Hvis du tar en kikk på Numpy for Matlab-brukere, ser du fort at det i mange tilfeller er en 1-til-1-mapping mellom Matlab- og Numpy-funksjonalitet. Dette gjør det veldig enkelt å porte Matlab til Python.

For meg er det to enorme fordeler med Python fremfor Matlab:

- Python er et langt mer elegant språk enn Matlab. For meg virker det som at Matlab ikke klarer å bli kvitt eldgammelt rusk fra fortiden, og det gjør hele språket til et stort lappeverk av rare funksjoner, klønete syntaks og ulogisk oppførsel.

- Det jeg skriver i Python kan mye lettere deles med andre siden mottaker ikke er avhengig av dyr programvare. Og jeg kan også enklere utvikle off-site uten å styre med lisensserverene på jobb.

 

Det største ankepunktet for min del er at det ikke finnes noen åpne ekvivalenter til Simulink og dens interface mot FPGA-programvare. Hvis du har behov for sånt kommer du ikke unna Matlab.

 

Jeg venter med å hoppe på Julia-karusellen inntil de har nådd v1.0. Når jeg utvikler er jeg stort sett ikke begrenset av kjøretiden på det jeg skriver, så jeg trenger foreløpig ikke super-ytelsen fra Julia. Med pre-v1.0-versjoner er det alltid en viss fare for at kompatibilitet mellom versjoner brekker, og å fikse den typen problemer er bortkastet tid for min del.

[Gjest Slettet+5132]

Og la oss ikke glemme herlige jupyter Notebook til python (og andre). Integrerer perfekt med matplotlib -- må prøves.

[knutinh]

Og la oss ikke glemme herlige jupyter Notebook til python (og andre). Integrerer perfekt med matplotlib -- må prøves.

Mathworks har Live Script som fyller noe av den samme nisjen, dog med endel begrensninger:

https://se.mathworks.com/help/matlab/matlab_prog/what-is-a-live-script.html

 

Videre så kan man installere Matlab Mobile på telefonen som eksekverer Matlab-skript ute i skyen og få resultatet tilbake. Som en bonus er da alle toolbokser inkludert.

 

-k

[Flin]

Personlig er jeg ingen fan av JAVA, jeg synes det blir så mye tekst og et par andre ting jeg blir sliten av. Hvis jeg hadde jobbet mer med det hadde jeg kanskje vendt meg til det. Skulle jeg utvikle en app så hadde jeg lært meg JAVA og skrevet kode uten å klage.

 

Det er faktisk ikke så stor forskjell på språkene og det er ikke så vanskelig å lære seg et nytt. For å sette det litt på spissen: Du er en dårlig programmerer hvis du kun kan jobbe med ett språk, hvis du kan få til alt med JAVA og tingen ting med C. Forskjellige språk har forskjellige fordeler og ulemper, bruk det som passer best til din situasjon.

 

Til daglig skriver jeg kode i Fortran, Python og C. Av og til må jeg innom IDL, Matlab, JS, HTML eller andre språk jeg bruker mindre. Jeg er helt klart best med de tre første, men jeg kan få til  et helt ok JS.

 

Når det kommer til Fortran og superdatamaskiner, jeg skjønner ikke påstanden om at at Fortran ikke fungerer så godt. Du kan integrere CUDA uten problemer, og hvis du synes det skulle være så vanskelig så kan du jo bare skrive CUDA delen i C/C++. Mitt hoved problem med Fortran er at det ikke er et populært språk som det utvikles like mange biblioteker til som andre språk.

Ta for eksempel https://bitbucket.org/blaze-lib/blaze, som er et veldig interessant bibliotek. Det finnes bare for C++. Klart hvis jeg vil implementere det inn i min kode så kan jeg bare skrive den modulen i C++, men det er litt ekstra arbeid. Kanskje det er lettere å skrive noen wrapper funksjoner.

 

Uansett, poenget er at det er tullete å krangle om hvilket språk som er best. Det handler om personlige preferanser og hva man forsøker å gjøre. Hvis dere bare behersker ett språk, eller nekter å bruke noen språk, så går dere glipp av veldig mye. Slike programmerer anser jeg ikke som veldig gode. Man burde kunne bruke et hvilket som helst språk hvis man må.