Objekt orientering suger

Om man använder ett bra bibliotek med bra design så är det ganska smidigt att byta ut komponenter där det behövs (om det ens behövs, bra bibliotek brukar ha tillräckligt generella lösningar). Särskilt i anktypade språk där det räcker med att du kan skicka samma meddelanden till klassen och instanserna för att du ska kunna byta ut två klasser genom att bara ändra vilken klass du instansierar.

Ännu roligare blir det i språk som är sent bundna så du enkelt kan lägga på nya metoder i klasser även om du inte har källkoden till dem.

Dessutom, varför utgå ifrån att kunden kommer ändra sig? Frågar du mig bör man ta ungefär samma approach till det som man skall göra till prestanda. Om kunden ändrar sig så får man göra de ändringar som behövs för att uppfylla kraven, men det är ju inget man kan göra i förhand, så det är ju dumt att lägga ner massor av tid på något som inte nödvändigtvis blir ett problem. Samma sak gäller ju prestanda, koda först, profilera sedan och optimera efteråt.

Nej, du pratar om beroenden. Det är dåligt att ha korsberoenden. Men förmågan av objekt att interagera mot varandra på ett sådant sätt är inte spaggetti.

ints måste kunna konverteras till strängar som måste kunna konverteras till ints som måste kunna serialiseras till något som måste gå att deserialisera

Korsinteragering, inte spaggetti.

Att påstå att det är bättre att koda nytt än att återanvända välfungerande bibliotek är ju bara struntprat. Varför återuppfinna hjulet är ett motto som är grundläggande när man diskuterar god programmeringsvana och best practices.

Så gjorde jag men när jag kodade OO, men det är väl egentligen inte alls meningen utan man ska hålla på med MVC och skit?

men då gör man så här

   *
 / | \
*  *  *

Du skapar ett objekt som används som en "växel" och styr trafiken mellan de andra objekten.

   *
 / | \
*  *  *

Jag vet mycket väl hur man gör, och det där är inte rätt.

Men det är inte relevant för diskussionen i vilket fall som helst. Poängen är att c++ kräver att jag går igenom fruktansvärt många steg och tar hänsyn till ordning på saker som inte ger något till strukturen. Och det är en onödvändig, komplikerande del av språket.

Är det onödigt även ur kompilator-kodarens synpunkt? Det är en uppriktigt fråga från min sida. Jag menar, det finns väl en del exempel på saker där programmeringsspråk har fått offrat användarvänlighet till fördel för kompilator?

Fast jag kan hålla med om att include guards, m.m. är smärta som verkar ganska onödig.

Har någon redan implementerat en standard ser jag inte vad du ska kunna tillföra? Varför göra sig en PNG-decoder själv, kan inte finnas några rimliga anledningar om inte projektledaren har fått order att verkligen bränna pengar.

Det verkar som du utgår från att jag menar att man ska använda ad hoc-komponenenter men det är inte riktigt syftet med återanvändning av kod (det kan dock fungera väl som inspiration till ett svårlöst problem). Utan att som i exemplet ovan ta in implementeringar av en standard, rfc, template, eller någon annan logiskt bundlad lösning. Bra programmering för mig är att också själv se var/hur man kan "abstrahera" sin lösning för att spara resurser i framtiden (om det argumentet inte biter på dig måste du väl ändå hålla med om att skriva om i princip samma lösning flera gånger är väldigt tråkigt).

Om de redan existerande implementationerna inte möter kraven för minnesanvändning/prestanda/funktionalitet.

Det är för mig självklart att använda redan existerande bibliotek så långt det går, så kan man lägga fokus på den faktiska applikationen och inte riskera att introducera buggar för att man har för mycket att ha hand om. Men de ska inte vara så hårt bundna till applikationen att man inte kan byta ut dem.
Wrappers är i allmänhet trevligt att använda och inte mycket jobb att skriva, man kan dock byta ut det bakomliggande biblioteket utan att ändra någonting i huvudkoden.
Att abstrahera allt för mycket är inte alltför bra heller, prestandan kan få lida och kodöversikten blir svårare och svårare för varje lager man lägger till, det gäller att hitta en bra balans.

Sitter för närvarande och skriver på ett system som ska köras på några switchar, dessa switchar använder sig av Broadcom-chips. Enligt din (gosh) åsikt bör vi alltså totalt ignorera Broadcoms API och implementera ett eget?
Nu är det lite annorlunda mot att använda ett redan existerande PNG-bibliotek eller liknande, men det är någonting som det verkligen inte finns tid till.

Briljant liknelse..

Om ett programs primära uppgift är och hantera grafik så tror jag nog ändå att de bygger sina egen hantering för grafiken. Är det däremot en extra finess, kanske en bild som skall visas när applikationen startar så är det självklart ett helt annat tillvägagångssätt. Det är då inte speciellt viktigt för applikationens huvudsyfte.

Jasså, det gör de?

Samtliga de där använder Core Image, alla utom Pixelmator använder NSImage för att läsa och skriva filer, Pixelmator använder ImageMagick.

Briljant liknelse

Inte speciellt underligt att Apple använder sitt eget bildhanteringsbibliotek, tycker du inte?
Faktum är att de faktiskt har skrivit något eget och inte använt någon annans prylar (applicerar inte så väl i diskussionen dock, då det skrevs för deras eget operativsystem ).

Ta dock Adobe exempelvis, skulle tro att all deras bildhanteringskod är skriven "in-house".

Två av de där programmen är inte från Apple. Vidare tycker jag inte att det spelar någon roll att de är skrivna in-house hos Apple, de är fortfarande mångsidiga nog att användas av massvis av olika slags program, vilket är själva poängen.

I ett bra bibliotek så är klasserna mångsidiga. Ta NSMutableArray som exempel. Man skulle kunna tro att NSMutableArray är en vanlig array som går att ändra på, med konstant tid för lookup och så vidare. Så är dock inte fallet, NSMutableArray anpassar sig efter hur många element som finns i arrayen. Från början beter den sig som en vanlig array, men om man trycker in många element i den så får den helt andra egenskaper. På så vis så är den väldigt ofta lämplig att använda, framförallt är den lämplig nog i tillräckligt många fall för att man ska kunna implementera först och profilera koden efteråt.

Mer läsning om NSArray här:
http://ridiculousfish.com/blog/?p=27

Jo, jag vet det. Men de andra två är ju inte direkt "hot shot"-prylar heller. Okej, de kostar pengar men långt ifrån vad exempelvis Photoshop kostar.
Vilket i och för sig kanske inte är aktuellt i frågan... Äh, det får vara.

Och vem har sagt annat? Det är inte mig du ska övertyga (kanske du inte försökte heller).

Den där argumentationen är typisk för en programmerare som i princip endast letar kod och bara "binder ihop" vad man hittar.
Har du skrivit en länkad lista, array eller hash table själv så kan du mycket snabbt räkna ut vad du skall välja vid olika typer av lösningar. De har olika fördelar och nackdelar beroende på hur de skall användas.

Är rätt sällan en duktig programmerare sitter och profilerar kod när det gäller den kod man har kontroll över eftersom man vet direkt när man ser kod vad som tar tid. Och det är även ett måste, det får inte uppstå buggar som att när man själv sitter och testar med en mindre mängd data så går det fort, så åker applikationen ut till någon kund som för in massor av data och plötsligt tar allt väldigt lång tid...

Så i din definition av en duktig programmerare så ingår det att man gissar istället för att profilera och att man inte testar sin kod ordentligt? Låter ju som en väldigt duktig programmerare vi pratar om.

Det är någon stans här som jag drar in det obligatoriska Knuth-citatet: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."

Nej du, riktigt duktiga programmerare kodar först och profilerar efteråt.

Att det finns buggar i andras kod är en risk naturligtvis, men det är ju därför man väljer libraries med omsorg, dessutom, det är antagligen större risk att det finns buggar i mina egna klasser än de som har använts av tusentals programmerare under ungefär 15 års tid. I de extremfallen där det finns en bugg, så går det ju dessutom nästan alltid att jobba runt den, eller att helt enkelt skriva om den metoden som felar själv.

Och just ja, naturligtvis har jag skrivit olika datastrukturer själv, det är ju bland det första man gör i algoritmkurser. Det betyder inte att jag vill återuppfinna hjulet hela tiden.

Gissar?

Att exempelvis veta fördelar och nackdelar med olika typer av listimplementationer är ju baskunskaper.

Nästan alla program idag jobbar med databaser av något slag, vanligen är det där man måste vara duktig för att få upp snabbhet då programmets hantering är försumbar i jämförelse.

Varför bry sig om olika typer av listimplementationer förutom där det spelar någon roll?

