Gå til innhold

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


Anbefalte innlegg

Videoannonse
Annonse
Gjest Slettet+5132

Du må nødvendigvis lære et relativt lavtnivåspråk som C om du skal lære hvordan PCen faktisk fungerer, da du kan bruke det til mer effektiv kode på høyere nivå. Men det spørs jo egentlig helt hvilken retning du går. Skal du bruke koden til "egenlaget" HW så er du gjerne ned på assembly nivå. Går du design og interaksjon så holder du deg nok på høynivå programmering hele tiden.

Jeg vil nå påstå at hvis man vil lære hvordan maskinen fungerer, burde man ned på assembler. I C må du rett nok styre minnet selv, men du får ikke skitnet til hendene som du får når du skal flytte minne inn til registrene osv. Jeg kjenner flere som kan C-programmering, men som ikke har den døyteste anelse om registere eller flyttallsoperasjoner. :) Det å kjenne til assembler kan gjøre at en får et litt annet syn på hvor kostbare beregninger er.

 

Men alt med måte, i praktisk bruk ville jeg kun brukt assembler som du beskriver det, altså til egenlaget HW.

 

 

Stort sett velges språket utifra det en skal gjøre. Skal en lære om objektorientert programmering må en naturligvis ha et språk som er objektorientert. Skal en bruke språket til matematiske beregninger, så er det ingen dum ide å velge et med ganske likt syntaks som Matlab som er laget for å utføre rimelig avanserte kalkulasjoner på en enkel måte. Skal du lære hvordan en CPU er laget eller lignende er ikke VHDL/Verilog/Assembly dumt. Alt i alt har introspråket lite å si. Det er jo det grunnlegende.

For det første kan man gjøre objektorientering i C (ikke at jeg anbefaler det :p ), det er omtrent slik GTK (Gimp Toolkit) er bygget opp. Det blir ikke pent, men det fungerer.

 

Når det gjelder MATLAB og avanserte matematiske beregninger, må jeg dessverre si meg dypt uenig. MATLAB er veldig bra for ting som kan representeres som vektor- eller matriseoperasjoner, for alt annet blir det veldig tungvindt på grunn av ytelseshensyn. Så essensielt vil jeg påstå MATLAB er veldig bra for enkle matematiske beregninger, men med en gang det blir litt hårete, må man over i et annet språk (Julia er en het kandidat, som essensielt er MATLAB med bedre ytelse for ting som ikke kan skrives som vektor- eller matriseoperasjoner). Når de matematiske beregningene blir større i omfang, er nok C/C++ eneste utvei (Til dere Fortran-elskere: Gå tilbake til 70-tallet! :p)

 

Lenke til kommentar

JavaScript er et serverside-språk, og brukes også til andre ting enn kun å kjøre i en nettleser.

Sant nok. Og Java ble hypa som browserspråk i gode gamle dager. Men hvor mange bruker node.js til serverside ting fordi det føles hjemmkoselig for en webutvikler som må kode backend, og hvor mange gjør det fordi de har foretatt en kvalifisert vurdering til fordel for node.js istedenfor Java/spring/jee?

Lenke til kommentar

Lurt å lese kommentarene på reddit og ikke bare copy pasta random artikler.

 

 

Not only is this article poorly written but it's also factually incorrect. Stanford University is not dropping Java as an introductory programming language.

Stanford offers its introductory programming course in Java four times a year, once every quarter. Stanford will continue to do this. This year, they are expanding to essentially offer the course 7 times, adding two new versions of the class, one in Python (offered twice) and one in Javascript (offered once).

As you can imagine, intro to programming is the most popular course at Stanford with almost 2000 students taking it every year. Something like 90% of undergrads and 50% of graduate students take the class before graduating.

/u/lolzfeminism

  • Liker 2
Lenke til kommentar

De dropper Java i betydningen dropper Java i introduksjonskurset. Utover det er artikkelen en av utallige tilsvarende idiot-artikler om "Javas død". Vi er riktig nok i agurktiden nå, men det er vel bare en ting som er verre enn agurker, nemlig resirkulerte agurker.

Lenke til kommentar

