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

[operg]

 

 

Dette stemmer, og er en latterlig dårlig feature i python imo.

 

Mangelen på encapsulation i Python fungerer etter min mening flott og er potensielt veldig kraftig når man jobber på et prosjekt bestående av et lite antall, oppegående utviklere, men er mindre heldig hvis man jobber i et stort team med masse mer eller mindre oppegående utviklere som må "tvinges" av språket til å skrive fornuftig kode.

 

 

Og funksjonelt. Man kan også skrive (nogenlunde) prosedyrisk java, men det er verbost og tungvindt og ekkelt.

 

Jeg mener mangelen på skikkelig lambda i Python hindrer det fra å bli kalt funksjonelt.

[Lycantrophe]

Det der var heftige greier i forhold til det som har vært på de første tre øvingene i TDT4102, som fortsatt ligner mye på programmeringen i ITGK. Gjelder kritikken din begge variantene av faget i like stor grad, Lycantrophe?

Ikke i like stor grad i TDT4102, men fortsatt ganske ille.

 

Jeg mener mangelen på skikkelig lambda i Python hindrer det fra å bli kalt funksjonelt.

Python er brukket på det jevne. Mangelen på encapsulation gjør at det egentlig ikke er spesielt godt objektorientert heller.

[operg]

 

Heter det ikke at det er din egen feil dersom du aksesserer et objekts interne variabler direkte der det skulle vært ungått? Bare fordi en har muligheten trenger en jo ikke bruke den.

 

Jo, og det fungerer fint hvis du er kun én eller noen få utviklere som jobber på et prosjekt. Men når et prosjekt blir stort finner du etter hvert ut at du ikke har fullstendig oversikt over koden, du mister gjerne muligheten til å spørre personen som skrev koden om hvordan han mente at ting skal gjøres, og i en virkelig bedrift jobber du gjerne med tragisk dårlige utviklere som hvis de ikke blir tvunget til noe annet definitivt kommer til å tulle med objektets interne variabler.

[operg]

Python er brukket på det jevne. Mangelen på encapsulation gjør at det egentlig ikke er spesielt godt objektorientert heller.

 

Begge deler har med språkets filosofi å gjøre: det første kommer fra "We're all consenting adults here"-prinsippet, og det siste fra det faktum at Guido ikke er storfan av funksjonell programmering. Du kan mislike valgene som ble tatt, men "brukket" vil jeg ikke si at det er.

[Lycantrophe]

Zen of python er eneste filosofien jeg vet om som faktisk oppfordrer folk til å skrive dårligere kode.

 

Det kaller jeg brukket.

[operg]

Hva som er "dårligere kode" er svært subjektivt. Man kan lett argumentere for at all programmering uten statiske typer er "dårlig kode", og da faller Python og en hel haug med andre språk vekk med en gang. Fakta er at ved å velge å bruke et programmeringsspråk aksepterer du ulike trade-offs i språket, og spesifikt i Python gir du vekk sikkerhet (static typing, encapsulation) i bytte mot muligheten til å skrive svært dynamisk kode.

[Lycantrophe]

Det er ikke statisk typing jeg sikter til (selv om jeg langt på vei foretrekker sterk, statisk typing, men det er nå så). Det er alle fjollete tesene i Zen jeg sikter til.

[Gjest Bruker-182691]

Kan vi muligens få oppgaven?

https://www.ntnu.no/wiki/pages/viewpage.action?pageId=68359689

 

skulle lagt den ved med en gang..

[operg]

Det er ikke statisk typing jeg sikter til (selv om jeg langt på vei foretrekker sterk, statisk typing, men det er nå så). Det er alle fjollete tesene i Zen jeg sikter til.

 

Jeg vet ikke helt hva du sikter til. De fleste utsagnene i Zen of Python er veldig ukontroversielle. Hvordan er "Beautiful is better than ugly" og "Errors should never pass silently" fjollete?

 

Som en sidekommentar er sikkerheten i språk som Java og C# en stor del av grunnen til at de er så populære i enterprise-sammenheng. Ikke bare tillater de ikke den type dynamisk magi som er så populær i språk som Python og Ruby, men de tillater heller ikke triksingen på mikronivå som man gjerne må ty til i C eller C++, og har en stor mengde funksjonalitet som er til for å øke sikkerheten i koden. Det gjør det betydelig lettere å utvikle programvare i store team, med utviklere på ulike erfarings- og kompetansenivåer.

[Lycantrophe]

skulle lagt den ved med en gang..

Du har flere bugs her, men det vet du sikkert.

 

#1: Siden han spesifiserer at han vil ha String som underliggende så får du gjøre det.