Om jag ska ha en array för att lagra lite användarinställningar går det bra mycket snabbare att skriva [[NSMutableArray alloc] init] än att skriva en egen klass för en mutable array, och det kommer antagligen att fungera utmärkt eftersom en klass som lagrar användarinställningar bara används någon gång då och då.

En bra programmerare gissar inte var flaskhalsen finns, utan mäter det. Vad spelar det för roll ifall hämtning från en databas tar 300 ms när det ändå bara görs var femte sekund? Man optimerar där det behövs, och man profilerar för att ta reda på var det behövs.

Vart kommer din elitistiska självbild ifrån?

Du tror att du kan skriva en specifik implementation snabbare, buggfriare och bättre strukturerat än en biblioteksimplementation som en större grupp utav programmerare arbetat i flera år med och som testats utav flera tusen användare?

Nåväl, inte omöjligt, du kan ju vara en superprogrammerare, men du tror även det är en bra idé. Vilket gör dig till en mycket dålig programmerare.

Att utnämna sig själv till c++ expert är inte svårt, men titeln är inte mer värd än den som ger den.

- Hårt arbete
- Många års erfarenhet
- Ständigt ifrågasättande om det inte finns bättre lösningar på det man gjort
- Intresse

En duktig programmerare tycker om att lösa problem, gärna bättre än andra. Man ser en utmaning i att göra något bättre än vad någon annan gjort.

Sitta och pussla ihop lösningar av annans kod gör ingen till en bra programmerare.

Självklart kan det finnas orsaker till att man måste leta upp färdiga lösningar, sitta och koda en helt egen databas om man skall ha databashantering tror jag ingen skulle drömma om

Du anar inte vad mycket skitkod det finns. Det krävs stor kunskap i att utvärdera program och om det faktiskt är värt och plocka in det istället för att göra eget.

Oj, det blev ett oväntat resultat av det där.

Jadå, men en duktig programmerare fokuserar sin problemlösning på de större problemen. Man vill inte i onödan bry sig om implementationsdetaljer för exempelvis olika datastrukturer.

En duktig programmerare återanvänder det som går att återanvända, och får ut sin produkt till kunden i tid. Det är klart att man kan sitta & uppfinna hjulet på sin egen fritid men om man jobbar på ett större projekt med en dead-line så funkar inte den attityden. Detta tror jag är sant för 90% av all mjukvaruutveckling, men rätta mig gärna om jag har fel.

Det är ont om duktiga programmerare. Sitter man mest och letar kod så blir man inte duktig programmerare, även om man uppfinner hjulet på nytt så finns det visst värde i att göra saker själv. När du lärde dig räkna så räknade du säkerligen tal som andra redan räknat ut en gång.

Möjligen är det få idag som faktiskt programmerar utan det mer blivit en blandning av design och programmering. Utvecklingsverktygen går ju mer och mer åt det hållet eller gick för jag ser tendenser till att man återgår till kodandet på vissa håll. Vanliga designverktyg går åt programmering.

Att skriva kod tar heller inte alls speciellt lång tid.

Men givetvis, är man osäker på kodandet eller producerar mycket buggar så är det säkerligen bättre och använda sig av annans kod.

Skriva kod kanske inte tar lång tid (beror ju på en del faktorer), men om jag ska skriva ett bibliotek för säg PNG-laddning och modifiering så måste jag först sätta mig in i specifikationen för PNG, vilket i sin tur tar sin lilla tid.

Bättre att fokusera på det som faktiskt är nödvändigt, så vidare man inte är i behov av ett eget PNG-bibliotek av någon anledning eller att ett sådant är högprioriterat på något sätt.

Okej, applikationen som jag kodar på här har en del egna implementationer av saker och ting, men detta beror på att de redan existerande biblioteken inte fungerar för oss. Prylarna ska rulla på ett antal switchkort med speciell hårdvara.
Men två stycken komponenter (kö- och trådhantering samt loggning) som är en stor del av applikationen är "färdiga" produkter som köpts in för detta, andra saker som körs på switcharna förutom våran applikation (såsom syslog) körs i princip orört (lite småmodifikationer gjorda).
Switcharna i sig kör en strippad variant av Linux.

Jag tycker inte att en god programmerare implementerar allt själv. En god programmerare gör det som behövs för att få ut en fullt fungerande produkt till kund i tid.
På hobbynivå har jag ingenting emot att uppfinna hjulet igen för att lära mig nya saker, dock.

Alltså jag tycker att båda har rätt ang. att använda färdiga bibliotek vs. skriva eget. I studiesyfte är det så klart bra att prova på att skriva så mycket olika saker som möjligt, men när det handlar om att möta deadlines är det kanske oftast inte något bra beslut att skriva eget. Ska även nämna att min enda erfarenhet kommer från laborationer och projekt i skolan, men i dessa har jag oftast enbart fokuserat på det som uppgiften handlat om, när jag inte har gjort det så har jag oftast haft problem med att bli klar i tid. I mina egna hobbyprojekt sätter jag mig gärna och försöker implementera en konverterare från 24bitars bitmappar till 16bitars eller liknande istället för att använda färdiga grejer, har lärt mig mycket på såna saker.

Angående prestandaoptimering håller jag med gosh till viss del. Alltså det är fel att säga att man kodar först och sen optimerar där det behövs. Om prestanda är ett viktigt kvalitetsattribut för systemet/programmet så måste man planera för det redan från början, och då ingår det att försöka förutsäga vilka delar som kommer att vara kritiska, särskilt om man utvecklar ett realtidssystem. För märker man att prestandan är dålig i efterhand så kan det innebära att man måste ändra på väldigt mycket. Det som har störst inverkan på prestanda är ju val av arkitektur/upplägg och datastrukturer samt algoritmer. Såna saker är aningen tidsödande att ändra i efterhand, håller ni inte med? Men om programmet/systemet inte klarar av att möta kraven i slutändan så måste man så klart undersöka var flaskhalsen/arna ligger och se vad man kan göra åt det.

Ett exempel på hur illa det kan gå om man inte har förståelse innan hur lång tid saker tar.
En vän till mig satt som konsult hos ett företag som bl.a. utvecklade programvara för att registrera telefonsamtal. Kraven på prestanda där var väldigt höga. På detta projekt hade man spenderat ett 9 siffrigt belopp, företaget hade en omsättning på drygt 3 miljarder (om jag minns rätt). Kompisen är duktig på att programmera och märkte snabbt att prestanda var alldeles för dålig.

De hade valt Java samt designade databasen i något grafiskt verktyg.

När kompisen påtalade att det aldrig skulle gå och få upp den prestanda som krävdes så fick han som svar "vad säger du? vi har spenderat XXX miljoner på projektet och det måste gå". Som konsult så kanske man inte känner att det är läge och säga ifrån utan man låter den som bestämmer köra huvudet i väggen så länge man får sina pengar, de var i slutskedet med. Ett år senare avvecklades företaget eller rättare sagt så införlivades företaget i moderbolaget, programvaran var basen i deras produkt men den fungerade tyvärr inte.

Detta är absolut inget unikt, det vimlar av projekt som kostat mycket mer än vad man från början tänkt och inte alls når upp till den funktionalitet man från början velat ha.

En kort fråga, vad har ett grafiskt databasverktyg med saken att göra? De flesta grafiska sådana gör inte mer än att formatera en query efter sina krav och köra den (brukar inte vara någon magi inblandad)?
Ganska svårt att göra göra en tabell seg, i så fall om man väljer fel fälttyper, onödiga fält och missar indexering på vissa fält.

Det där är dock inte ett exempel på optimering som så. Snarare att de valde fel verktyg för uppgiften.
Är väl självklart (hoppas jag) att man redan innan vet om någonting är tidskritiskt och tar ställning till utvecklingen efter det. Det vill säga man väljer rätt verktyg från början och kodar så optimerat som man kan. Därefter kan man profilera och optimera ännu mer om det behövs.

Precis samma problem som alla andra grafiska utvecklingsverktyg orsakar. Man behöver inte förstå vad som händer bakom kulisserna vilket innebär att man gör saker som man inte riktigt förstår konsekvenserna av.

Som? De grafiska databasverktyg jag pillat på har inte inbjudit till något sådant utan snarare har varit jävligt straight-forward angående vad som ska göras och vad som görs.

Inte som om man tycker "gör mig en databas till mitt vackra projekt" och den skapar databasen själv. De jag arbetat med har man fått gå igenom steg för steg, precis som när man skriver queries för hand, minus den sista biten.
Alltså, när man skapar ett nytt fält får man ställa in precis hur fältet ska se ut, ingen magi alls.

Nu råkar jag föredra att sitta och skriva queries själv, men det är en personlig preferens som kommer av att jag finner det onödigt att blanda in extra mjukvara för något så simpelt.