Gjest Slettet+5132 Skrevet 20. juli 2017 Del Skrevet 20. juli 2017 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 ), 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! ) Lenke til kommentar
quantum Skrevet 20. juli 2017 Del Skrevet 20. juli 2017 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
evilGuy Skrevet 20. juli 2017 Del Skrevet 20. juli 2017 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 2 Lenke til kommentar
quantum Skrevet 20. juli 2017 Del Skrevet 20. juli 2017 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
0laf Skrevet 20. juli 2017 Del Skrevet 20. juli 2017 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
Lunaris Skrevet 20. juli 2017 Del Skrevet 20. juli 2017 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 ), 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! ) 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 Skrevet 20. juli 2017 Del Skrevet 20. juli 2017 (endret) 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 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 20. juli 2017 av Slettet+5132 Lenke til kommentar
quantum Skrevet 20. juli 2017 Del Skrevet 20. juli 2017 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
Anders Jensen Skrevet 20. juli 2017 Del Skrevet 20. juli 2017 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. 1 Lenke til kommentar
0laf Skrevet 20. juli 2017 Del Skrevet 20. juli 2017 (endret) ...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 20. juli 2017 av adeneo Lenke til kommentar
knopflerbruce Skrevet 20. juli 2017 Del Skrevet 20. juli 2017 Bare for å pirke: INF1000 hadde Java i hele sitt livsløp, og ble "erstattet" av IN1000, som er Python-basert. Lenke til kommentar
phel21 Skrevet 20. juli 2017 Del Skrevet 20. juli 2017 Grafen i artikkelen må mangle viktige komponenter. Den viser ingen økning for noen programmeringsspråk som tilsvarer fallet i popularitet for C og Java de siste årene. Hvor ble alle de prosentene av? Lenke til kommentar
abooAyoob Skrevet 20. juli 2017 Del Skrevet 20. juli 2017 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
knutinh Skrevet 20. juli 2017 Del Skrevet 20. juli 2017 (endret) 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 ), 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! ) 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 20. juli 2017 av knutinh Lenke til kommentar
quantum Skrevet 20. juli 2017 Del Skrevet 20. juli 2017 Hvordan er økosystemet til golang vs Java? Lenke til kommentar
siDDis Skrevet 20. juli 2017 Del Skrevet 20. juli 2017 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
Paul Birgensen Skrevet 20. juli 2017 Del Skrevet 20. juli 2017 C er tingen for nye CS studenter, noe Harvard har forstått . 1 Lenke til kommentar
knutinh Skrevet 21. juli 2017 Del Skrevet 21. juli 2017 (endret) 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 21. juli 2017 av knutinh Lenke til kommentar
Gjest Slettet+5132 Skrevet 21. juli 2017 Del Skrevet 21. juli 2017 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
Anbefalte innlegg
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 kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå