Gå til innhold

Holgers lille NTNU-tråd | *Se første post for spørsmål om hybel*


HolgerL

Hvilket sted tilhører du?  

1 456 stemmer

  1. 1. Velg ett av alternativene

    • Dragvoll
      254
    • Gløshaugen
      1018
    • Annet
      202


Anbefalte innlegg

Videoannonse
Annonse

Du får melde deg opp til kont om du leverer blankt (skjema om avbrutt eksamen) eller stryker. Om du vet det blir F på besvarelsen er det bedre å levere nevnte skjema da det etter det jeg har fått med meg koster NTNU penger å rette besvarelser selv om de er tomme.

Lenke til kommentar

Ja, Java er nyttig hvis du skal bli corporate programmeringsape.

Det er det man tjener penger på, ja, men det er ikke det som gjør python dårlig. Finnes også mange andre snasene språk med omtrent samme syntaks:)

Hva gjør python dårlig, og hvilke andre general purpose-programmeringsspråk ville du anbefalt å undervise i et introkurs...?

Lenke til kommentar

Ja, Java er nyttig hvis du skal bli corporate programmeringsape.

Det er det man tjener penger på, ja, men det er ikke det som gjør python dårlig. Finnes også mange andre snasene språk med omtrent samme syntaks:)

Hva gjør python dårlig, og hvilke andre general purpose-programmeringsspråk ville du anbefalt å undervise i et introkurs...?

Hvor dårlig det er kommer litt ann på konteksten, men hovedproblemet er at språket i mine øyne skalerer veldig dårlig i forhold til størrelsen på et prosjekt. Dynamisk typing og mangelen på synlighetsmodifikatorer har mye av skylden for dette, da det over tid blir veldig vanskelig å holde styr på hva kode faktisk gjør og hvordan det skal brukes, særlig i prosjekter med flere personer. Dynamisk typing gjør det også veldig vanskelig å lage en fornuftig IDE som typisk hjelper til med å holde styr på større prosjekter.

 

Problem nummer to er manglen på krøllparanteser for scope. Dette går vanligvis greit for en enkelt person, men så fort man sitter å jobber flere samtidig med forskjellige editorer kombinert med litt copy and paste ender man fort opp med indenteringsproblemer. I et språk med krøllparanteser kan en IDE holde styr på riktig indentering, mens man i python blir nødt til å lese igjennom koden for å se hva som skal være hvor.

 

Problem 3 er at man ikke har noen kompilator som finner små fillefeil. Man er faktisk nødt til å kjøre programmet og treffe den spesifikke kodestien som trigg feilen.

 

Problem 4 språket er i dag fragmentert mellom versjon 2 og 3 som gir mange morsomme feil om man ikke følger med.

 

Jeg vil heller anbefale språk som C++, Java, Scala eller C#. Kanskje C++ siden den har minst syntaks fiksfakseri man trenger å lære for å skrive simple ikke objektbaserte programmer samtidig som det er relativt intuitivt å relatere det til hvordan en datamaskin fungerer (da jeg var studass i java virket det for meg som folk forstod konspeptene mye bedre hvis man gjorde et forsøk på å fjerne "magien" som ligger mellom programmeringsspråket og datamaskinen).

 

Edit: vil bare legge til at man ikke trenger å gå veldig dypt inn i c++ i et introkurs, så det treng ikke å være spesielt mye vanskeligere enn f.eks. Python, men kanskje mindre ekspessivt).

Endret av Turgon
  • Liker 4
Lenke til kommentar

Dynamisk typing gjør det også veldig vanskelig å lage en fornuftig IDE som typisk hjelper til med å holde styr på større prosjekter.

 

Virkelig? Det ville jo gjort det enklere siden en IDE kan kjøre en python-interpreter i bakgrunnen og hente ut masse metainformasjon. En IDE for et statisk språk er nødt til å parse, tyde, og i visse tilfeller kompilere kildekoden. Når har du forresten behov for å lage din egen IDE?

 

Problem nummer to er manglen på krøllparanteser for scope. Dette går vanligvis greit for en enkelt person, men så fort man sitter å jobber flere samtidig med forskjellige editorer kombinert med litt copy and paste ender man fort opp med indenteringsproblemer.

 