Sant nok. Og Java ble hypa som browserspråk i gode gamle dager. Men hvor mange bruker node.js til serverside ting fordi det føles hjemmkoselig for en webutvikler som må kode backend, og hvor mange gjør det fordi de har foretatt en kvalifisert vurdering til fordel for node.js istedenfor Java/spring/jee?

 

De fleste tar nok en kvalifisert avgjørelse om å benytte Node, ettersom det har både fordeler og ulemper å velge et event-drevet språk i stedet for språk som i større grad bruker tråder.

 

Likevel, JavaScript brukes til stadig nye ting, og en JavaScript-motor, slik som V8 som brukes i Node, kan implementeres nær sagt hvor som helst.

 

Poenget var at det ikke er utelukkende front-end utviklere som bruker JavaScript, språket benyttes på serversiden, i .pdf filer, diverse "office" løsninger (OpenOffice bl.a), IRC klienter, tillegg til nettlesere samt diverse program som gjør det enklere å lage applikasjoner til flere platformer, slik som PhoneGap e.l.

 

 

Har selv holdt på en del med assembler, turbo pascal, til og med Basic for mange år siden, men skal man nærmere metallet uten å slite seg i hjel i assembler, er Fortran et greit alternativ.

C/C++ er vel fremdeles mest brukt for programvare, spill og den slags, samt Apples styggedom Objective C, som heldigvis er byttet ut med Swift.

Skal man drive med noe som helst innen finanssektoren, er kunnskap om Cobol nærmest påkrevd.

 

Java lever nok også i veldig mange år enda, alt fra mesteparten av Android, ElasticSearch, Hadoop, HBase, Eclipse, politiets nye DNA-register, OpenOffice, menyene på Bluray-plater og veldig mye annet er tross alt skrevet i Java.

Lenke til kommentar

 

Du må nødvendigvis lære et relativt lavtnivåspråk som C om du skal lære hvordan PCen faktisk fungerer, da du kan bruke det til mer effektiv kode på høyere nivå. Men det spørs jo egentlig helt hvilken retning du går. Skal du bruke koden til "egenlaget" HW så er du gjerne ned på assembly nivå. Går du design og interaksjon så holder du deg nok på høynivå programmering hele tiden.

Jeg vil nå påstå at hvis man vil lære hvordan maskinen fungerer, burde man ned på assembler. I C må du rett nok styre minnet selv, men du får ikke skitnet til hendene som du får når du skal flytte minne inn til registrene osv. Jeg kjenner flere som kan C-programmering, men som ikke har den døyteste anelse om registere eller flyttallsoperasjoner. :) Det å kjenne til assembler kan gjøre at en får et litt annet syn på hvor kostbare beregninger er.

 

Men alt med måte, i praktisk bruk ville jeg kun brukt assembler som du beskriver det, altså til egenlaget HW.

 

 

Stort sett velges språket utifra det en skal gjøre. Skal en lære om objektorientert programmering må en naturligvis ha et språk som er objektorientert. Skal en bruke språket til matematiske beregninger, så er det ingen dum ide å velge et med ganske likt syntaks som Matlab som er laget for å utføre rimelig avanserte kalkulasjoner på en enkel måte. Skal du lære hvordan en CPU er laget eller lignende er ikke VHDL/Verilog/Assembly dumt. Alt i alt har introspråket lite å si. Det er jo det grunnlegende.

For det første kan man gjøre objektorientering i C (ikke at jeg anbefaler det :p ), det er omtrent slik GTK (Gimp Toolkit) er bygget opp. Det blir ikke pent, men det fungerer.

 

Når det gjelder MATLAB og avanserte matematiske beregninger, må jeg dessverre si meg dypt uenig. MATLAB er veldig bra for ting som kan representeres som vektor- eller matriseoperasjoner, for alt annet blir det veldig tungvindt på grunn av ytelseshensyn. Så essensielt vil jeg påstå MATLAB er veldig bra for enkle matematiske beregninger, men med en gang det blir litt hårete, må man over i et annet språk (Julia er en het kandidat, som essensielt er MATLAB med bedre ytelse for ting som ikke kan skrives som vektor- eller matriseoperasjoner). Når de matematiske beregningene blir større i omfang, er nok C/C++ eneste utvei (Til dere Fortran-elskere: Gå tilbake til 70-tallet! :p)

 

 