#2: Du gjør noe feil når du skal sjekke om du er helt til høyre i right()-metoden din. For det første, siden Java ikke har operator overloading (som er HELT fjernt) vil ikke String != "" sjekke som du tror den gjør. Du må bruke String.equals("") eller "".equals(String). Videre sjekker dette om stringen din er tom, ikke hva som står på posisjonen.

 

Hint: Hva vet stringen om lovlige posisjoner?

 

#3: Du gjør riktig i å lage en ny streng, men ikke gå omveien om charArray. Tips: substring og +. :--)

#4: Denne løses på samme måte som #3.

[Lycantrophe]

Jeg vet ikke helt hva du sikter til. De fleste utsagnene i Zen of Python er veldig ukontroversielle. Hvordan er "Beautiful is better than ugly" og "Errors should never pass silently" fjollete?

Explicit is better than implicit.

Mhm, ingenting er bedre enn å få masse unødvendige implementasjonsdetaljer slengt i trynet. Gjør det også vanskeligere å forandre underliggende implementasjoner. Hva er abstraksjon.

 

Sparse is better than dense.

Hva er eleganse.

 

Som en sidekommentar er sikkerheten i språk som Java og C# en stor del av grunnen til at de er så populære i enterprise-sammenheng. Ikke bare tillater de ikke den type dynamisk magi som er så populær i språk som Python og Ruby, men de tillater heller ikke triksingen på mikronivå som man gjerne må ty til i C eller C++, og har en stor mengde funksjonalitet som er til for å øke sikkerheten i koden. Det gjør det betydelig lettere å utvikle programvare i store team, med utviklere på ulike erfarings- og kompetansenivåer.

Corporate backing og buzzwords for 10-15 år siden har nok også noe med saken å gjøre. Endret 11. januar 2014 av Lycantrophe

[endrebjo]

 

Ikke bare tillater de ikke den type dynamisk magi som er så populær i språk som Python og Ruby, men de tillater heller ikke triksingen på mikronivå som man gjerne må ty til i C eller C++, og har en stor mengde funksjonalitet som er til for å øke sikkerheten i koden.

Når C++ brukes sammen med et fornuftig og moderne rammeverk trengs vanligvis ikke denne triksingen på mikronivå. Qt er blant de bedre her, siden pakken er såpass omfattende.

Det er i prinsippet det som har blitt gjort med C# også. Altså at .NET-rammeverket er såpass omfattende at triksing ikke trengs. Uten .NET er vel ikke C# noe som helst?

Endret 11. januar 2014 av endrebjo

[Yokoya]

 

Jo, og det fungerer fint hvis du er kun én eller noen få utviklere som jobber på et prosjekt. Men når et prosjekt blir stort finner du etter hvert ut at du ikke har fullstendig oversikt over koden, du mister gjerne muligheten til å spørre personen som skrev koden om hvordan han mente at ting skal gjøres, og i en virkelig bedrift jobber du gjerne med tragisk dårlige utviklere som hvis de ikke blir tvunget til noe annet definitivt kommer til å tulle med objektets interne variabler.

 

I praksis kan du ha private attributter ved __x. Alle som går omveien og aksesserer når en utvikler har gjort dette kan skylde seg selv og i enterprise miljøer bli sparket dersom noe går galt.

 

Dessuten kan flittig bruk av docstrings som dokumenterer atferd fortelle andre nettopp hvordan grensesnittet skal brukes.

Endret 11. januar 2014 av Yokoya

[nicho_meg]

Amatører hele gjengen. Bruk assembly!

[operg]

 

 

Mhm, ingenting er bedre enn å få masse unødvendige implementasjonsdetaljer slengt i trynet. Gjør det også vanskeligere å forandre underliggende implementasjoner. Hva er abstraksjon.

 

Tvert imot, at ting er eksplisitt gjør det lettere å forstå hva som skjer. Hvis du mener at det forhindrer abstraksjon vet jeg ikke hvor mye Python du har skrevet, for det er like lett å abstrahere i Python som i andre språk. "Explicit is better than implicit" betyr f.eks. at ting som 5 == "5" (som i JavaScript) ikke skal være lov, ikke at man ikke skal abstrahere.

 

 

Hva er eleganse.

 

Er massive onelinere "eleganse"? Det er den slags "Sparse is better than dense" handler om.

 

 

 

Når C++ brukes sammen med et fornuftig og moderne rammeverk trengs vanligvis ikke denne triksingen på mikronivå. Qt er blant de bedre her, siden pakken er såpass omfattende.

Det er i prinsippet det som har blitt gjort med C# også. Altså at .NET-rammeverket er såpass omfattende at triksing ikke trengs. Uten .NET er vel ikke C# noe som helst?