Muligens om man bruker Notepad.

PROTIP: Bli enig om hvor mange space dere skal bruke for å identere, og ikke miks tab og space.

 

I et språk med krøllparanteser kan en IDE holde styr på riktig indentering, mens man i python blir nødt til å lese igjennom koden for å se hva som skal være hvor.

 

Hvorfor er dette vanskeligere for et språk som bruker whitespace som identering? Det ser ikke ut som du kan noen ting om parsing, og da synes jeg ikke at du skal uttale deg om det.

 

Problem 4 språket er i dag fragmentert mellom versjon 2 og 3 som gir mange morsomme feil om man ikke følger med.

 

Hvis du definerer "å følge med" som å vite hvor man er, eller hvilket språk man programmerer i.

 

Jeg vil heller anbefale språk som C++, Java, Scala eller C#. Kanskje C++ siden den har minst syntaks fiksfakseri man trenger å lære for å skrive simple ikke objektbaserte programmer

 

C++ har minimal syntaks? luls. Python har nesten ingen syntaks hvis man bare holder seg til å kun skrive imperative programmer.

 

samtidig som det er relativt intuitivt å relatere det til hvordan en datamaskin fungerer (da jeg var studass i java virket det for meg som folk forstod konspeptene mye bedre hvis man gjorde et forsøk på å fjerne "magien" som ligger mellom programmeringsspråket og datamaskinen).

 

Var du studass i Java? Please tell me more about your expertise in teaching. Per ditt argument så burde jo assemblyspråk være enklere å programmere i siden det er nærmere hardware.

  • Liker 6
Lenke til kommentar

Problem nummer to er manglen på krøllparanteser for scope. Dette går vanligvis greit for en enkelt person, men så fort man sitter å jobber flere samtidig med forskjellige editorer kombinert med litt copy and paste ender man fort opp med indenteringsproblemer. I et språk med krøllparanteser kan en IDE holde styr på riktig indentering, mens man i python blir nødt til å lese igjennom koden for å se hva som skal være hvor.

Dette er spesifisert gjennom PEP 8, hvor standarden er fire spaces per tabulering. Hvis prosjektet ditt ikke klarer å standardisere dette, så vil du få like mye trøbbel med identeringsfeil i andre språk (K&R-stil? Allman? osv.)

 

Problem 3 er at man ikke har noen kompilator som finner små fillefeil. Man er faktisk nødt til å kjøre programmet og treffe den spesifikke kodestien som trigg feilen.

Det er ikke sånn man skal bruke en kompilator. Til dette bruker man typisk enhetstester, eller et IDE med LINTing.

 

Problem 4 språket er i dag fragmentert mellom versjon 2 og 3 som gir mange morsomme feil om man ikke følger med.

Ja, akkurat som hvis du kompilerer C++ med forskjellige ekstrabiblioteker, som du trenger mange av siden språket inkluderer såpass lite grunnfunksjonalitet. Skillet mellom 2 og 3 er ikke spesielt stort og det er uansett sånn at de aller fleste prosjekter bruker 2.x hvor ting er veldig stabilt.

 

Jeg vil heller anbefale språk som C++, Java, Scala eller C#. Kanskje C++ siden den har minst syntaks fiksfakseri man trenger å lære for å skrive simple ikke objektbaserte programmer samtidig som det er relativt intuitivt å relatere det til hvordan en datamaskin fungerer (da jeg var studass i java virket det for meg som folk forstod konspeptene mye bedre hvis man gjorde et forsøk på å fjerne "magien" som ligger mellom programmeringsspråket og datamaskinen).

namespace::lol<type>(Blabla())

 

Jeg anser meg selv som en stor fan av C++. Å anbefale det fremfor Python fordi det har lite fiksfakseri er det rene vannvidd. Jeg har vært studass i flere år. Hva tror du er lettest å forklare for en som aldri har sett en forløkke før?

for(int i = 0; i<N; i++){
   dostuff()
}

eller

for i in range(0,10)
   dostuff

Førstnevnte krever at man forklarer sammenligningsoperatorer, heltallsdeklarasjoner og inkrementeringsoperatorer. Sistnevnte krever engelskforståelse.

 