Hehe, jeg mente å lære C for å vite mer om hvordan OSet fungerer. Lavere nivå enn Java/C#, men definitivt ikke vite hvordan maskinen fungerer nivå som du helt korrekt skriver. 

 

Jeg tenkte MATLAB til personlig bruk for universiteter. Altså som et verktøy for å utføre beregningene som de må utføre. Så er vel perspektiv da hva en tenker på som tyngre og lettere beregninger. Jeg tenkte vel mer på det som steget etter vitenskapelige kalkulatorer. Og så har du den problemstillingen med at folk som studerer mye matematikk, studerer lite programmering. Og de som studerer mye programmering studerer lite matematikk. Så selv om de gjerne kommer på et nivå hvor MATLAB er mer ineffektivt og noe annet burde ha blitt benyttet så måtte de da lært seg C/C++, noe en ikke gjør på noen mattematikkstudier jeg kjenner til. Vanskelig å være ekspert i to ting samtidig :) Spesielt det å kode beregninger i parallell effektivt er vanskelig om du ikke har mye koding. MATLAB gjør ting enklere.  

 

Men regner med den type beregninger du gjør/tenker på så tror jeg deg på at C/C++ er det som teller. Ikke at jeg vet noe om det da, men det gjør åpenbart du :) Jeg har en følelse av at det også involverer en del parallellisering.

 

Men ja poenget er jo at du lærer språk i forhold til det du skal gjøre. Så hva du lærer i introduksjonen er ikke akkurat representativt for hva du vil bruke senere. Og det viktigste å lære er jo hvordan du skal tenke, gå frem når du koder. Du vil gå gjennom mange språk, og du begynner ikke akkurat super-grunnleggende og går gjennom alt for hvert nye språk. Og hvis du faktisk går på UiO sine nettsider så ser du at selv om første semester er Python, så er fortsettelsen undervist i Java.

 

 

Fant faktisk denne fordypningen innenfor matematikk ved UiO:

http://www.uio.no/studier/program/matematikk-informatikk/studieretninger/beregningsorientert-informatikk/oppbygging/

 

Der har et fag for parallellprogrammering der C/C++ er anbefalt forkunnskap. Så da finnes det faktisk. Matematikk med informatikk, studieretning beregningsorientert informatikk.

Lenke til kommentar
Gjest Slettet+5132

Internasjonalt kalles gjerne tungberegningsretningen innenfor matematikk CSE -- Computational Science and Engineering. Det begynner å bli stort i utlandet, og UiO har vært tidlig ute i internasjonal sammenheng med blant annet den retningen du peker på. 
 
Uansett mener jeg MATLAB er et hinder heller enn et verktøy i undervisningen. Med en gang en skal ha bittelitt kompliserte beregninger (eg. løse en PDE i en dimensjon) må en til med vektorisering for å ha brukbar hastighet. Dessverre er vektoriseringssyntaksen ganske langt fra den matematiske beskrivelsen. I matematisk sammenheng vil en kanskje skrive 
 chart?cht=tx&chl=for j=2,\ldots, N:
chart?cht=tx&chl=u^{j}_{n+1}=u_n^j+\frac{\Delta t}{\Delta x} (u^n_j-u^n_{j-1})
 
mens i MATLAB må en, for å få brukbar ytelse, skrive noe ala (med forbehold om småfeil!)
 

u(n+1,2:end) = u(n,2:end) - (dt/dx) * (u(n,2:end) - u(n,1:end-1));

som er betydelig vanskeligere å lese. Sammenlikner en det med et språk som klarer å kjøre for-loops effektiv, får en noe ala

for j in range(2,N):
    u[n+1,j] = u[n,j] - (dt/dx) *(u[n,j]-u[n,j-1])

som må sies å være betydelig nærmere den matematiske formuleringen. Det er uansett her Julia viser sin fordel!

 

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.

Endret av Slettet+5132
Lenke til kommentar

 

Skal man drive med noe som helst innen finanssektoren, er kunnskap om Cobol nærmest påkrevd.

 

