Skrivet av klk:
Separera systemdomän från användardomän är viktigt. (använder de namn som Casey Maratori beskrev så bra).
Det är viktigt, men detta är nog något som p.g.a. av ökad mognadsgrad ett allt mindre problem.
Moderna/popular språk som t.ex. Python har rätt mycket "batterier inkluderade" till den grad att systemdomänen i praktiken är "klar". Finns ingen anledning att fokusera på något annat än användardomänen i de flesta projekt.
Detta är bra och visar på ökad mognad i denna sektor.
Skrivet av klk:
Det finns en bok som heter "clean code" skriven av Robert C Martin. Sämsta bok som skrivits och förstört massor eftersom den beskriver att bra kod är att skriva kod för användardomän. Att kod är som att läsa en bok.
Att den blev så populär tror jag beror på att många kunde äntligen göra något programmeringsmässigt. Så de trodde "nu är jag programmerare". Försöker då en "riktig" programmerare förklara att man inte gör som de lärt sig så förstår de inte alls.
Clean Code har fått en hel del kritik, men nog mer för att den framställer saker som egentligen är "best practices" mer som lagar. Den har också fått kritik för att fokusera allt för mycket på detaljer och lite får det att låta som "fixar man detaljerna är man hemma". Även perfekta delar kan bli en dålig helhet om ingen tänkt på hur man ska sätta ihop det hela...
Personligen gillar jag inte trenden, som Clean Code trycker hårt på, att inte använda sig av kommentarer. Kommentarer kan vara otroligt värdefulla när de berättar varför något är gjort på ett visst sätt, hur något är gjort står ju i koden!
Men den trycker också på en lång rad saker som känns som självklara saker. Som att varje funktion ska ha exakt en uppgift, ge saker namn som förklara avsikten.
En av mina käpphästar, som jag nog pushar lika hårt som du pushar HN, är att så långt som möjligt skriva saker så konsekvent som möjligt. Vilken kodstandard och hur många white-space man råkar ha vid indentering kvittar, men alla ska använda samma så långt som realistiskt möjligt!!
Go nailar det sista på ett för mig fullt acceptabelt sätt: standard-tooling inkluderar en language-server (som definitivt kan hantera väldigt stora projekt) där de flesta av dessa val redan är gjorda. Det håller inte bara en fin nivå inom projekten, det gör att även andra projekt har en mycket snarlik outline.
Har jobbat på ett ställe som hade väldigt bra ordning på sin kodbas, men där det ändå blev rätt drygt p.g.a. att den kodstandard man körde inom företaget var så ovanligt att all 3:e-partskod alltid såg "off" out. När IDE/textredigerar blev allt bättre att formatera automatiskt blev det ännu värre då typ ingen hade stöd för den variant som användes internt...
Det är också ett stor "därför suger HN", "ingen annan" använder det idag!
Skrivet av klk:
Hur jag vet att exempelvis rust eller andra "förlåtande" språk inte kommer användas till större svårare projekt
Vet man om ovanstående så är det ganska lätt och se hur långt ett projekt kommer. Det beror en del på vilken typ av domän koden hanterar. Är det domäner kända för utvecklare kommer de längre, är det ovanliga så kommer de inte speciellt långt.
Att utveckla en editor, spelmotor eller annat kan komma ganska långt även om det är tekniskt men det beror på att användardomänen också är känd för utvecklare.
Är det annat som vetenskapliga domäner eller liknande, då bli det genast mer problem.
Eftersom jag granskat en del rust projekt så, i princip samtliga rust projekt jag kollat uppträder för mycket "skitkod" och det är enligt mig orsaken till att de inte kommer så långt. Ett allvarligt designfel de har i rust är att språket saknar överlagring och det gör att att de har mycket svårare att skriva kod i mönster. Nästan alla "kända" rust projekt har en eldsjäl och de kan nå närmare 100 000 rader och då är det vad jag sett nästan alltid domäner välkända för utvecklare. Har inte sett rustprojekt med något mer udda domän som är större men tar gärna emot tips på sådant. Att det saknas projekt i domäner okända för utvecklare tror inte jag är en slump.
Ovan är direkt svammel. Rust används redan inom områden där en typisk programmerare knappast har någon djupare domänkunskap. Exempel är industri-tillämpningar, automotive, robotics, B2C och B2B.
Sen behöver du inte kolla längre än till Rust-kompilatorn + standardbibliotek för att hitta något som redan nått sjusiffrigt antal kodrader. Finns rätt många Rust-baserade open-source projekt som är en handfull hundratusentals rader.
Antar att du även räknar in Java, C# och Go i "förlåtande språk". Där finns det massor med väldigt stora projekt idag.
Skrivet av klk:
Vet du någon annan kodstil för att hantera kod
För ändringen är "skriv kod som du själv vill". Vad jag vet är det endast hungarian notation som finns och vars syfte är att hantera svår kod. Det kan vara mycket kod, avancerad kod, svår domän eller liknande. Hjärnan behöver inte arbeta lika mycket och kan därför lägga energi på annat.
Se ovan, ändringen är absolut INTE "skriv kod som du vill". Tycker personligen det är en kritisk del att så långt som realistiskt möjligt hålla en konsekvent stil i kodbasen.
Däremot ser jag ingen poäng med HN. Det har en poäng i svagt typade språk som t.ex. C och ännu mer i svagt typade språk som också är dynamiskt typade som många script-språk som t.ex. TCL, Perl, etc. Det har ingen poäng i statiskt och starkt typade språk som C++, Rust, Go, C#, m.fl. (det är extra meningslöst i språk med generics vilket i.o.f.s är alla nämnda).
Som @Ingetledigtnamn nämner ovan var du väldigt emot smarta pekare och likande. Vad tycker du då om det som sägs i videon du länkar ovan där jättar som Microsoft och Apple säger att de redan hittat tusentals buggar när de slog på "standard library hardening" som bl.a. lägger in bounds-check för operator[].
Har tror jag man fick en smärtsam "vi har inte längre CPUer designade på 70/80-talet där man kan cykelräkna", CPU-design har på flera sätt rejält sprungit ifrån det som historiskt gjorde C och C++ unikt men som idag ibland är rena sänken (att inte ha GC kan rätt bli ett sänke om man ger sig in i multi-thread programmering).
Att slå på de extra check:arna i "standard library hardening" verkar ju på moderna CPU-designer fått en prestanda-dipp på <1%. Ingen bryr sig om <1% givet hur mycket mer minnessäkert det ändring gör språken!!!
Samtidigt kan man också fatta varför det var en dålig idé innan vi fick de breda out-of-order CPUerna vi har idag. Det är rätt mycket instruktioner som läggs till om man gör något som detta
int foo(const vector<int> &v, int i)
{
return v[i];
}
men det är i praktiken helt irrelevant när CPUer kan köra 8-12 instruktioner per cykel, men de är väldigt ofta begränsade av RAM-access och liknande så det mer är 1-4 instruktioner per cykel som faktiskt körs. Att checka ovan orsakar inga sådan problem då den data som behövs redan ligger i register/L1$.
Skrivet av klk:
Det nya är deklarativ programmering, istället för att skriva kod som programmerare gör så skriv en bok. Inget som ersätter utan det är något helt annat eftersom imperativ kod jämfört med deklarativ kod ofta är varandras motsatser.
???
Det här är deklarativt
SELECT name
FROM employees
WHERE salary > 50000;
det här är imperativt
result = []
for emp in employees:
if emp.salary > 50000:
result.append(emp.name)
I min bok ser Python mer ut som #2...