Python er helt riktig språk å ha som førsteårskurs. Det er ryddig, interaktivt og har svært mange datastrukturer og funksjoner innebygd i standardimplementasjonen. Det eneste ankepunktet mitt er at det er litt for vanskelig å ha god kontroll på typer for en nybegynner.

 

Jeg har hatt jobber hvor jeg skrev lavnivå C-kode og har mye erfaring med relativt tung programmering, men jeg synes allikevel Python er et godt valg fordi det ikke lener seg på avgjørelser fra 70-tallet i like stor grad som C-derivatene du nevner. Og dette kommer fra en som har K&R på nattbordet.

 

Hvis vi underviser i Java til alle elever vil det ikke minst være meningsløst, siden svært mange ingeniørstudenter vil drive med vitenskaplige anvendelser, og ikke skal bli Accenture-droner.

  • Liker 6
Lenke til kommentar

Dynamisk typing gjør det også veldig vanskelig å lage en fornuftig IDE som typisk hjelper til med å holde styr på større prosjekter.

 

Virkelig? Det ville jo gjort det enklere siden en IDE kan kjøre en python-interpreter i bakgrunnen og hente ut masse metainformasjon. En IDE for et statisk språk er nødt til å parse, tyde, og i visse tilfeller kompilere kildekoden. Når har du forresten behov for å lage din egen IDE?

Jeg vet ikke om du har prøvd å sammenlikne typingske python IDE'er (som wing, pycharm) med Visual Studio med resharper, eclipse, intelij sov, men om disse IDEene gjør det du foreslår (som jeg tviler på), klarer de fortsatt ikke deterministisk å fortelle meg typene til inputvariabler, gi meg metodedefinisjoner og å fortelle meg at et gitt uttrykk ikke gir mening utifra typen. Dette har nok noe med at selv om man kan ha en interpreter gående, så må denne ha relevante input-data for å gi mening. Statisk typede språk kan derimot bruke typedefinisjonene til å logisk sjekke om metodene gir mening (selvsagt ikke fult ut, men mye lengre enn en python IDE kan).

 

Jeg har aldri snakket om å lage en egen IDE, bare om at det ikke er mulig å lage en python IDE som er like god som eksisterende IDEer for språk som java og c#.

Problem nummer to er manglen på krøllparanteser for scope. Dette går vanligvis greit for en enkelt person, men så fort man sitter å jobber flere samtidig med forskjellige editorer kombinert med litt copy and paste ender man fort opp med indenteringsproblemer.

 

Muligens om man bruker Notepad.

PROTIP: Bli enig om hvor mange space dere skal bruke for å identere, og ikke miks tab og space.

Dette er ikke bare et problem med notepad, men også et problem mellom forskjellige python IDEer uavhengig av antallet space satt opp fordi de behandler copy og paste anderledes (eller noe slikt). Uansett trenger trenger man med en slik syntaks å bli enig om diverse ting (space vs tab, antallet spaces, osv), en kompleksitet man ikke trenger å forholde seg til språk med krøllparantes.

 

I et språk med krøllparanteser kan en IDE holde styr på riktig indentering, mens man i python blir nødt til å lese igjennom koden for å se hva som skal være hvor.

 

Hvorfor er dette vanskeligere for et språk som bruker whitespace som identering? Det ser ikke ut som du kan noen ting om parsing, og da synes jeg ikke at du skal uttale deg om det.

Du skjønner ikke hvorfor parseren får problemer dersom indenteringen blir borte, også beskylder du meg for å ikke kunne noe om parsing? Dette blir derimot aldri tvetydig med krøllparanteser fordi starten på f.eks. en metode definisjon blir ulik slutten og en parser kan dermed uten tvetydighet parse i vei.

 

Problem 4 språket er i dag fragmentert mellom versjon 2 og 3 som gir mange morsomme feil om man ikke følger med.

 

Hvis du definerer "å følge med" som å vite hvor man er, eller hvilket språk man programmerer i.

Jeg mener at det er lett å få relativt lugubre feilmeldinger ved bruk uvettig bruk av biblioteker fra den andre standarden. Problemet er at det ikke nødvendigvis er tydelig hva som er feilen utifra exceptionen som blir kastet.

 