Java lever nok også i veldig mange år enda, alt fra mesteparten av Android, ElasticSearch, Hadoop, HBase, Eclipse, politiets nye DNA-register, OpenOffice, menyene på Bluray-plater og veldig mye annet er tross alt skrevet i Java.

 

 

 

For ikke å snakke om finans, Java er det nye Cobol, vet du. For å være helt ærlig så har jeg ikke sett snurten av noe Cobol i alle de åra jeg har jobba i finans, men jeg vet det lurer bak der på noen av stormaskinene rundt omkring.

Lenke til kommentar

Java har litt stort og krevende kjøremiljø samt høyt minneforbruk til å egne seg i moderne konteiner miljøer. Det er ikke det at det ikke fungerer, men det er ikke i nærheten så effektivt som Golang. Om en bryr seg om responstider er også Golang vesentlig bedre enn Java pga vesentlig lavere GC tider. Derfor er det nok mange bedrifter av de med litt mer foroverlente utviklere som vurderer migrering fra Java til Golang som gjerne også gir høyere produktivitet enn Java. Golang fungerer utmerket til det meste av foretningslogikk så langt en ikke har svært harde realtime krav, da må en nok over på GC frie alternativer som C/C++ eller Rust uansett, men de er typisk mindre produktive språk og for C/C++ sin del er det en del ekstra bugs en står i fare for å pådra seg.

 

I undervisningsøyemed tenker jeg Python er helt ok, men undres litt over at en ikke bruker et språk med mer moderne concurrency modeller, som CSP, slik Golang har.

  • Liker 1
Lenke til kommentar

...foroverlente utviklere som vurderer migrering fra Java til Golang som gjerne også gir høyere produktivitet enn Java.

 

Det er nok mange foroverlente utviklere, samt selskapene disse utviklerne jobber i, som synes "Go" høres litt for mye ut som "Google", og derfor ikke helt kjøper reklamen om hvor fantastisk det er.

 

Jeg har prøvd Go, å synes det var forholdsvis enkelt og greit å komme i gang, å lengre har jeg ikke kommet, men det er og blir et "Google-produkt", selv om det er open-source.

 

Om en bryr seg om responstider er også Golang vesentlig bedre enn Java pga vesentlig lavere GC tider.

Så vidt jeg kan huske, er GC betydelig dårligere i Go, og compileren er heller dårlig implementert med ingen mulighet for justering.

Nå vet jeg at de har forbedret GC betydelig de siste to-tre årene i Go, ettersom det var et av de store ankepunktene for å bruke språket.

Endret av adeneo
Lenke til kommentar

Er ferdigutdannet nå og jobber med innføring av nytt e-læringssystem på NTNU. Det første jeg møtte på gamle HIST( Nåværende NTNU) var VB.net, før vi ble kastet over på Javascript. Tok PHP og Pythn på siden.

 

Python er ikke dumt, kan brukes til så mye og lettlest for nye som skal lære seg å skrive kode.

 

Husker jeg tok noen kurs i webutvikling på Hist for kanskje 4år tilbake. Det var trist og helt hårreisende utdatert stoff de lærte bort. Tabeller for layout og mye annet dårlig. Undervisninstoffet var flere år gamle pdf'er og ingen forelesninger. Fikk ikke noe svar på kritikken da jeg skrev til dem heller.

Lenke til kommentar

 

Du må nødvendigvis lære et relativt lavtnivåspråk som C om du skal lære hvordan PCen faktisk fungerer, da du kan bruke det til mer effektiv kode på høyere nivå. Men det spørs jo egentlig helt hvilken retning du går. Skal du bruke koden til "egenlaget" HW så er du gjerne ned på assembly nivå. Går du design og interaksjon så holder du deg nok på høynivå programmering hele tiden.

Jeg vil nå påstå at hvis man vil lære hvordan maskinen fungerer, burde man ned på assembler. I C må du rett nok styre minnet selv, men du får ikke skitnet til hendene som du får når du skal flytte minne inn til registrene osv. Jeg kjenner flere som kan C-programmering, men som ikke har den døyteste anelse om registere eller flyttallsoperasjoner. :) Det å kjenne til assembler kan gjøre at en får et litt annet syn på hvor kostbare beregninger er.

 

