Visa signatur
Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer
C++ och dess framtid att programmera minnessäkert - Hur går utvecklingen?
Skrivet av Yoshman:
Vad är det jag inte kan göra i Go, C#, Swift, etc här?
Varför byter inte alla till de språk du förespråkar? Hur kan man sitta kvar i skitspråket C/C++ ?
Finns de enligt dig en enda fördel med språket C/C++ (om du helt plockar bort ekosystemet)
Citera flera
Citera
Det mesta är redan sagt, men det egentliga problemet är att man använder ett lågnivåspråk, C++, för att göra saker som sedan länge är bättre lämpat för högnivåspråk. Andra språk spinner vidare på det och fortsätter läcka minne och vara kraschiga, medan det i 30 år har funnits språk som inte har de problemen. Rust är en nickning åt dem men når inte hela vägen. Jag tror att det är för sent, och att vi kommer att fortsätta använda osäkra och instabila språk och fortsätta ge mjukvara ryktet att vara osäker och instabil. Hade vi valt rätt för 30 år sen, hade mjukvara idag haft ryktet att vara säker och stabil. Man kan fortfarande skriva applikationer i dessa språk, men tyvärr är drivrutiner och API:er byggda på C/C++. Dessa språk måste bytas ut där också för att applikationer ska köra säkert och stabilt.
Visa signatur
[4790k@4.6]+[RTX 3070 OC]+[16GB]+[4x SSD]+[NZXT+700W Gold]+[Win7]+[2x Samsung SA27950D <3]+[Topre TKL]+[G403 Hero wired]+[HyperX Cloud Alpha S]+[KingKong 2 Pro]. ZBook 17 G5, Quadro P3200, Win11.
Citera flera
Citera
(1)
Skrivet av klk:
Varför byter inte alla till de språk du förespråkar? Hur kan man sitta kvar i skitspråket C/C++ ?
Tre huvudsakliga punkter
1. Historik, väldigt få har lyxen att gå jobba med green-field projekt. Val av språk är ofta redan gjort
2. Vi har ett gäng språk för de har olika designval i vad som är deras styrkor. Vilken som är "rätt" beror på vad ska göra, vilken/vilka target-plattformen/plattformarna är.
3. Har man lyxen att välja är det inte bara språkets styrkor som avgör. Spelar också roll vad de som ska jobba med det hela har för kunskaper och preferenser.
Skrivet av klk:
Finns de enligt dig en enda fördel med språket C/C++ (om du helt plockar bort ekosystemet)
C: inte många, men det är fortfarande ett kritiskt språk då typ allas FFI bygger på C ABI. Vidare är alla relevanta OS C-baserade.
C++: faktiskt inte, ser faktiskt inte ett enda fall där om jag fick välja helt fritt och inte var beroende på C++ p.g.a. av bibliotek eller liknande idag skulle välja C++.
C++ har alltid varit komplext, tidigare var det värt att betala för komplexiteten (och horribla kompileringstider) för det inte fanns inga realistiska alternativ.
Och säger inte det för jag hatar C eller C++, totalt sett är det just dessa två språk jag spenderat mest tid i under mina arbetstår. C++ är också det första "vettiga" språk jag lärde mig, kunde bara 68k-assembler, Turbo Pascal samt ett gäng BASIC-dialekter innan.
Gillar verkligen att lära mig nya språk, framförallt de som är "populära" (följde och kunde C# i "teorin" väldigt tidigt, men tog till 2022 innan jag faktiskt använde språket professionellt). Och det ihop med att jag råkat varit i situationer där språkval legat på mig har gett lyxen att kunna jobba med rätt många olika språk, framförallt med det jag trott varit "bästa val".
Nämnt Go flera gånger, det är något jag lite snubblade in på och som jag inte valt att kika på innan då jag inte riktigt fattade storheten i detta. Efter att använt det i ett par projekt nu har detta blivit en favorit. Styrkorna här är inte i häftiga språkfeatures utan på hur otroligt genomtänkt det är på systemnivå och at-scale.
Är det något där man vill pressa ut maximalt från CPUn skulle jag idag konsekvent välja Rust över C++, om möjligt vilket det långt ifrån alltid är p.g.a. historik.
C# är likt C++ främst bra då det finns så otroligt mycket skrivit redan, ihop med väldig mogen tooling.
Python är rätt mycket enda realistiska alternativet idag för AI/ML.
Så finns inget "bästa val", men ser inte hur C++ är bästa val någonstans idag utom i de fall där historik tvingar på det.
Visa signatur
Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer
Citera flera
Citera
(6)
Skrivet av HolyFather:
Det mesta är redan sagt, men det egentliga problemet är att man använder ett lågnivåspråk, C++, för att göra saker som sedan länge är bättre lämpat för högnivåspråk.
Har snart bättre exempel men är det här hög eller lågnivå? (klistrade in det tidigare)
auto valueResult = gd::expression::token::calculate_s("length( text )", { {"text", "0123456789012345"} });
auto valueResult = gd::expression::token::calculate_s( "10 - -10" );
auto valueResult = gd::expression::token::calculate_s("min( 100, 200 ) + 999 + max( 10, 30 )");
auto valueResult = gd::expression::token::calculate_s( "10 >= x", {{"x", 10}} );
Citera flera
Citera
Skrivet av Yoshman:
Är det något där man vill pressa ut maximalt från CPUn skulle jag idag konsekvent välja Rust över C++, om möjligt vilket det långt ifrån alltid är p.g.a. historik.
C# är likt C++ främst bra då det finns så otroligt mycket skrivit redan, ihop med väldig mogen tooling.
Python är rätt mycket enda realistiska alternativet idag för AI/ML.
Så finns inget "bästa val", men ser inte hur C++ är bästa val någonstans idag utom i de fall där historik tvingar på det.
Min spekulation.
Enligt mig så kommer C# minska och kanske till och med helt försvinna inom en 15 års period, kan gå snabbare beroende på AI. Den typ av kod som oftast skrivs med C# kan genereras relativt enkelt med AI. Microsoft har mer eller mindre sagt detta med.
Java kan gå samma väg även om jag tror att java är något mer stabilt.
Rust's popularitet tror jag hänger på Microsoft. Ser Microsoft affärsmöjligheter i att ta "över språket" kan det växa. Just nu är Rust inklämt mellan lågnivå och högnivå, svårt att tjäna pengar där. Störst problem med Rust enligt mig är att utvecklare inte tränas på arkitektur, det är för "lätt" att slänga ihop något och plocka saker från Cargo.
Tror Rust fortsatt kommer vara populärt för mindre open source applikationer.
Python tror jag fortsatt kommer vara mycket populärt, python konkurrerar inte med "vanliga" programmeringsspråk. Och det finns sådana extrema mängder pythonkod ute på företag så det lär fortsätta användas. Tror mer och mer python blir automatgenererad. Den typen av deklarativa kodning, där är LLM starkt.
C++ kan säkert också minska men det finns precis som Python enorma mängder kod och det är i princip bara inom detta område utvecklare hittas som klarar av att hantera större mängder kod. Bara jättebolag har råd att anställa utvecklare för andra språk där de också klarar stora projekt.
Nya AI-anpassade språk kommer säkert dyka upp snart och ta marknadsandelar
Citera flera
Citera
Skrivet av klk:
Fråga något AI verktyg, att jag skall behöva förklara skillnader mellan C++ och Python i tråden visar bara på hur lågt nivån sjunkit
AI verktyg är generellt ännu okunnigare än du. Vilket du vet mycket väl.
Men de skulle antagligen ge bättre (inte bra!) svar än du i det här fallet.
Du kan egentligen ingenting om Python, eller några andra programmeringsspråk än C++, eller hur? Det är därför du aldrig ger några raka svar på frågor - för du vet inte svaren, och försöker undvika att visa din okunnighet.
Motbevisa mig gärna. Om du kan.
Citera flera
Citera
(3)
Skrivet av Erik_T:
AI verktyg är generellt ännu okunnigare än du. Vilket du vet mycket väl.
Men de skulle antagligen ge bättre (inte bra!) svar än du i det här fallet.
Ibland när samhälle diskuteras och hur saker blir mer och mer specialiserade händer det att ordet expertsamhälle används.
Och vad är det? Vad innebär det att vara "expert".
Alla har nog sin tolkning då det är subjektivt.
Men för att ta det till programmering och något jag tror äldre programmerare observerat.
De som lärde sig koda fram till början på 90 talet. De är nästan samtliga självlärda. Deras intresse drev dem till att lära sig programmera och de tvingades anpassa sig samt experimentera. Det fanns inte färdiga lösningar och det vart mycket svårt att hitta information om hur man skulle göra. Tog mycket lång tid att lära sig hur saker löstes och under tiden gjordes också mycket misstag.
Skolan plockade upp programmering, det vart linjer på universitet mm som lärde ut programmering. Fler och fler lärde sig hur man skulle skriva kod via studier. När de kom ut i arbetslivet fick de också arbeta med mer människor som "lärt" sig hur saker skulle lösas. De hade inte testat fram det.
Att läsa sig till något är ofta fördelaktigt tidsmässigt, det går att lyckas göra något snabbare än om man måste experimentera och lära sig själv. Men man lär sig inte lika bra och förstår inte alla detaljer runt det man lärt sig.
En typisk expert som lärt sig via studier och en som lärt sig själv har ofta svårt att diskutera. Elever som fungerar bra i skolan är duktiga på att memorera och låter bli att tänka själva. Vår skola uppmuntrar inte kritiskt tänkande. Att ha fotografiskt minne är mycket förmånligt om man vill ha bra betyg.
När självlärda diskuterar med studielärda krockar det. Typiskt för studielärd är mycket snabba reaktioner. Om en självlärd presenterar en ide och den studielärde lyssnar, då tänker de olika. Den studielärde funderar över vad den läst medan den självlärde förstår tekniken.
Det svåra med dessa två grupper är problemen med att få till konstruktiva samtal. En självlärd kan presentera världens bästa ide, den studielärde begriper ändå inte för att den vet bara vad den läst. Och svar kommer blixtsnabbt eftersom en studielärd inte tänker utan bara letar i minnet om vad den tidigare läst.
Exakt så här fungerar AI med. AI är som en mycket bra uppslagsbok, det fungerar jättebra med att bolla ideer och göra det enklare.
Men skall man göra svårare saker fungerar det inte alls, precis som att prata med en "expert".
Microsoft Layoffs: Next Wave of Job Cuts to Target Mid-level Managers, Non-Tech Roles
Senast redigerat
Citera flera
Citera
Skrivet av klk:
...Det svåra med dessa två grupper är problemen med att få till konstruktiva samtal.
...
Välskriven och bra sammanfattning av olika sorters lärande och hur människor kan ha olika sätt att närma sig problem och diskussioner, det kan verkligen ställa till med kommunikationsproblem.
Men vad tänker du om ett hypotetiskt fall där någon har väldigt mycket åsikter om några ämnen, men personen i fråga är varken självlärd eller utbildad eller verkar ha någon slags erfarenheten av ämnena i fråga?
Finns det någon chans att det skulle bli svårt för en sådan person att diskutera med andra som har lång och gedigen erfarenhet i sådana ämnen oavsett om dom är självlärda eller skolade?
Eller ja, man mest bara undrar hur det skulle gå. Kanske finns det några exempel på nätet man kan titta på om man är nyfiken.
Citera flera
Citera
(10)
Min bild är att i princip alla teknikintresserade programmerar de en hel del i deras ungdom, sedan lite i skolan. Beroende på vilken utbildning så olika mycket. Sist kommer de ut i arbetslivet och vissa vad arbetslivet föredrar. Köpa en lösning som är vältestad under väldigt många år på flera ställen för kanske 20 000kr och konstant uppdateras eller få någon att utveckla en egen i princip otestad buggig lösning för 2 miljoner kronor? Detta leder till att väldigt många idag inte precis programmerar så mycket, man använder färdiga lösningar och arbetar med dem.
C++ för mig blir då mer en lösning för riktigt stora applikationer och spel, sedan finns det enstaka lösningar som brukar vara små. Det handlar då i princip alltid om att riktigt bra prestanda behövs.
Det jag tycker är tråkigt är hur världen har blivit. Det går inte länge ha en cykel utanför bostaden och det är inte precis så lätt att sälja applikationer. Så man kan utveckla hur grym applikation som helst, men för att förståndiga personer ska installera den så krävs det att man är väldigt betrodd, inte enkelt heller är det med att få in certifikat vilket annars hade skrämt bort typ alla att använda mjukvaran vid installationen.
Jag har själv utvecklat en Applikation som hade kunnat varit säljbar, men den målgrupp(tekniker) jag skulle sälja till installerar ej applikationer från okända. Om jag då gör en Webblösning, ja glöm de ger data till mig om de ej känner mig. Nu hade jag i princip inte tjänat en krona på min App, det är bara det jag har insett att det inte är en ekonomisk enkel lätt väg att satsa emot.
Och detta innebär att man får tänka till vad man kan göra för programmering? Mobilappar laddar folk hem som galningar och där är väl inte C++ så vanligt? Företagslösningar vill de ha så enkel att underhålla för så många som möjligt och C++ är inte alltid den enklaste språket för alla.
Senast redigerat
Citera flera
Citera
(2)
Skrivet av flexm:
Men vad tänker du om ett hypotetiskt fall där någon har väldigt mycket åsikter om några ämnen, men personen i fråga är varken självlärd eller utbildad eller verkar ha någon slags erfarenheten av ämnena i fråga?
Eftersom jag själv tycker det är extremt kul att programmera och någon bara "pratar" programmering så är jag på hugget direkt. Tycker sådant är fantastiskt kul, inte att prata men att arbeta och jobba med andra med samma intresse.
Om personer drar upp ideer jag själv inte tänkt på eller kanske helt nya områden är det också mycket bra, blir nyfiken och frågar. Försöker lära mig.
Där det krockar är när andra har svårt att ta in kritik eller lyssna. JA jag vet att nästan alla här inte tror jag läser och lyssnar.
Men för att ta ett exempel från tråden, några inlägg tidigare användes ett exempel för att visa trådning och då användes fibonacci för att visa.
Vet inte hur många varianter av fibonacci jag läst för att testa prestanda och trådar men det är många. fibonacci används nästan alltid och den gör det för att den är så enkel att tråda.
Visar någon det så är det inte jättesvårt att räkna ut att det handlar om "läs-kunskap" för den typen av parallelliserade arbeten är ganska långt ifrån verkliga lösningar. Det enda den visar är hur snabb en processor är på "compute" men även där är den dålig för det är så mycket annat som spelar roll. Men den är bättre att göra en loop som räknar från 0 till väldigt stort tal
Kan ta ett annat område där det lätt blir konflikt om jag är med i diskussionen
Hur man skall dokumentera kod och användningen av en "formatter".
Vanligt att team använder formatters och då sätts de ibland på max längd som en rad får lov att ha. För att bevisa att det är bra med längden (låt säga att de valt max 80 tecken) visar de kod där det ser bra ut. Ofta på enkel kod och det är kanske 95% av all kod som är enkel.
Men det är inte den koden man behöver konfigurera projektet för, det är de svårare delarna som stil måste anpassas för. Lätt kod kan nästan vara slarvig, det är inte några större problem ändå.
Är man då ett team med 5 juniora utvecklare och en erfaren, de juniora har läst i skolan hur man skall göra, vem tror du vinner?
De här juniora utvecklarna har inte hunnit göra något svårt än, de har inte suttit i "skiten".
"experter" har förstört massor inom programmering. Det är så mycket kunskap som gått förlorad
Eller för att ta den kanske viktigaste biten
Hur skriver man hanterbar kod som är sjusiffrigt antal rader
Senast redigerat
Citera flera
Citera
Skrivet av lillaankan_i_dammen:
...Det jag tycker är tråkigt är hur världen har blivit...
Absolut, håller med
Det är några IT jättar och de är duktiga på att lobba igenom regler som passar. IT är viktigare än olja vilket man ibland glömmer av, många vill kontrollera området
Och enligt mig är det också samma grupper som ligger bakom kritiken mot C++ och minne för det är så fruktansvärt korkat
Citera flera
Citera
Skrivet av klk:
Eller för att ta den kanske viktigaste biten
Hur skriver man hanterbar kod som är sjusiffrigt antal rader
Du tjatar om detta ganska ofta. Nu är det upp till bevis! Vad är det i C++ (språket alltså!) som gör koden lätt hanterbar när man har en miljon rader kod? Vilka språk-features in C++ gör det lätt hantera mycket kod. Jag vill inte höra något om IDEt eller anekdoter om att några klantarslen inte kunde hantera sin stora kodbas. Vad i C++ gör det lätt att hantera stora kodbaser?
Fram till C++20 fanns det ju inte ens modul-begrepp utan man var helt beroende av include-filer och inkluderade man dem i "fel" ordning så kunde betydelsen ändras. Det känns inte som en bra bas för att hantera mycket kod. Eller är det samma argument som vanligt, man lär sig med tiden?
Citera flera
Citera
(5)
Skrivet av klk:
Absolut, håller med
Det är några IT jättar och de är duktiga på att lobba igenom regler som passar. IT är viktigare än olja vilket man ibland glömmer av, många vill kontrollera området
Och enligt mig är det också samma grupper som ligger bakom kritiken mot C++ och minne för det är så fruktansvärt korkat
Jag anser utvecklingen generellt har gått emot cash is king. Och då ser de långsiktigt. De vill ha en lösning som fungerar så bra som möjligt och lätt att uppgradera under t.ex. 20år. Under dessa år kommer det komma in väldigt mycket olika personer, ibland helt nyexamerade ibland seniorer.
För vissa saker som spelutveckling, Photoshop, CAD och annat så är säkert C++ det bästa än idag, jag är väldigt osäker på detta, jag arbetar inte alls med såna gigantiska program. Mindre program däremot, ja många anser att det finns språk som är enklare.
När jag själv läste på högskolan för länge sedan älskade jag assembler, C och även C++. Det var så roligt att blanda in inlines assemblera etc. Sedan kom jag ut i arbetslivet och insåg vilket extremt fokus det är på pengar, kortsiktigt och långsiktigt. Likaså att folk ej vill låsa in sig i något vare sig företag eller personer.
Alltså ta in en person som är superduktig på vad som helst och den får den göra lösningar som kräver dennas kunskaper(skills), sedan slutar denna personen. Ja, då kan det bli att försöka leta upp en liknande person.
Eller så väljer man göra en lösning där det är enklare att hitta en ny ersättare.
*edit*
Jag påstår detta gäller i princip alla tekniska arbeten. För väldigt många uppgifter är det superviktigt att det är lätt att få någon kunna jobba vidare med lösningen. Inte det att lösningen är skapad av ett geni som har gjort en sådan komplex lösning som den bara kan och man måste hitta ett nytt geni inom detta område för att jobba vidare.
Visst forskningsprojekt och annat kräver riktigt grymma personer, men den stora skaran av arbetsmarknaden är mycket enklare.
Senast redigerat
Citera flera
Citera
(1)
Skrivet av klk:
Där det krockar är när andra har svårt att ta in kritik eller lyssna. JA jag vet att nästan alla här inte tror jag läser och lyssnar.
Men för att ta ett exempel från tråden, några inlägg tidigare användes ett exempel för att visa trådning och då användes fibonacci för att visa.
Vet inte hur många varianter av fibonacci jag läst för att testa prestanda och trådar men det är många. fibonacci används nästan alltid och den gör det för att den är så enkel att tråda.
Visar någon det så är det inte jättesvårt att räkna ut att det handlar om "läs-kunskap" för den typen av parallelliserade arbeten är ganska långt ifrån verkliga lösningar. Det enda den visar är hur snabb en processor är på "compute" men även där är den dålig för det är så mycket annat som spelar roll. Men den är bättre att göra en loop som räknar från 0 till väldigt stort tal
Då måste du helt ha missat vad det faktiskt handlade om.
När man ska exemplifiera något är det avgörande att just det man vill visa står i fokus. Om det man applicerar exemplet på är minst lika komplext som själva poängen, får man en rätt usel signal-till-brus-nivå.
Det som gör den rekursiva Fibonacci-serien så användbar här är att det man räknar ut är irrelevant i sammanhanget. Det man vill exemplifiera är:
1. Hur hanteras fall där indata/utdata-par är sinsemellan oberoende?
En av de få komplexiteterna här är att olika indata kan kosta olika mycket. Hur hanterar den valda metoden sådan obalans?
Ovanstående är trivialt att exemplifiera, det är bara att variera det heltal som är indata, samt antalet sådana indata!
2. Hur, om ens möjligt, kan man använda flera CPU-kärnor för att lösa ett och samma fall?
För desktop-användning är detta i 9 fall av 10 det mest intressanta.
Tyvärr är det betydligt mer komplicerat än fall 1. Fall 1 räcker ofta ganska bra på serversidan, men har rätt begränsad nytta på klientsidan.
Även detta fall är enkelt att exemplifiera, den språk-/plattformsspecifika delen alltså, eftersom det handlar om en typisk “divide-and-conquer”-algoritm (som nästan alltid bäst löses med någon form av work-stealing task scheduler).
Men vi inväntar det du skulle visa, kanske kommer det med helt nya insikter i ämnet.
Skrivet av klk:
Kan ta ett annat område där det lätt blir konflikt om jag är med i diskussionen
Hur man skall dokumentera kod och användningen av en "formatter".
Här tycker jag att Go-gänget visar att de verkligen har förstått problematiken i projekt som innefattar stora och/eller många team.
De flesta sätt att formatera kod är helt OK. Det som är fsck är när man inte kan komma överens om att följa en och samma modell, alternativt att man har en modell, men saknar verktyg som automatiskt säkerställer att den följs.
gofmt är ett standardverktyg som används “by default”, och stilen är förutbestämd av Go-teamet. Det betyder att inte bara din kod följer samma modell, det betyder att all kod man använder, även från externa projekt, följer samma stil.
DET är något som faktiskt hjälper i stora projekt. Det har egentligen inget med själva språket att göra, utan är ett designval man gjorde redan från början genom att inkludera detta i standardverktygen.
Det som ändå gör att även språket i sig hjälper i stora kodbaser med många inblandade, är att det är ett av de enklaste språk som har skapats. C++ är ju ganska mycket antitesen till just den punkten.
Skrivet av klk:
Eller för att ta den kanske viktigaste biten
Hur skriver man hanterbar kod som är sjusiffrigt antal rader
Har jobbat med kodbaser som är 6-, 7- och till och med 8-siffriga i SLOC. Jag är inte alls med på vad du menar skulle vara så unikt här, det är något som görs, och görs i fler språk än bara C++.
Skulle gissa att C är överlägset vanligast om man fokuserar på projekt med 7- och 8-siffriga SLOC. Är också rätt övertygad om att det finns ungefär lika många Java-projekt som C++-projekt idag med 7-siffriga kodbaser.
Men jag förstår inte alls vad som skulle göra C++ mer lämpat än andra språk. Som @Ingetledigtnamn påpekade är det knappast en fördel att C och C++ fortfarande drar runt på sina header-filer. Det är ett designbeslut som “alla” insett inte var optimalt.
Visa signatur
Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer
Citera flera
Citera
(6)
Skrivet av Yoshman:
Skulle gissa att C är överlägset vanligast om man fokuserar på projekt med 7- och 8-siffriga SLOC. Är också rätt övertygad om att det finns ungefär lika många Java-projekt som C++-projekt idag med 7-siffriga kodbaser.
Och vet du varför det nästan är bara C i dessa jätteprojekt?
Java räknar jag bort för det är i princip alltid automatgenererad kod som sköter databaser, går att producera mängder med kod men det är samma typ av kod överallt
Citera flera
Citera
Skrivet av Ingetledigtnamn:
Du tjatar om detta ganska ofta. Nu är det upp till bevis! Vad är det i C++ (språket alltså!) som gör koden lätt hanterbar när man har en miljon rader kod? Vilka språk-features in C++ gör det lätt hantera mycket kod.
Bristerna, bristerna i språket gör att språket lämpar sig för stora projekt. C++ har så mycket frihet att du måste lära dig saker som är mycket viktiga att behärska om du skall göra stora projekt. Andra språk har för mycket skydd, programmerare kommer så långt att de knappt tänker på att skriva om, de får inte nödvändig träning.
Det är inte speciellt svårt att skriva kod som bara kan växa och växa men man måste tänka på vissa saker och det är fasligt svårt att få in detta bland dagens utvecklare.
Om du sätter valfri junior utvecklare i C++, personen kommer kanske till 10 000 rader kod om det finns tallang, därefter är det ett fasligt trassel och man "tröttnar". Orsaken till att utvecklaren tröttnar beror på att det blir mentalt mycket jobbigt att komma ihåg alla lösningar man försökt sig på. När hjärnan spenderar så mycket syre på saker som inte är skapande, utvecklare vill skapa, inte sitta och försöka komma ihåg eller lista ut vad kod gör. Det orkar inte hjärnan och de tröttnar. Många hatar verkligen C++ på grund av detta.
Skriver jag C++ eller lär ut till någon så är det några saker som jag försöker pränta in direkt, ibland går det och ibland går det inte. Går det inte så ger jag dem en uppgift jag vet de kommer faila på. När de failat så kan vi fortsätta för då har de förstått bättre.
Har också failat och slitit med skitkod, det är inte kul.
Men dessa trix är mycket svåra att diskutera bland "experter", dessa experter som lärt sig, det är så här man skriver kod.
Citera flera
Citera
Skrivet av klk:
Och vet du varför det nästan är bara C i dessa jätteprojekt?
Kan inte tala för alla sådana projekt, men de jag jobbat i som haft så stora kodbaser hade en väldigt viktig gemensam nämnare: de var redan 25-30 år gamla projekt som fortfarande aktivt utvecklades.
Sen är tyvärr en av nackdelarna med C att det blir rätt mycket kod. Backar man till 80/90-talet var det ju rätt normalt att skriva "vanliga applikationer" i C. Idag vore det rätt korkat om man inte på något sätt är fast med C, för idag finns långt bättre alternativ.
Skrivet av klk:
Java räknar jag bort för det är i princip alltid automatgenererad kod som sköter databaser, går att producera mängder med kod men det är samma typ av kod överallt
Då undrar jag hur många Java-projekt du jobbat i...
Har själv (tack och lov, Java är inte min favorit) bara jobbat i två hyfsat stora Java-projekt. Det var knappast automatgenererad databaskod som stod för lejonparten...
För att ta ett exempel där vi har facit, Hadoop är knappast heller packat med auto-genererad databaskod. Det är ändå ca 2M Java-SLOC.
Visa signatur
Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer
Citera flera
Citera
(8)
Skrivet av Yoshman:
Kan inte tala för alla sådana projekt, men de jag jobbat i som haft så stora kodbaser hade en väldigt viktig gemensam nämnare: de var redan 25-30 år gamla projekt som fortfarande aktivt utvecklades.
Det har allt startats en hel del projekt med andra språk också. Stora projekt med andra språk har haft lättare att krascha. Har ju själv dragit upp ett men vet några till som inte så många andra vet om vad som faktiskt hänt.
Utan att outa något så är det väl välkänt att Ericsson brände sig på 90 talet när de hade några större C++ projekt de inte fick ihop. Det tog ett tag innan de vågade sig på C++ igen.
Nyligen har vi haft två statliga miljardprojekt som fått kasserats, skolplattformen och millenium.
Att C projekt kan växa och leva länge tror jag beror på att utvecklare måste förstå hårdvaran för att klara av att skriva C koden, bara där har man filtrerat bort flera riskabla moment. C är också mycket lättläst, det är nästan som att lästa uppifrån och ner och så förstår man vad som görs. En konsekvens av det är att C också är lätt att debugga och hitta fel i. C är superenkelt att jobba med.
Min största kritik mot C är att det blir mycket kod (som du också nämnt), skriva "smart" kod genom att använda finesser i språk eller abstrahera funktionalitet är inte alls som i andra språk. Språket är inte speciellt kreativt
Att Linux klarat att leva och växa så finns säkert många orsaker till men en av de viktigare kan vara att de så benhårt endast tillåtit C och att de har vissa regler i styleguiden som inte gör att utvecklare kan slarva.
Skrivet av Yoshman:
Då undrar jag hur många Java-projekt du jobbat i...
Inget, tar inte i java med tång. Java är bedrövligt, gjort massa skada för hela utvecklarkollektivet
Skrivet av Yoshman:
För att ta ett exempel där vi har facit, Hadoop är knappast heller packat med auto-genererad databaskod. Det är ändå ca 2M Java-SLOC.
Det finns alltid undantag och jag antar att detta projekt inte består av 70% testkod.
Java idag används nästan uteslutande som backend på servrar (räknar bort andriod på mobiler) och utan att veta så skulle jag höfta att det är minst 90% databaslogik så tror inte jag det är fel. De jag känner som använder java jobbar med den typen av applikationer och tror inte de deltagit i andra typer av projekt med java. Det är databas för hela slanten, liknande gäller C# (C# på windows och java på linux)
Kan vara värt och nämna Microsoft Office, de påstår att det är 300 miljoner rader kod. Tror det är en överdrift men det är väldigt mycket kod. Windows är runt 10 gånger större än Linux.
Senast redigerat
Citera flera
Citera
Skrivet av klk:
Det har allt startats en hel del projekt med andra språk också. Stora projekt med andra språk har haft lättare att krascha. Har ju själv dragit upp ett men vet några till som inte så många andra vet om vad som faktiskt hänt.
Det kan stämma och kan vara totalt fel, gissar att du likt jag har totalt noll relevant relevant information som på något sätt kan styrka hur det ligger till här.
Skrivet av klk:
Att C projekt kan växa och leva länge tror jag beror på att utvecklare måste förstå hårdvaran för att klara av att skriva C koden, bara där har man filtrerat bort flera riskabla moment. C är också mycket lättläst, det är nästan som att lästa uppifrån och ner och så förstår man vad som görs. En konsekvens av det är att C också är lätt att debugga och hitta fel i. C är superenkelt att jobba med.
Min största kritik mot C är att det blir mycket kod (som du också nämnt), skriva "smart" kod genom att använda finesser i språk eller abstrahera funktionalitet är inte alls som i andra språk. Språket är inte speciellt kreativt
C är definitivt ett mindre språk än t.ex. C++, C#, Rust och ett par andra som diskuterats i tråden. Men det är långt ifrån det enklaste språket som finns.
Många Lisp-dialekter tendera ha väldigt enkla språk definitioner. En av Go:s designmål och en av dess "killer-features" är att språket i sig är så lätt, något som ofta nämns gör det extra lämpligt i projekt med många medlemmar och många team.
Men tror ändå att den långt viktigare egenskapen för att C är så pass vanlig i stora projekt ändå är kombinationen av dess ålder, samt att det under 70-, 80- och början på 90-talet var ett av på den tiden relativt få språk lämpliga för systemprogrammering.
C är i första hand en portabel assembler. Enda "moderna" språket som verkar ha liknande designmål är Zig. Rust är helt klart mer en modern efterföljare till C++, även om Rust har en delmängd i form av Rust-core specifikt för användning där man inte vill eller kan ha OS-stöd (t.ex. om man använder Rust som del av sitt OS).
C++ har på senare år också en liknande delmängd i form av freestanding. Frågan där är: varför skulle man välja det över Rust-core givet att C++ här saknar sin största fördel i form av ett stort existerande bibliotek av program?
Skrivet av klk:
Att Linux klarat att leva och växa så finns säkert många orsaker till men en av de viktigare kan vara att de så benhårt endast tillåtit C och att de har vissa regler i styleguiden som inte gör att utvecklare kan slarva.
Linux har primärt växt och frodats för det helt enkelt blivit det bästa alternativet för en lång rad områden.
Det ironiska är ändå att Torvalds skapade Linux för att bygga en desktop-*NIX klon. Desktop är en av väldigt få områden där Linux inte är dominerande idag.
Skrivet av klk:
Inget, tar inte i java med tång. Java är bedrövligt, gjort massa skada för hela utvecklarkollektivet
Det kan du absolut tycka, men du har egentligen inget konkret att styrka det sista med.
Har i flera fall kunna följa och läst om något språk eller teknik under längre tid, ibland år. Men oavsett hur mycket man läser, hör andra berätta är det inte på något sätt samma sak som att faktiskt använda tekniken själv.
Extremfallet för mig är C# som jag började läsa på om när det lanserades och följt mer eller mindre nära sedan dess. Mycket för att i Sverige är .NET extremt populärt så det kändes som "måste ju bli något man kommer använda". Nästan lite komiskt att det tog till 2022 innan jag skrev första C# raden i jobbet...
Och när jag väl började använda det var det mycket jag kände till, men var också flera saker som inte alls stämde. Tycker t.ex. att de som anser att C# och Java är "nära varandra" saknar erfarenhet i minst ett av språken.
Java, C# C++ och C delar alla att det finns extremt stora ekosystem runt dem. Java stora styrka skulle jag säga är JVM-tekniken, specifikt hur extremt väl moderna JVM:er presterar (när de väl passerat "warm-up", vilket i sig gör JVM-språken mer lämplig för backend jämfört med desktop). Som tur är finns ju idag Kotlin om man skulle behöva jobba med Java
Skrivet av klk:
Det finns alltid undantag och jag antar att detta projekt inte består av 70% testkod.
Java idag används nästan uteslutande som backend på servrar (räknar bort andriod på mobiler) och utan att veta så skulle jag höfta att det är minst 90% databaslogik så tror inte jag det är fel. De jag känner som använder java jobbar med den typen av applikationer och tror inte de deltagit i andra typer av projekt med java. Det är databas för hela slanten, liknande gäller C# (C# på windows och java på linux)
Ok, låt oss ta exempel på saker skrivna i Java som jag själv använt hyfsat nyligen:
- Kafka är runt 1,2M SLOC, varav ca 200k är tester. Knappast heller dominerad av dataskod...
- IntelliJ IDEA är 2,5-3M SLOC, det är en IDE så definitivt inte dominerad av databaskod.
- WildFly är ca 1,5M SLOC, det är full-stack application server, så knappast heller dominerad av databaskod.
Ja, likt det mesta som utvecklas i Java på datorer så är det "backend". Men lite svårt att "räkna bort" mobiler idag givet att det säljs runt 10 smarta mobiler per dator idag, mängden programvara som skrivs för mobiler lär klart överstiga den som skrivs för datorer numer vilket gör Java/Kotlin till väldigt stora "applikationsspråk", där man också har en JVM som är optimerad på ett helt annat sätt för att passa use-case:et.
Visa signatur
Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer
Citera flera
Citera
(7)
Lite on-topic igen
En väldigt lång video, över 1h20m. Men en video som väldigt bra belyser vanliga misstag som görs i C++, hur motsvarande Rust-kod ser ut (och de som ser videon kommer notera hur lika mycket är mellan dessa språk på kodnivå) samt en förklaring till varför endast två designdetaljer i Rust helt eliminerar dessa fel (ger kompileringsfel istället för UB)
Det två detaljerna är
1. References are always valid. No dangling pointers.
2. Mutable references are unique. No mutable aliasing.
Är dessa två + hur man designat vissa delar av standardbiblioteket som bl.a. gör att data-race blir kompileringsfel, att Rust-kompilator i vissa lägen kan göra mer optimeringar jämfört med motsvarande C++ (främst från 2.), etc.
Kan man C++ bara på någorlunda hyfsad nivå kommer nog all Rust i videon vara rätt självklar. Den är gjort just ur aspekten, "förklara hur Rust fungerar för någon som kan C++". Den går väldigt bra in på saker som ofta är grunden i säkerhetsbuggar i C++ kod.
Visa signatur
Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer
Citera flera
Citera
(7)
Skrivet av Yoshman:
Lite on-topic igen
En väldigt lång video, över 1h20m. Men en video som väldigt bra belyser vanliga misstag som görs i C++, hur motsvarande Rust-kod ser ut (och de som ser videon kommer notera hur lika mycket är mellan dessa språk på kodnivå) samt en förklaring till varför endast två designdetaljer i Rust helt eliminerar dessa fel (ger kompileringsfel istället för UB)
Håller med om att det var en bra video och lyckades ta mig igenom det mesta även om jag spelade på högre hastighet. Har inte tittat på någon som jämför med C++ på det viset och det var bra för egen del, då förstår jag bättre varför de designat språket som de gjort.
Min uppfattning som kanske delats av andra om Rust är att man inte förstår varför språket skulle vara så bra, hur ett språk med så mycket hinder och lustig syntax kan locka eller locka en viss grupp utvecklare så extremt? Tror jag förstår varför nu
Rust är ett "bra" utbildningspråk men inte på att skriva kod utan att förstå minneshantering. Utvecklare som lärt sig skriva kod utan att tänka på minnet, för dem att gå in i C++ är en stor förändring. Om de däremot går genvägen via Rust kan de säkert förstå C++ bättre om de vill ta sig vidare och inte stannar på Rust.
Tror att rusts fördel också är dess motståndare och gör ett försök att beskriva varför
Rust är inte designat för att vara ett läsbart språk med logik, rust är designat för att förhindra framförallt minnesbuggar. Innan jag såg videon förstod inte jag hur extrem anpassningen efter det var. Förstår det bättre nu. Tror också det är orsaken till att om man är van vid normala språk uppfattar rusts syntax så udda. Språket skiljer sig radikalt mot allt annat. Rust försöker ta de enklare språken och göra dem som C++.
Problemet som jag tror Rust har är att det också är bra på att lära programmeraren hur den skall hantera minnet, språket tvingar utvecklaren till att skriva "korrekt" kod sett till minnet. Men när utvecklaren lärt sig det så blir hindren i språket en börda.
Varför vana C++ utvecklare kräks på Rust
Beskriver hur jag brukar skriva kod, kan möjligen vara lite extremt men det det finns andra C++ utvecklare som går åt det hållet. Så ovanligt är det inte.
Normalt delar jag in kod i kvalitetsnivåer och tänket kommer från extreme programmering. Finns många tekniker idag som har sitt ursprung därifrån.
Enklare förklaring av extreme programmering är att kod lever, den är aldrig klar. Går alltid att göra koden bättre.
Därför anpassas arbetet för att hela tiden göra det enkelt att förbättra kod. Som utvecklare måste man när som helst kunna gå in i kod och klara av att förbättra den utan att göra sönder koden.
Det är verkligen inte lätt att lära sig men de utvecklare som förstår är mycket effektiva.
De kvalitetsnivåer jag använder är bara något som fungerat, andra kan ha andra tekniker.
De är "play", "target", "source", "general"
"play" = lekkod, denna kod är endast för att testa och "leka" fram funktionalitet. Kod här får skrivas precis hur som helst och det skrivs mycket men slängs också.
"target" = hårdkodad funktionalitet för ett en target och target kommer från CMake. I CMake används target och kan beskrivas som en applikation eller ett bibliotek. Koden där är unik för just den applikationen eller det biblioteket. Koden är inte skriven för att kunna delas till andra applikationer eller bibliotek.
"source" = Jobbar man i större projekt brukar dessa ha flera targets men varje taget har en hel del likheter. Kod som kan delas i just det projekt mellan targets ligger i source.
"general" = det här är kod som nästan är lika generell som stl. Det är kod som kan delas i valfritt C++ projekt och koden måste hålla mycket hög kvalitet och "fungera".
Syftet med att dela upp kod så här flera men framförallt återanvändning, att flera utvecklare med olika skicklighet skall kunna jobba tillsammans, att det skall vara lärorikt att jobba i koden, förhindra buggar.
Vilken ny programmerare som helst kan direkt gå in i "play" och göra vad den vill för att ta ett exempel. "play" kod kan använda kod i nivåer under men koden under kan självklart inte använda sig av "play" kod. Samma sak mellan de andra nivåerna, nivån under kan använda kod från nivån över men inte tvärtom.
Varför ovanstående inte fungerar med Rust
Sitter jag och skriver "play" kod så vill jag inte bråka med ett språk som har en massa regler för vad som går och inte går att göra. Skydden i rust blir där ett stort hinder. Personligen så klistrar jag ofta in kod från annat man hittar och testar, skriver om eller plockar bort "private" för att kunna leka och se vad som händer och lära mig annan kod. Det hade inte fungerat med "rust" för det blir så mycket fokus på att skriva "rätt".
I extreme programming är det helt ok att skriva kod som är planerad att slängas. Ingen utvecklare skriver den perfekta koden på första försöket. Har team metodik som går ut på att de skall skriva rätt på första försöket när det handlar om egendesignad kod kommer projektet att krascha, fungerar inte.
De allra flesta mjukvaruprojekt följer fasta ramverk så därför kan säkert en hel del utvecklare vara ovana vid tänket. Skall man gå i mål med större lite udda projekt däremot, då måste det till.
Sammanfattning: Rust är bra för att lära sig
Citera flera
Citera
Skrivet av klk:
Håller med om att det var en bra video och lyckades ta mig igenom det mesta även om jag spelade på högre hastighet. Har inte tittat på någon som jämför med C++ på det viset och det var bra för egen del, då förstår jag bättre varför de designat språket som de gjort.
Min uppfattning som kanske delats av andra om Rust är att man inte förstår varför språket skulle vara så bra, hur ett språk med så mycket hinder och lustig syntax kan locka eller locka en viss grupp utvecklare så extremt? Tror jag förstår varför nu
Rust är ett "bra" utbildningspråk men inte på att skriva kod utan att förstå minneshantering. Utvecklare som lärt sig skriva kod utan att tänka på minnet, för dem att gå in i C++ är en stor förändring. Om de däremot går genvägen via Rust kan de säkert förstå C++ bättre om de vill ta sig vidare och inte stannar på Rust.
Tror att rusts fördel också är dess motståndare och gör ett försök att beskriva varför
Rust är inte designat för att vara ett läsbart språk med logik, rust är designat för att förhindra framförallt minnesbuggar. Innan jag såg videon förstod inte jag hur extrem anpassningen efter det var. Förstår det bättre nu. Tror också det är orsaken till att om man är van vid normala språk uppfattar rusts syntax så udda. Språket skiljer sig radikalt mot allt annat. Rust försöker ta de enklare språken och göra dem som C++.
Problemet som jag tror Rust har är att det också är bra på att lära programmeraren hur den skall hantera minnet, språket tvingar utvecklaren till att skriva "korrekt" kod sett till minnet. Men när utvecklaren lärt sig det så blir hindren i språket en börda.
Varför vana C++ utvecklare kräks på Rust
Beskriver hur jag brukar skriva kod, kan möjligen vara lite extremt men det det finns andra C++ utvecklare som går åt det hållet. Så ovanligt är det inte.
Normalt delar jag in kod i kvalitetsnivåer och tänket kommer från extreme programmering. Finns många tekniker idag som har sitt ursprung därifrån.
Enklare förklaring av extreme programmering är att kod lever, den är aldrig klar. Går alltid att göra koden bättre.
Därför anpassas arbetet för att hela tiden göra det enkelt att förbättra kod. Som utvecklare måste man när som helst kunna gå in i kod och klara av att förbättra den utan att göra sönder koden.
Det är verkligen inte lätt att lära sig men de utvecklare som förstår är mycket effektiva.
De kvalitetsnivåer jag använder är bara något som fungerat, andra kan ha andra tekniker.
De är "play", "target", "source", "general"
"play" = lekkod, denna kod är endast för att testa och "leka" fram funktionalitet. Kod här får skrivas precis hur som helst och det skrivs mycket men slängs också.
"target" = hårdkodad funktionalitet för ett en target och target kommer från CMake. I CMake används target och kan beskrivas som en applikation eller ett bibliotek. Koden där är unik för just den applikationen eller det biblioteket. Koden är inte skriven för att kunna delas till andra applikationer eller bibliotek.
"source" = Jobbar man i större projekt brukar dessa ha flera targets men varje taget har en hel del likheter. Kod som kan delas i just det projekt mellan targets ligger i source.
"general" = det här är kod som nästan är lika generell som stl. Det är kod som kan delas i valfritt C++ projekt och koden måste hålla mycket hög kvalitet och "fungera".
Syftet med att dela upp kod så här flera men framförallt återanvändning, att flera utvecklare med olika skicklighet skall kunna jobba tillsammans, att det skall vara lärorikt att jobba i koden, förhindra buggar.
Vilken ny programmerare som helst kan direkt gå in i "play" och göra vad den vill för att ta ett exempel. "play" kod kan använda kod i nivåer under men koden under kan självklart inte använda sig av "play" kod. Samma sak mellan de andra nivåerna, nivån under kan använda kod från nivån över men inte tvärtom.
Varför ovanstående inte fungerar med Rust
Sitter jag och skriver "play" kod så vill jag inte bråka med ett språk som har en massa regler för vad som går och inte går att göra. Skydden i rust blir där ett stort hinder. Personligen så klistrar jag ofta in kod från annat man hittar och testar, skriver om eller plockar bort "private" för att kunna leka och se vad som händer och lära mig annan kod. Det hade inte fungerat med "rust" för det blir så mycket fokus på att skriva "rätt".
I extreme programming är det helt ok att skriva kod som är planerad att slängas. Ingen utvecklare skriver den perfekta koden på första försöket. Har team metodik som går ut på att de skall skriva rätt på första försöket när det handlar om egendesignad kod kommer projektet att krascha, fungerar inte.
De allra flesta mjukvaruprojekt följer fasta ramverk så därför kan säkert en hel del utvecklare vara ovana vid tänket. Skall man gå i mål med större lite udda projekt däremot, då måste det till.
Sammanfattning: Rust är bra för att lära sig
Började kika på XP 1999 och jobbar idag på ett sätt som faller inom denna metod. Ställer mig lite frågande till vilken del av XP som säger att det är absolut kritiskt att kunna skriva kod med UB, för det är i praktiken den enda begränsning du har i den Rust videon gick igenom jämfört med C++.
Kanske dags att släppa det hävdar kring "man behöver inte förstå minne om man jobbar med Rust" och "det går inte att hantera minne tillräckligt flexibelt i Rust". Det går att skriva OS och drivers i Rust, det rätt mycket är det enda bevis man behöver för att med stor säkerhet säga: man kan göra allt relevant med minne.
Går även att göra UB i Rust, enda skillnaden mot C++ är att det är "opt-in" i form av "unsafe".
Är lite förvånad att du gillar XP då två av hörnstenarna där är TDD (vilket inte är samma sak som "gödsla med asserts", men även det har värde) samt "do the simplest thing that could possibly work, refactor when needed". Det senare kommer kräva förändringar av implementation, vilket tenderar bli allt annat än enkelt om man exporterar ett stort API då de som använder sådan kod kommer göra beroenden detta. Kritiskt att ha så litet API som möjligt för effektiv "refactor".
Och "konstigt syntax". Påminner om "simple made easy" videon. Du blandar ihop dessa två egenskaper. Både C++ och Rust har tyvärr allt annat än enkel syntax, de är tvärtom två av de mest komplexa språk som existerar. Men att du tycker Rust är svårare att förstå kommer bara av att C++ är för dig enklare då du inte har någon relevant erfarenhet med Rust.
För att ta några konkreta exempel, och undrar om ens du kan hävda att C++ är mer läsbart här...
C++
#include <concepts>
#include <cstdint>
#include <iostream>
#include <iterator>
#include <ranges>
class Fibonacci : public std::ranges::view_interface<Fibonacci> {
public:
struct Iterator {
using value_type = uint32_t;
using difference_type = std::ptrdiff_t;
using iterator_concept = std::input_iterator_tag;
uint32_t curr = 0;
uint32_t next = 1;
value_type operator*() const noexcept {
return curr;
}
Iterator& operator++() noexcept {
auto temp = curr;
curr = next;
next = temp + next;
return *this;
}
void operator++(int) noexcept { ++(*this); }
constexpr bool operator==(std::default_sentinel_t) const noexcept {
return next > UINT32_MAX / 2;
}
};
constexpr Iterator begin() const noexcept {
return Iterator{};
}
constexpr std::default_sentinel_t end() const noexcept {
return {};
}
};
static_assert(std::ranges::range<Fibonacci>);
static_assert(std::input_iterator<Fibonacci::Iterator>);
int main() {
for (auto n : Fibonacci{} | std::views::take(100)) {
std::println("{}", n);
}
}
Rust
#[derive(Debug)]
struct Fibonacci {
curr: u32,
next: u32,
}
impl Default for Fibonacci {
fn default() -> Self {
Fibonacci { curr: 0, next: 1 }
}
}
impl Iterator for Fibonacci {
type Item = u32;
fn next(&mut self) -> Option<Self::Item> {
if self.next > u32::MAX / 2 {
return None
}
let current = self.curr;
self.curr = self.next;
self.next = current + self.next;
Some(current)
}
}
fn main() {
for n in Fibonacci::default().into_iter().take(100) {
println!("{}", n)
}
}
iterator för egen typ, det är så komplex i C++ att det i praktiken används rätt sällan jämfört med t.ex. Rust och än mer C# där det är trivialt att göra
C++
// string find
size_t found = s1.find(s2);
if (found != string::npos) {
cout << "first 'object' found at: " << found << endl;
}
// string reverse find
found = s1.rfind(s2);
if (found != string::npos) {
cout << "last 'object' found at: " << found << endl;
}
Rust
// string find
if let Some(found) = s1.find(s2) {
println!("first 'object' found at: {}", found);
}
// string reverse find
if let Some(found) = s1.rfind(s2) {
println!("last 'object' found at: {}", found);
}
strängsökning med standardbibliotek
Går att göra rätt många liknande exempel. Ja, Rust är komplex när man skapar egen typer och man vill ha funktioner som returnerar referenser till saker. Då måste man förstå "borrow-checker" och de anoteringar som krävs för att kompilator ska kunna göra rätt analys. Var ett exempel på detta i videon. Utanför det har jag svårt att se var Rust är mer komplex jämfört med motsvarande C++ (men båda är som sag definitivt komplexa!!!).
Hoppas och tror ändå att videon gav en del insikter. Om inte annat borde det nu vara lite enklare att förstå varför Rust-kompilatorn ibland kan göra mer aggressiva optimeringar jämfört med C++. Det är helt enkelt en del antaganden som är sanna 100 % av tiden i Rust, men bara nästan 100 % av tiden i C++ och kompilatorer kan inte ignore "nästan" i de lägena.
Visa signatur
Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer
Citera flera
Citera
(10)
Skrivet av klk:
Rust är inte designat för att vara ett läsbart språk med logik, rust är designat för att förhindra framförallt minnesbuggar. Innan jag såg videon förstod inte jag hur extrem anpassningen efter det var. Förstår det bättre nu.
Det här stämmer inte för de av oss som faktiskt använder språket. Jag använder Rust för att det är ett produktivt språk som är lätt att uttrycka sig i. Att det är säkert är bara en bonus. De tre hörnstenarna i Rust är
> Performance
> Reliability
> Productivity
Källa: https://www.rust-lang.org/
Vad sägs om att faktiskt lära dig språket innan du gör massa antaganden?
Senast redigerat
Källa, kan inte stava
Citera flera
Citera
(6)
Skrivet av spiksoppa:
Det här stämmer inte för de av oss som faktiskt använder språket. Jag använder Rust för att det är ett produktivt språk som är lätt att uttrycka sig i. Att det är säkert är bara en bonus. De tre hörnstenarna i Rust är
> Performance
> Reliability
> Productivity
Källa: https://www.rust-lang.org/
Vad sägs om att faktiskt lära dig språket innan du gör massa antaganden?
Hur menar du att det skiljer sig mot vad jag skrev?
Personligen så det jag saknar i språket är frihet och min kritik mot språket var att lösningarna (designen) i språket har sådant fokus på de saker du räknar upp.
Dess fördelar är också dess nackdelar
Citera flera
Citera
Skrivet av spiksoppa:
Det här stämmer inte för de av oss som faktiskt använder språket. Jag använder Rust för att det är ett produktivt språk som är lätt att uttrycka sig i. Att det är säkert är bara en bonus. De tre hörnstenarna i Rust är
> Performance
> Reliability
> Productivity
Källa: https://www.rust-lang.org/
Vad sägs om att faktiskt lära dig språket innan du gör massa antaganden?
Ett till och nu tänker jag såga Rust vid fotknölarna.
Angående dina tre ord för hur rust är designat så
> Performance: kommentar: Min tolkning av rust är att rust skall likna "enkla" språk men få till snabbheten i C++
> Reliability: kommentar: Det här tolkar jag som är det övergripande, kommer i första rum. Allt annat får stå tillbaka om det inte är säkert
> Productivity: kommentar: ALLA språk är designade efter produktivitet, gäller bara att förstå vilken för olika programmerare har olika krav och det varierar både med kunskap och vilken typ av mjukvara som görs
Beskriver två områden som enligt mig är mer eller mindre katastrof i designen, de måste ändra om språket skall kunna växa till bredare skaror.
Jämför man C++ och Rust så är C++ designat efter principer. En sådan princip är att alla objekt har konstruktör och destruktion. Det viktiga är principen, att språket följer fasta regler. Även om C++ har mycket högt fokus på prestanda så är principerna det viktiga.
Att införa hack i språket är omöjligt, knappt någon C++ programmerare hade accepterat det.
Rust har inte samma principer efter vad jag lyckats lista ut. Sökt en del efter jag tittade på genomgången för att kolla upp saker som enligt mig var underliga. Det blev inte mindre underligt efter jag läst. Kan ha missuppfattat men då blir jag nog rättad snabbt här i tråden
I rust heter destruktionsobjektet Drop. Så fort man behöver destruera på ett annorlunda sätt behöver denna Drop metod implementeras. Och till det lägger man till en trait (ett beteende), i rust kan man lägga till en hel hög med beteenden (traits).
Så var i ligger problemet? Problemet är att det inte är en princip, ett fast mönster som går igen.
Skillnaden kan tyckas liten men när saker växer så behöver man i rust känna till mer om koden för att veta medan det i C++ gäller allt. Eftersom rust inte har arv och andra mer avancerad språkhantering kanske de inte tänker på principen på samma sätt som C++.
C++ är mer genomtänkt för jag tolkar metoden Drop som ett hack.
För att fortsätta på spåret så enligt mig så det viktigaste i C++ är att förstå konstruktörer och destruktion, görs den hanteringen smart blir hela objekten och koden mycket smidigare att jobba med.
Rust har ingen konstruktor utan även där en metod som heter new. Inte lika snyggt men kanske hanterbart tills man lär sig att Rust inte kan överlagra metoder.
Rust måste lägga till att överlagra metoder annars kommer det aldrig bli mer än ett språk för en liten klick. Det tog jag för en självklarhet så inte ens letat, råkade hitta det nu när jag försökte förstå hur objekt skapas och förstörs.
Istället för att som i C++ ha flera olika konstruktörer används en teknik kallad "builder pattern", liknar message chainging. Det här är för mig direkt i soptunnan. Om jag använder objekt och det är massa extra kod i annan kod för hur objektet skapas upp, det blir en mardröm när man skall designa om eller refaktorera koden.
I C++ där principerna är viktiga, där är fokus att man skall kunna jobba med ett objekt, göra det så bra som möjligt och sedan "glömma" koden i objektet, objektet följer principer. Man behöver inte veta vilka attribut (medlemmar mm) objektet har.
Att Rust inte kan överlagra metoder gör också att jag förstår bättre varför de de standardiserade objektet har så många metoder och onödigt långa namn, enda sättet att sära på metoder är med namn och då blir namnen längre.
Skapas objekt i C++ och det exempelvis har en metod kallad "add". det läggs till saker. Då behöver jag bara veta den metoden och sedan avgör argumenten av olika överlagrade "add" metoder vad som görs. C++ har stort fokus på data och för att läsa C++ kod så behöver man först läsa namnet och koppla det till argument. Minnet är helt centralt när C/C++ utvecklare skriver kod.
Jag tror inte minnet är det för Rust, utvecklare i Rust är språkbegåvade.
Citera flera
Citera
Skrivet av klk:
Jämför man C++ och Rust så är C++ designat efter principer. En sådan princip är att alla objekt har konstruktör och destruktion. Det viktiga är principen, att språket följer fasta regler. Även om C++ har mycket högt fokus på prestanda så är principerna det viktiga.
Att införa hack i språket är omöjligt, knappt någon C++ programmerare hade accepterat det.
C++ är inte *designat* för fem öre. Det började som ett rent hack av C ("C with classes"), där sedan nya features lagts till efter hand utan någon övergripande plan, och utan några principer som behövde följas.
Mängder av "objekt" har varken konstruktor eller destruktor - jag tänker då främst på alla de grundläggande typerna som heltal, teckensträngar, m.m.
Jag är inte så bekant med Rust, men skaparna av det verkar åtminstone ha haft en genomtänkt plan för språket.
Citera flera
Citera
(5)
Skrivet av Erik_T:
C++ är inte *designat* för fem öre. Det började som ett rent hack av C ("C with classes"), där sedan nya features lagts till efter hand utan någon övergripande plan, och utan några principer som behövde följas.
Har påskfirandet redan börjat?
Vet inte vad jag skall svara på det mer än att du har fel. Det är många som vill vara med och säga sitt när nya saker skall in i språket
Citera flera
Citera
Skrivet av klk:
Ett till och nu tänker jag såga Rust vid fotknölarna.
Angående dina tre ord för hur rust är designat så
> Performance: kommentar: Min tolkning av rust är att rust skall likna "enkla" språk men få till snabbheten i C++
> Reliability: kommentar: Det här tolkar jag som är det övergripande, kommer i första rum. Allt annat får stå tillbaka om det inte är säkert
> Productivity: kommentar: ALLA språk är designade efter produktivitet, gäller bara att förstå vilken för olika programmerare har olika krav och det varierar både med kunskap och vilken typ av mjukvara som görs
Beskriver två områden som enligt mig är mer eller mindre katastrof i designen, de måste ändra om språket skall kunna växa till bredare skaror.
Jämför man C++ och Rust så är C++ designat efter principer. En sådan princip är att alla objekt har konstruktör och destruktion. Det viktiga är principen, att språket följer fasta regler. Även om C++ har mycket högt fokus på prestanda så är principerna det viktiga.
Att införa hack i språket är omöjligt, knappt någon C++ programmerare hade accepterat det.
Både Rust och C++ är byggt på en lång rad principer. Väldigt många av deras principer överlappar, bl.a. att prestanda/effektivitet är kritiskt. De skiljer på den punkten i att Rust säger att UB är aldrig acceptabelt i "safe Rust", medan C++ historiskt inte haft någon sådan policy (men är lite den man nog kommit fram till att man bör ändra framåt).
Sen skiljer de på en viktig fundamental punkt. C++ startade som "C with classes", där OO-delen är start inspirerad av Simula.
Rust kommer från ML, ett funktionellt språk. Rust är dock mindre drakoniskt funktionellt och går rätt bra att programmera OO m.h.a. struct+traits.
Skrivet av klk:
I rust heter destruktionsobjektet Drop. Så fort man behöver destruera på ett annorlunda sätt behöver denna Drop metod implementeras. Och till det lägger man till en trait (ett beteende), i rust kan man lägga till en hel hög med beteenden (traits).
Så var i ligger problemet? Problemet är att det inte är en princip, ett fast mönster som går igen.
Skillnaden kan tyckas liten men när saker växer så behöver man i rust känna till mer om koden för att veta medan det i C++ gäller allt. Eftersom rust inte har arv och andra mer avancerad språkhantering kanske de inte tänker på principen på samma sätt som C++.
C++ är mer genomtänkt för jag tolkar metoden Drop som ett hack.
Skulle kalla "trait Drop" för allt annat än ett hack. Det kommer från en väldigt hård princip i hur Rust är designat och är långt fler traits som är "opt-in" för en rad beteenden man kanske vill ha.
Skrivet av klk:
För att fortsätta på spåret så enligt mig så det viktigaste i C++ är att förstå konstruktörer och destruktion, görs den hanteringen smart blir hela objekten och koden mycket smidigare att jobba med.
Rust har ingen konstruktor utan även där en metod som heter new. Inte lika snyggt men kanske hanterbart tills man lär sig att Rust inte kan överlagra metoder.
I Rust är det idiomatiska sättet att göra en konstruktor att ha med en "new" metod i sin typ-implementation. Man kan också välja att ha en default-kontruktor genom att implementera "trait Default".
Skrivet av klk:
Rust måste lägga till att överlagra metoder annars kommer det aldrig bli mer än ett språk för en liten klick. Det tog jag för en självklarhet så inte ens letat, råkade hitta det nu när jag försökte förstå hur objekt skapas och förstörs.
Rust är långt ifrån ensam av de "nya" språket att inte ha med överlagring. Det finns en lång rad problem med detta som är rätt komplexa. Men finns helt klart användningsområden också, så valet här är inte självklart.
Skrivet av klk:
Istället för att som i C++ ha flera olika konstruktörer används en teknik kallad "builder pattern", liknar message chainging. Det här är för mig direkt i soptunnan. Om jag använder objekt och det är massa extra kod i annan kod för hur objektet skapas upp, det blir en mardröm när man skall designa om eller refaktorera koden.
Öh, med builder-pattern går det ju utmärkt att ha en default-ctor + ett gäng metoder. Och det går hur bra som helst att göra i Rust!
Visa signatur
Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer
Citera flera
Citera
(5)
Skrivet av Yoshman:
Började kika på XP 1999 och jobbar idag på ett sätt som faller inom denna metod. Ställer mig lite frågande till vilken del av XP som säger att det är absolut kritiskt att kunna skriva kod med UB, för det är i praktiken den enda begränsning du har i den Rust videon gick igenom jämfört med C++.
Det är inte kritiskt med C++, XP används i olika former av nästan alla. Men det finns bättre och sämre sätt att hantera kod på ett flexibelt sätt. Poängen är ändå att ta sig från A till B och det på ett så bra sätt som möjligt.
Skrivet av Yoshman:
Kanske dags att släppa det hävdar kring "man behöver inte förstå minne om man jobbar med Rust" och "det går inte att hantera minne tillräckligt flexibelt i Rust". Det går att skriva OS och drivers i Rust, det rätt mycket är det enda bevis man behöver för att med stor säkerhet säga: man kan göra allt relevant med minne.
Ja eller kanske mer att Rust hjälper programmerare med att förstå riskerna med minne samtidigt som språket också förhindrar att utsätta sig för risker. Förståelse för minne kan säkert uppnås men inte vana att jobba med minne och det tror jag ogillas bland många i C och C++.
Att det går skriva OS i rust är en sak, tror inte det kommer göras.
Skrivet av Yoshman:
Är lite förvånad att du gillar XP då två av hörnstenarna där är TDD (vilket inte är samma sak som "gödsla med asserts", men även det har värde) samt "do the simplest thing that could possibly work, refactor when needed". Det senare kommer kräva förändringar av implementation, vilket tenderar bli allt annat än enkelt om man exporterar ett stort API då de som använder sådan kod kommer göra beroenden detta. Kritiskt att ha så litet API som möjligt för effektiv "refactor".
XP är luddigt och TDD är bara en rekommendation. Utan att kunna bevisa det skulle det inte förvåna att XP med TDD kommer från java kollektivet. Java har som jag tidigare nämnt förstört massor. Har aldrig och kommer aldrig jobba i ett projekt med som bygger på TDD men några vänner har jobbat med personer som försökt bygga program med TDD och de vart aldrig klara. Det skrivs test efter test utan att komma någonvart. Därmed inte sagt att det inte går men TDD är en fantastisk metod om man vill göra det svårt för sig själv.
Det fungerar möjligen i språk likt java och C# eftersom det inte är meningen att utvecklare där skall hitta på egna lösningar. Fokus är att använda deras respektive runtime bibliotek.
C++ kan du med lite kreativitet göra så mycket mer.
Skrivet av Yoshman:
Och "konstigt syntax". Påminner om "simple made easy" videon. Du blandar ihop dessa två egenskaper. Både C++ och Rust har tyvärr allt annat än enkel syntax, de är tvärtom två av de mest komplexa språk som existerar. Men att du tycker Rust är svårare att förstå kommer bara av att C++ är för dig enklare då du inte har någon relevant erfarenhet med Rust.
Problemet med Rust är att du måste lära dig syntaxen, det behöver du inte i C++. De som inte skriver den svåra koden i C++ projekt behöver heller inte lära sig detaljer i språket. Men projekten behöver ha minst en person som kan C++ på djupet för annars är C++ troligen det bästa språket att välja om projektet skall krascha så snabbt som möjligt. Någon måste kunna köra bilen för att ta en liknelse.
Skrivet av Yoshman:
För att ta några konkreta exempel, och undrar om ens du kan hävda att C++ är mer läsbart här...
Nu jämför du äpplen och päron. C++ kod skrivs inte som den görs i Rust om man använder språket på rätt sätt.
Citera flera
Citera
- Bygga en dator i mindre chassi9
- Windows 11 25H2 nära lansering24
- Här är de fem första rekryterna till Battlefield 6: Slaget18
- Alternativ till Spotify0
- Ska köpa 5070 Ti - finns chans till prissänkning under hösten?1
- Big techs - Big no. Vilken mediaspelare ska jag välja?4
- Sista koll inför beställning - budget ca 20k (4K-gaming)15
- Övriga Fynd – Diskussionstråd2,6k
- Dagens fynd — Diskussionstråden55k
- Teenage Engineering släpper gratischassi – slut direkt60
- Säljes Intel i5 12600K
- Köpes 5700/5800 x3d sökes
- Säljes SteelSeries Apex Pro Mini
- Köpes Hubb 1gbs 4 portar (Liten)
- Säljes DAN/Lian-Li A3 svart med träfront / Fractal S36V2
- Säljes Säljer diverse datorer, tillbehör och monitortillbehör
- Säljes Google Pixel 10 Pro 128GB Obsidian
- Säljes LG Oled65B7V , Nytt moderkort och nätdel, bytt panel.
- Säljes GeForce RTX2060, Intel core i3-10100F, Corsair kylare
- Köpes F1 2019, 2020, 21 (PS4, XB1)
- Windows 11 25H2 nära lansering24
- AMD utreder rapport om brända Ryzen 9950X30
- Systemkraven för Battlefield 6 presenterade45
- Lenovos handhållna Legion Go 2 kan avtäckas på IFA-mässan3
- ESET hittar skadeprogram som skriver sig självt33
- AMD går på djupet i RDNA 414
- Sapphires moderkort närmar sig lansering21
- Quiz: Vad kan du om gamingskärmar?73
- MSI: 533 dagar senare - knappt någon OLED-inbränning128
- Intels Nova Lake-S nära färdigställda35
Externa nyheter
Spelnyheter från FZ