Jeg vil heller anbefale språk som C++, Java, Scala eller C#. Kanskje C++ siden den har minst syntaks fiksfakseri man trenger å lære for å skrive simple ikke objektbaserte programmer

 

C++ har minimal syntaks? luls. Python har nesten ingen syntaks hvis man bare holder seg til å kun skrive imperative programmer.

Det jeg mente å si her er at man kan kompilere og kjøre c++ kode uten å f.eks. ha en klasse definisjon rundt, slik man må i java. Problemet med dette er at det legger til ekstra elementer som må forklares( eller bare godtas) før man begynner. Syntaks rundt diverse statements har jeg ikke noe problem med (en god IDE legger til slik syntaks automatisk).

 

samtidig som det er relativt intuitivt å relatere det til hvordan en datamaskin fungerer (da jeg var studass i java virket det for meg som folk forstod konspeptene mye bedre hvis man gjorde et forsøk på å fjerne "magien" som ligger mellom programmeringsspråket og datamaskinen).

 

Var du studass i Java? Please tell me more about your expertise in teaching. Per ditt argument så burde jo assemblyspråk være enklere å programmere i siden det er nærmere hardware.

Tror ikke det er nødvendig å være nedlatende. Du må huske på at jeg ikke er spesielt smart, så du kan la det være implisitt.

 

Men poenget ditt.. Problemet med assembly er at det ikke er direkte nyttig som et programmeringssårk, og det inneholder ingen av syntakskonvensjonene til språk som er direkte nyttig. Det inneholder også ingen "normale" programmeringskonsepter som også er en svært naturlig del av et introduksjonskurs. C++ har alle disse. Python dekker også halvveis dette behovet, men litt av poenget var jo å argumentere for noe annet ...

Lenke til kommentar
[..] en kompleksitet man ikke trenger å forholde seg til språk med krøllparantes.

 

Unnskyld meg, men selvom et språk tillater forskjellige typer indentasjon, så er da dette vitterlig noe man burde bli enige om i forkant av et prosjekt. Jeg hadde ikke akkurat vært full av begeistring hadde jeg blitt overrakt kode som bestod av en salig blanding, til tross for at det kompilerte.

Lenke til kommentar

Problem nummer to er manglen på krøllparanteser for scope. Dette går vanligvis greit for en enkelt person, men så fort man sitter å jobber flere samtidig med forskjellige editorer kombinert med litt copy and paste ender man fort opp med indenteringsproblemer. I et språk med krøllparanteser kan en IDE holde styr på riktig indentering, mens man i python blir nødt til å lese igjennom koden for å se hva som skal være hvor.

Dette er spesifisert gjennom PEP 8, hvor standarden er fire spaces per tabulering. Hvis prosjektet ditt ikke klarer å standardisere dette, så vil du få like mye trøbbel med identeringsfeil i andre språk (K&R-stil? Allman? osv.)

Dette er riktig. Poenget mitt er at det er mye lettere å forholde seg til { og } enn det er til standarder særlig siden svært få leser bruksanvisningen (men ja, dette er et brukerproblem).

 

Problem 3 er at man ikke har noen kompilator som finner små fillefeil. Man er faktisk nødt til å kjøre programmet og treffe den spesifikke kodestien som trigg feilen.

Det er ikke sånn man skal bruke en kompilator. Til dette bruker man typisk enhetstester, eller et IDE med LINTing.

[/qoute]

Vel.. jeg synes det er mye lettere å la kompilatoren finne mine syntaksfeil enn det er å lese koden til jeg finner dem selv.

 

I den virkelig verden vil man selvsagt ha en IDE (som du sier) som kjører parsing i bakgrunnen for å finne syntaks og diverse semantiske feil som kan utledes fra koden. Poenget mitt er at slik analyse er mye lettere (og derfor i praktisk bruk) for statisk typede språk.

 

Jeg snakker forresten om nivået før man begynner å skrive enhetstester. Må også ta høyde for at jeg ikke er smart nok til å skrive feilfrikode, men at det selvsagt kan være mange som er flike til nettopp det:)

[qoute]

Problem 4 språket er i dag fragmentert mellom versjon 2 og 3 som gir mange morsomme feil om man ikke følger med.