Men alt med måte, i praktisk bruk ville jeg kun brukt assembler som du beskriver det, altså til egenlaget HW.

 

Stort sett velges språket utifra det en skal gjøre. Skal en lære om objektorientert programmering må en naturligvis ha et språk som er objektorientert. Skal en bruke språket til matematiske beregninger, så er det ingen dum ide å velge et med ganske likt syntaks som Matlab som er laget for å utføre rimelig avanserte kalkulasjoner på en enkel måte. Skal du lære hvordan en CPU er laget eller lignende er ikke VHDL/Verilog/Assembly dumt. Alt i alt har introspråket lite å si. Det er jo det grunnlegende.

For det første kan man gjøre objektorientering i C (ikke at jeg anbefaler det :p ), det er omtrent slik GTK (Gimp Toolkit) er bygget opp. Det blir ikke pent, men det fungerer.

 

Når det gjelder MATLAB og avanserte matematiske beregninger, må jeg dessverre si meg dypt uenig. MATLAB er veldig bra for ting som kan representeres som vektor- eller matriseoperasjoner, for alt annet blir det veldig tungvindt på grunn av ytelseshensyn. Så essensielt vil jeg påstå MATLAB er veldig bra for enkle matematiske beregninger, men med en gang det blir litt hårete, må man over i et annet språk (Julia er en het kandidat, som essensielt er MATLAB med bedre ytelse for ting som ikke kan skrives som vektor- eller matriseoperasjoner). Når de matematiske beregningene blir større i omfang, er nok C/C++ eneste utvei (Til dere Fortran-elskere: Gå tilbake til 70-tallet! :p)

 

Min interesse er dsp, ikke hpc eller web.

 

Jeg opplever ofte at MATLAB->assembler er en naturlig overgang, mens C oppfattes som en forstyrrende omvei.

 

MATLAB lar meg prototype ting kjapt, og mange av mine syssler går også tålelig kjapt.

 

Assembler er å kommunisere direkte med cpu og eksponerer alle muligheter (inklusive muligheten til å skyte seg selv solid i foten).

 

C er vel egentlig et språk for å skrive kompilatorer og operativ-system. Det at det brukes til relativt lavnivå tallknusing er vel bare i mangel av noe bedre (og ja, jeg antar at FORTRAN ville ha vært bedre men har minimal erfaring der).

 

-k

Endret av knutinh
Lenke til kommentar

C lar deg kode SIMD, og gjør det enkelt å kalle på disse funksjonene fra andre språk som Python, Lua osv. Dermed kan en sitte å kode matematiske beregninger i Python med minimalt ytelsestap.

 

Fortran har noen spesielle regler som gjør at optimalisering under kompilering kan bli mer aggresivt enn C. På 80/90-tallet var dette en fordel, men idag kan en fint gå rundt dette med C.

Lenke til kommentar

C lar deg kode SIMD, og gjør det enkelt å kalle på disse funksjonene fra andre språk som Python, Lua osv. Dermed kan en sitte å kode matematiske beregninger i Python med minimalt ytelsestap.Fortran har noen spesielle regler som gjør at optimalisering under kompilering kan bli mer aggresivt enn C. På 80/90-tallet var dette en fordel, men idag kan en fint gå rundt dette med C.

Spørsmålet som dukker opp er hvorfor vi ofte må dille med intrinsics i C for at algoritmen skal kunne nyttiggjøre seg (feks) SIMD hardware.

 

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).

 

Poenget ditt med aliasing av pekere og restrict (?) er greit nok, C-kode kan ofte skrives på en slik måte at man ender opp nært hardwarens begrensninger - gitt dyp kunnskap om C, kompilator, hardwaren man kjører på og inspeksjon av assembler output som få programmerere har eller har tid til å gjøre. Jeg er i tvil om C er den kjappeste veien til målet, gir mest hw uavhengig kode, best vedlikeholdbarhet og færrest bugs.

 

Jeg er dog helt overbevist om at C++ _ikke_ er veien dit.

 

-k

Endret av knutinh
Lenke til kommentar
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.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...