Å ikke måtte være avhengig av rammeverk er etter min mening en stor fordel. Qt er én ting, men i C++ må du gjerne bruke Boost for å gjøre mye av det som man enkelt kan gjøre uten ekstra biblioteker i C#/Java, og Boost er som kjent en stor haug med dritt. Å ha ting fornuftig implementert i kjernen av språket er en fordel her.

Selv om det er litt rart å vurdere C# uten .NET (C# er ikke som C eller C++, som man gjerne bruker på platformer der standardbiblioteket ikke er til stede), er det ikke sant at all sikkerheten i C# kommer fra .NET-bibliotekene. Se f.eks. her.

[Lycantrophe]

Tvert imot, at ting er eksplisitt gjør det lettere å forstå hva som skjer.

Men dette gjør fort at vi også må prosessere for mye informasjon på en gang.

 

"Explicit is better than implicit" betyr f.eks. at ting som 5 == "5" (som i JavaScript) ikke skal være lov, ikke at man ikke skal abstrahere.

Takk og lov, forøvrig.

 

Denne explicitnessen, forøvrig, gjør også at ting som for-loops og manuell stack-håndtering foretrekkes (i ideomatisk python) fremfor, say, funksjoner. Det er ikke positivt.

 

Er massive onelinere "eleganse"? Det er den slags "Sparse is better than dense" handler om.

Nå er det fullt mulig å skrive "dense" i python-øyne uten å ha massive onelinere.

[endrebjo]

 

Å ikke måtte være avhengig av rammeverk er etter min mening en stor fordel. Qt er én ting, men i C++ må du gjerne bruke Boost for å gjøre mye av det som man enkelt kan gjøre uten ekstra biblioteker i C#/Java, og Boost er som kjent en stor haug med dritt. Å ha ting fornuftig implementert i kjernen av språket er en fordel her.

Både Boost og STL er strengt tatt rammeverk begge to (i hvert fall biblioteker) Som rammeverk er Boost, som du sier, en stor haug med dritt. Og STL er for simpelt. Derfor kan en like gjerne kjøre Qt og få et langt lettere C++-liv. Når Qt er såpass tilgjengelig på alle plattformer ser jeg ikke noe grunn for å ikke bruke det. Industrien digger det.

Å vurdere C++ uten å ta i betrakning gode rammeverk er i mine øyne litt tynt, akkurat som på C#.

[Elgstuing]

Samme her. Sammenlignet med LF fikk jeg nok 70-75 % riktig, likevel holdt det til A. Må være veldig normalfordelte skalaer. Men jeg klager jo ikke.

 

Ja, det må vel være noe sånn. Ser en mye større andel av folk med B og D enn normalt (henger vel sammen med den nye karakterskalaen til en viss grad), men mengden A er jo ikke noe større enn til vanlig. Synes i grunnen ikke at noen av oppgavene på eksamenen var noe vanskeligere enn til vanlig (foruten at uttrykket i den siste oppgaven ble grisete til en nesten vanvittig grad), men jeg hadde konstant dårlig tid og glemte å gjøre en hel oppgave (hadde tenkt å gjøre 1b til slutt, dersom jeg hadde tid) og gjorde flere relativt grove feil delvis pga hastarbeid, men allikevel holdt det til A. Må si at jeg synes det er ganske merkelig. Å se karakteren A på studweb ved siden av Statistikk ble mildt sagt overraskende.

Endret 11. januar 2014 av Elgstuing

[Crumpler]

Noen med erfaring fra SANT0002 (Psykologisk antropologi) her? Er det et greit emne, er det noen obligatoriske aktiviteter, og hvordan er det å lese på egenhånd?

 

EDIT: Er det mange øvinger og obligatoriske aktiviteter i tekled?

Endret 12. januar 2014 av Crumpler

[PhelpsTransposed]

^ Dette er tøyset er grunnen til TDT4100 ikke egentlig egner seg til å lære seg å programmere.

Dette. Fikk en E i faget når jeg hadde det - har likevel hatt både sommerjobber og deltidsjobber der jeg har programmert i etterkant, hvor i prinsippet mye vanskeligere programmering har vært veldig mye lettere.

 

Bil bilen = new Bil();

 

og lignende eksempler som bare gjør at dysleksien kicker inn eller noe - det går helt i surr for meg.

 

Hele faget er enormt dårlig lagt opp spør du meg, med bare tøyseeksempler som hverken egner seg til å gi forståelse eller vise praktisk bruk av faget/programmering. Husker jeg hadde enorme problemer med å skille klassenavn, objektnavn og variabelnavn fra hverandre nettopp på grunn av slike eksempel som det over.

Endret 12. januar 2014 av PhelpsTransposed