Ja, akkurat som hvis du kompilerer C++ med forskjellige ekstrabiblioteker, som du trenger mange av siden språket inkluderer såpass lite grunnfunksjonalitet. Skillet mellom 2 og 3 er ikke spesielt stort og det er uansett sånn at de aller fleste prosjekter bruker 2.x hvor ting er veldig stabilt.

[/qoute]

Jeg mente å sammenlikne mer med java og C# her, som ikke har behov for å mange 3. parts biblioteker(særlig sistnevnte). Men det spesifikke problemet med python er at det er syntaktiske forkskjeller i elementere ting som print, som gjør at alt garrantert er inkompatibelt.

[qoute]

Jeg vil heller anbefale språk som C++, Java, Scala eller C#. Kanskje C++ siden den har minst syntaks fiksfakseri man trenger å lære for å skrive simple ikke objektbaserte programmer samtidig som det er relativt intuitivt å relatere det til hvordan en datamaskin fungerer (da jeg var studass i java virket det for meg som folk forstod konspeptene mye bedre hvis man gjorde et forsøk på å fjerne "magien" som ligger mellom programmeringsspråket og datamaskinen).

namespace::lol<type>(Blabla())

 

Jeg anser meg selv som en stor fan av C++. Å anbefale det fremfor Python fordi det har lite fiksfakseri er det rene vannvidd. Jeg har vært studass i flere år. Hva tror du er lettest å forklare for en som aldri har sett en forløkke før?

for(int i = 0; i<N; i++){
dostuff()
}

eller

for i in range(0,10)
dostuff

Førstnevnte krever at man forklarer sammenligningsoperatorer, heltallsdeklarasjoner og inkrementeringsoperatorer. Sistnevnte krever engelskforståelse.

 

Python er helt riktig språk å ha som førsteårskurs. Det er ryddig, interaktivt og har svært mange datastrukturer og funksjoner innebygd i standardimplementasjonen. Det eneste ankepunktet mitt er at det er litt for vanskelig å ha god kontroll på typer for en nybegynner.

 

Jeg har hatt jobber hvor jeg skrev lavnivå C-kode og har mye erfaring med relativt tung programmering, men jeg synes allikevel Python er et godt valg fordi det ikke lener seg på avgjørelser fra 70-tallet i like stor grad som C-derivatene du nevner. Og dette kommer fra en som har K&R på nattbordet.

 

Hvis vi underviser i Java til alle elever vil det ikke minst være meningsløst, siden svært mange ingeniørstudenter vil drive med vitenskaplige anvendelser, og ikke skal bli Accenture-droner.

Det var ikke meningen å sammenlikne syntaksen mellom C++ og python, men mellom språkene jeg foreslo. Det jeg spesifikt ville unngå var nødvendigheten av en klassedefinisjon. Angående eksemplet ditt har man foreach varianter av for-løkker både i java (der den forvirrende nok heter for) og i C#. Men jeg tror heller ikke man går i gang med for løkker før man forstår operatorene den er bygd opp av.

 

Uansett var det viktigste punktet for meg det første jeg listet opp, som du ikke svarte på. Problemet med python er at det ikke er veldig nyttig som språk i arbeidslivet. Og ja. De aller fleste som går ut av data vil jobbe i en konsulentselskap (desverre:))

 

[..] en kompleksitet man ikke trenger å forholde seg til språk med krøllparantes.

 

Unnskyld meg, men selvom et språk tillater forskjellige typer indentasjon, så er da dette vitterlig noe man burde bli enige om i forkant av et prosjekt. Jeg hadde ikke akkurat vært full av begeistring hadde jeg blitt overrakt kode som bestod av en salig blanding, til tross for at det kompilerte.

 

Tingen er at i språk med eksplisitt markering av start og slutt, så kan du velge å ikke bry deg:) Må igjen presisere at det er det første poenget jeg kom med som er spesielt viktig for meg.

Lenke til kommentar
Uansett var det viktigste punktet for meg det første jeg listet opp, som du ikke svarte på. Problemet med python er at det ikke er veldig nyttig som språk i arbeidslivet. Og ja. De aller fleste som går ut av data vil jobbe i en konsulentselskap (desverre:))

 

For det første er de fleste som tar TDT4110 (Python-versjonen av ITKG) ikke studenter fra Datateknikk.

 

For det andre er ikke poenget med en 5-årig utdannelse på NTNU å gjøre studentene til flinke Java-arbeidsmaur som kan gjøre jobben sin i Accenture tilfredsstillende, men å gi dem en ordentlig dataingeniør-utdannelse. Hvis man bare vil lære Java og bli ferdig med det kan man like godt gå på NITH eller en annen tulleskole.

Endret av operg
  • Liker 2
Lenke til kommentar
Uansett var det viktigste punktet for meg det første jeg listet opp, som du ikke svarte på. Problemet med python er at det ikke er veldig nyttig som språk i arbeidslivet. Og ja. De aller fleste som går ut av data vil jobbe i en konsulentselskap (desverre:))

 

For det andre er ikke poenget med en 5-årig utdannelse på NTNU å gjøre studentene til flinke Java-arbeidsmaur som kan gjøre jobben sin i Accenture tilfredsstillende, men å gi dem en ordentlig dataingeniør-utdannelse. Hvis man bare vil lære Java og bli ferdig med det kan man like godt gå på NITH eller en annen tulleskole.

 

Poeng og poeng fru Blom. Arbeidsmarkedet er drevet etter "etterspørsel og behov"-prinsippet. P.t. er det stort behov for Java-troll, og da er det temmelig tåpelig at akademikere skal sitte og rekke pekefinger angående meningen med ingeniørstudiet og slikt vås. Hvis ikke meningen med et studium er å forberede studentene på arbeidsmarkedet, hva skal det da være?

  • Liker 2
Lenke til kommentar

Arbeidsmarkedet er mer enn bare det som skjer "P. t". Forskjellen på en universitetsutdannelse i datateknikk/informatikk og en fagutdannelse i det samme faget bør være åpenbar. Om man ønsker å være java-arbeidsmaur så er det nok av muligheter til å lære seg det andre steder enn på Gløshaugen.

Lenke til kommentar

Vel. Nå har det seg slik at det er betydelig mye vanskeligere å få seg jobb som "Java arbeidsmaur" med kun "fagutdannelse", hva du legger i det vet jeg ikke, men jeg antar bachelor eller kanskje master fra en høyskole, så at det er nok av muligheter er jeg bare delvis enig i. Muligheter ja. Nok av de, kanskje. Ikke så mange som hvis man har en NTNU-utdannelse ihvertfall.

 

Arbeidsmarkedet er selvsagt mer enn det som skjer P.T, det har du rett i. Dog mener jeg det er viktig å ha en, i mangel av et bedre ord, ydmyk holdning til hva man faktisk kan etter universitetet. Det er, etter min mening, ikke stort, ihvertfall ikke mye man kan ta direkte ut i arbeidsmarkedet, Nå blir dette veldig generalisert og sikkert ikke like relevant for mange, men det får heller bare være. Poenget mitt er ihvertfall at grunnen til at mange havner i en Java/.Net/xxx-avdeling i starten, er at det er et behov for å lære seg teknologi/programmering/utvikling ordentlig fra bunnen av, før man ved senere anledning får mer ansvar og andre arbeidsoppgaver, eller at man tar seg jobb i en eller annen linje-bedrift.

 

Dessuten, mye negativt snakk om det å være "java arbeidsmaur". Hvis man ser litt stort på det er man tross alt med på å utvikle morgendagens produkter og tjenester, tatt i bruk i både det offentlige og det private næringsliv. Verdiskapning kalles det, og er ikke det poenget med arbeidslivet?

  • Liker 2
Lenke til kommentar

Dessuten, mye negativt snakk om det å være "java arbeidsmaur". Hvis man ser litt stort på det er man tross alt med på å utvikle morgendagens produkter og tjenester, tatt i bruk i både det offentlige og det private næringsliv. Verdiskapning kalles det, og er ikke det poenget med arbeidslivet?

Litt av problemet er vel at en del av java-konsulentene parasitter på statens jur som leverer alt for dårlige tjenester som går ned år etter år og det aksepteres fordi innkjøperne i staten ikke gjør jobben skikkelig. Hvis man vil sikre seg godt betalt jobb for alltid kan man like gjerne lære seg COBOL. Hvorfor underviser ikke NTNU i COBOL da, montro?

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å
×
×
  • Opprett ny...