C++ och dess framtid att programmera minnessäkert - Hur går utvecklingen?

Permalänk
Medlem
Skrivet av Dimman:

Har förstått att du är av den åsikten, men jag håller inte med rakt av. Jag har jobbat med flera av samma åsikt och har senare suttit och fått göra om deras lösningar för att de var suboptimala i grunden, trots att jag inte själv skrivit så värst mycket kod de senaste åren. Kod är bara en implementation av en lösning, har man ingen bra lösning så hjälper det inte hur duktig man än är i valfritt språk.

Jämför det lite med en snickare, de kan vara hur skillade som helst med alla verktyg men om ritningen/planlösningen/rördragning/eldragning/whatever är kass så kan du bygga det hur perfekt du vill; slutresultatet blir inte bra.

Angående arkitektur, kan jag klistra in det här exemplet på en tabell i databas. Vet du hur många utvecklare som säger "men så där kan du inte göra" och säger de så för att de vet eller vet de inte?

CREATE TABLE application.TUser ( UserK INT IDENTITY(1,1) NOT NULL ,UserGroupK INT ,GlobalK INT NOT NULL ,CustomerK BIGINT ,CreateD DATETIME ,UpdateD DATETIME ,AuthorityS INT -- rights for this user ,RoleC INT ,FId INT ,FAlias NVARCHAR(100) ,FLoginName NVARCHAR(100) ,FDisplayName NVARCHAR(100) ,FFirstName NVARCHAR(100) ,FLastName NVARCHAR(100) ,FDescription NVARCHAR(1000) ,FMail NVARCHAR(200) ,FMobile NVARCHAR(100) ,FLoginD DATETIME ,FLoginCount INT ,FProfile VARCHAR(100) ,FIdle SMALLINT DEFAULT 0 ,FDeleted SMALLINT DEFAULT 0 ,FPassword VARCHAR(256) ,FLastLoginD DATETIME ,FLastIp NVARCHAR(100) );

Permalänk
Medlem
Skrivet av klk:

Fråga: När tog det fart, och jag är medveten om att embedded idag inte är som det var för en hel del år sedan. Att det idag är nästan som vilken programmering som helst

Du vet väldigt mycket för att veta väldigt lite. Embedded har i stora drag sett likadant ut de senaste 15-20 åren, åtminstone.

Visa signatur

Citera mig för svar.
Arch Linux

Permalänk
Medlem
Skrivet av klk:

Fråga: När tog det fart, och jag är medveten om att embedded idag inte är som det var för en hel del år sedan. Att det idag är nästan som vilken programmering som helst

Vad tog fart? Har väl varit igång sedan vi satt folk på månen eller jag kanske har fel?

Idag så lever ju mycket av embedded kodningen framförallt embedded Linux i ett gränsland där det är svårt att urskilja det från en gammal desktop. Det finns ju fortfarande en hel del som kör på mindre system som är baremetal eller använder RTOS. Oavsett så kräver det fortfarande en del eftertänksamhet för att hantera systembegränsningar(låg bandbredd, skrivningar, CPU/minnesanvändning, energieffektivitet osv).

Permalänk
Medlem
Skrivet av huttala:

Erlang communityn lever, men är liten. Och det är fintechs och andra bolag som behöver extrem skalning som fortfarande använder erlang. Whatsapp, Discord, Klarna, Nordnet och Kivra är några bolag jag kommer på såhär på rak arm som kör erlang(och elixir).

Kan lägga till LoL's meddelandesystem, RabbitMQ, Cisco(uppskattade att 90% av världens internettrafik passerar en BEAM-nod), Bet365.

Permalänk
Tangentbordskonnässör
Skrivet av klk:

Angående arkitektur, kan jag klistra in det här exemplet på en tabell i databas. Vet du hur många utvecklare som säger "men så där kan du inte göra" och säger de så för att de vet eller vet de inte?

CREATE TABLE application.TUser ( UserK INT IDENTITY(1,1) NOT NULL ,UserGroupK INT ,GlobalK INT NOT NULL ,CustomerK BIGINT ,CreateD DATETIME ,UpdateD DATETIME ,AuthorityS INT -- rights for this user ,RoleC INT ,FId INT ,FAlias NVARCHAR(100) ,FLoginName NVARCHAR(100) ,FDisplayName NVARCHAR(100) ,FFirstName NVARCHAR(100) ,FLastName NVARCHAR(100) ,FDescription NVARCHAR(1000) ,FMail NVARCHAR(200) ,FMobile NVARCHAR(100) ,FLoginD DATETIME ,FLoginCount INT ,FProfile VARCHAR(100) ,FIdle SMALLINT DEFAULT 0 ,FDeleted SMALLINT DEFAULT 0 ,FPassword VARCHAR(256) ,FLastLoginD DATETIME ,FLastIp NVARCHAR(100) );

Vad är grejen med alla kryptiska namn? Varför skriver du inte vad kolumnerna fakiskt ska representera?
Jag kan nog gissa mig fram till vad allt betyder, men det ska jag inte behöva göra.

Permalänk
Medlem
Skrivet av Dimman:

Du vet väldigt mycket för att veta väldigt lite. Embedded har i stora drag sett likadant ut de senaste 15-20 åren, åtminstone.

Vad är det för processorer du jobbar mot och hur ser de bästa processorerna ut i branchen

Stämmer att embedded inte är något jag grävt i

Permalänk
Tangentbordskonnässör
Skrivet av orp:

Kan lägga till LoL's meddelandesystem, RabbitMQ, Cisco(uppskattade att 90% av världens internettrafik passerar en BEAM-nod), Bet365.

Haha, ja.. just.. Den lilla detaljen att (typ) hela internet kör på Erlang glömde jag nämna (vilket tillsammans med whatsapp var anledningen till att jag börja leka runt i språket).

Permalänk
Medlem
Skrivet av klk:

Ibland pratar man om 10x programmerare, tror du det existerar och om det gör det vad är det med utvecklare som gör att de är 10x?
Vad kan en 10x utvecklare som inte "vanliga" utvecklare kan

??? 10x-utvecklare är, vad jag förstår, bara larv ???

Varför skulle det finnas de som är 10 gånger duktigare än alla andra?
Kanske de finns men i så fall (för att travestera Fermi) var är de?

Visa signatur

Debian, bara Debian

Permalänk
Medlem
Skrivet av huttala:

Vad är grejen med alla kryptiska namn? Varför skriver du inte vad kolumnerna fakiskt ska representera?
Jag kan nog gissa mig fram till vad allt betyder, men det ska jag inte behöva göra.

Om en utvecklare är van att skriva kod utan extra ramverk eller hantera mycket stora databaser så fattar man direkt för har tidigare nämnt hur viktigt mönster är när något växer.

För en utvecklare är vissa fält i databasen viktiga, utvecklaren är mindre intresserad av fält som har användardata. Genom att benämna fälten så som exemplet visar kan utvecklaren direkt se vilka utvecklaren skall fokusera på. Och det går också ganska lätt att skriva generell kod endast genom att anpassa kod efter fältnamn.

Sådana här "småsaker" får enorm betydelse om man vill ha smidigare kod

Permalänk
Medlem
Skrivet av klk:

Angående arkitektur, kan jag klistra in det här exemplet på en tabell i databas. Vet du hur många utvecklare som säger "men så där kan du inte göra" och säger de så för att de vet eller vet de inte?

CREATE TABLE application.TUser ( UserK INT IDENTITY(1,1) NOT NULL ,UserGroupK INT ,GlobalK INT NOT NULL ,CustomerK BIGINT ,CreateD DATETIME ,UpdateD DATETIME ,AuthorityS INT -- rights for this user ,RoleC INT ,FId INT ,FAlias NVARCHAR(100) ,FLoginName NVARCHAR(100) ,FDisplayName NVARCHAR(100) ,FFirstName NVARCHAR(100) ,FLastName NVARCHAR(100) ,FDescription NVARCHAR(1000) ,FMail NVARCHAR(200) ,FMobile NVARCHAR(100) ,FLoginD DATETIME ,FLoginCount INT ,FProfile VARCHAR(100) ,FIdle SMALLINT DEFAULT 0 ,FDeleted SMALLINT DEFAULT 0 ,FPassword VARCHAR(256) ,FLastLoginD DATETIME ,FLastIp NVARCHAR(100) );

Nu är jag ingen expert på databaser, men det ser ut som en implementationsteknisk detalj. Helt omöjligt att veta vad det är till för produkt/lösning och vad det finns för krav på den. Det var lite av min poäng tidigare, men jag misstänker att vi inte kommer komma närmre ett konsensus med fler meningar här.

Visa signatur

Citera mig för svar.
Arch Linux

Permalänk
Medlem
Skrivet av klk:

Vad är det för processorer du jobbar mot och hur ser de bästa processorerna ut i branchen

Stämmer att embedded inte är något jag grävt i

Just nu jobbar jag för Arm på Arm mot Arm, så är kanske lite partisk i frågan.

Visa signatur

Citera mig för svar.
Arch Linux

Permalänk
Medlem
Skrivet av Dimman:

Nu är jag ingen expert på databaser, men det ser ut som en implementationsteknisk detalj. Helt omöjligt att veta vad det är till för produkt/lösning och vad det finns för krav på den. Det var lite av min poäng tidigare, men jag misstänker att vi inte kommer komma närmre ett konsensus med fler meningar här.

Inget krav utan ett exempel på arkitektur, hur en liten sak kan spela mycket stor roll för hur "lätt" databasen blir att jobba mot för utvecklare.

Låt säga att en databas kommer innehålla 200 tabeller eller mer, med "läsbara" namn har troligen det teamet knappt kommit till 50-60 tabeller innan de gått in i väggen, medan de som tänkt till för att klara förstå databasen kan öka på ordentligt

Permalänk
Medlem
Skrivet av klk:

Inget krav utan ett exempel på arkitektur, hur en liten sak kan spela mycket stor roll för hur "lätt" databasen blir att jobba mot för utvecklare.

Låt säga att en databas kommer innehålla 200 tabeller eller mer, med "läsbara" namn har troligen det teamet knappt kommit till 50-60 tabeller innan de gått in i väggen, medan de som tänkt till för att klara förstå databasen kan öka på ordentligt

Dvs en implementationsteknisk detalj.

Visa signatur

Citera mig för svar.
Arch Linux

Permalänk
Medlem
Skrivet av Dimman:

Dvs en implementationsteknisk detalj.

Kalla det vad du vill. Det påverkar slutresultatet ordentligt

Permalänk
Tangentbordskonnässör
Skrivet av klk:

Om en utvecklare är van att skriva kod utan extra ramverk eller hantera mycket stora databaser så fattar man direkt för har tidigare nämnt hur viktigt mönster är när något växer.

För en utvecklare är vissa fält i databasen viktiga, utvecklaren är mindre intresserad av fält som har användardata. Genom att benämna fälten så som exemplet visar kan utvecklaren direkt se vilka utvecklaren skall fokusera på. Och det går också ganska lätt att skriva generell kod endast genom att anpassa kod efter fältnamn.

Sådana här "småsaker" får enorm betydelse om man vill ha smidigare kod

Ja, fast ditt exempel är ett anti pattern och visar hur man inte ska göra i stora projekt.

Permalänk
Medlem
Skrivet av klk:

Om en utvecklare är van att skriva kod utan extra ramverk eller hantera mycket stora databaser så fattar man direkt för har tidigare nämnt hur viktigt mönster är när något växer.

Nu snackar du goja igen... Vad har extra ramverk och mycket stora databaser att göra med frågan kring märklig namngivning?

Jag fattar vad där står men på alla bolag jag jobbar så och open-source-projekt som jag kollat så namnger man aldrig exempelvis "CreateD" eller "UpdateD" utan "CreatedAt", "UpdatedAt". Vill man göra det det svårt för sig så kan du base64 encode:a kolumnnamnen också.

Kan ju tipsa om att Postgres nya UUID har inbakad timestamp så då slipper man ha CreateD.

Skrivet av klk:

För en utvecklare är vissa fält i databasen viktiga, utvecklaren är mindre intresserad av fält som har användardata. Genom att benämna fälten så som exemplet visar kan utvecklaren direkt se vilka utvecklaren skall fokusera på. Och det går också ganska lätt att skriva generell kod endast genom att anpassa kod efter fältnamn.

Sådana här "småsaker" får enorm betydelse om man vill ha smidigare kod

Om det finns sådana use-case varför inte dela på datan istället för att en namnkonvention för kolumner?

Permalänk
Medlem
Skrivet av orp:

Nu snackar du goja igen... Vad har extra ramverk och mycket stora databaser att göra med frågan kring märklig namngivning?

Jag fattar vad där står men på alla bolag jag jobbar så och open-source-projekt som jag kollat så namnger man aldrig exempelvis "CreateD" eller "UpdateD" utan "CreatedAt", "UpdatedAt". Vill man göra det det svårt för sig så kan du base64 encode:a kolumnnamnen också.

Om du är van utvecklare vet du direkt vad som går att göra baserat på vad det är för data du jobbar mot
"CreateD" eller "UpdateD" = Lätt

"CreatedAt", "UpdatedAt" = inte så lätt och kommer ta längre tid

Permalänk
Medlem
Skrivet av klk:

Om du är van utvecklare vet du direkt vad som går att göra baserat på vad det är för data du jobbar mot
"CreateD" eller "UpdateD" = Lätt

"CreatedAt", "UpdatedAt" = inte så lätt och kommer ta längre tid

Om du är van utvecklare så spelar inte detta någon märkbar roll mer än att den ena är mer språkligt korrekt

Permalänk
Medlem
Skrivet av orp:

Om du är van utvecklare så spelar inte detta någon märkbar roll mer än att den ena är mer språkligt korrekt

Om du tar mitt första exempel, jag kan med en enda metod lista ut vad varje fält är för något för att det skall fungera och skriva kod mot det fältet.

Alla fält som börjar på "F" är användardata, inte viktiga (plocka bort)
Resten av fälten kollar jag sista bokstaven och är stor för att få något unikt. Vips vet jag allt

Det är också sådant här som skiljer "vanliga" utvecklare mot 10x utvecklare

Din lösning där det är mänskligt läsbara namn, du kommer få skriva mycket mer kod för att hantera databasen

Permalänk
Medlem
Skrivet av klk:

Om du tar mitt första exempel, jag kan med en enda metod lista ut vad varje fält är för något för att det skall fungera och skriva kod mot det fältet.

Hur fungerar en ORM utan din namnkonvention?

Skrivet av klk:

Alla fält som börjar på "F" är användardata, inte viktiga (plocka bort)
Resten av fälten kollar jag sista bokstaven och är stor för att få något unikt. Vips vet jag allt

Varför inte bara lägga användardatan i en egen tabell?

Skrivet av klk:

Det är också sådant här som skiljer "vanliga" utvecklare mot 10x utvecklare

Jag klassar inte dålig databasdesign som 10x

Permalänk
Medlem
Skrivet av orp:

Hur fungerar en ORM utan din namnkonvention?

ORM använder du om du inte kan programmera

Permalänk
Medlem
Skrivet av klk:

ORM använder du om du inte kan programmera

Nu säger du uppenbart korkade saker igen...

ORM använder man om man inte vill uppfinna hjulet igen. Det du beskrev lät som en kass ORM som är beroende av namnkonvention.

Varför är en ORM ett tecken på att man inte kan programmera? Du använder ju boost och C++ standard lib, kan du inte programmera eller varför använder du det?

Permalänk
Medlem
Skrivet av orp:

Nu säger du uppenbart korkade saker igen...

ORM använder man om man inte vill uppfinna hjulet igen. Det du beskrev lät som en kass ORM som är beroende av namnkonvention.

Du vinner inget på det, endast extra beroende

Permalänk
Medlem
Skrivet av klk:

Du vinner inget på det, endast extra beroende

Du vinner ju inget på boost eller C++ standard lib endast extra beroende...

Du drog säkert gränsen vid ORM eftersom du nu skrivit något liknande och är stolt.

Du tyckte uppenbarligen inte att det var så viktigt att återanvända kod som du tidigare påstått.

Permalänk
Medlem
Skrivet av klk:

Om du tar mitt första exempel, jag kan med en enda metod lista ut vad varje fält är för något för att det skall fungera och skriva kod mot det fältet.

Alla fält som börjar på "F" är användardata, inte viktiga (plocka bort)

Det vet du bara för att du vet hur du har valt att namnge dem så.
För resten av världen så är det ingen som så där omedelbart begriper att ett "F" prefix indikerar användardata. Och om man väl lyckas lista ut det, så undrar alla varför i all världen någon skulle vilja välja ett så kryptiskt sätt att markera den saken.

Permalänk
Medlem
Skrivet av klk:


Alla fält som börjar på "F" är användardata, inte viktiga (plocka bort)
Resten av fälten kollar jag sista bokstaven och är stor för att få något unikt. Vips vet jag allt

Haha förlåt men F som i användardata förde genast tankarna till klassikern ”F som i ordblind” 😅

Visa signatur

Citera mig för svar.
Arch Linux

Permalänk
Tangentbordskonnässör
Skrivet av klk:

Om du tar mitt första exempel, jag kan med en enda metod lista ut vad varje fält är för något för att det skall fungera och skriva kod mot det fältet.

Alla fält som börjar på "F" är användardata, inte viktiga (plocka bort)
Resten av fälten kollar jag sista bokstaven och är stor för att få något unikt. Vips vet jag allt

Det är också sådant här som skiljer "vanliga" utvecklare mot 10x utvecklare

Din lösning där det är mänskligt läsbara namn, du kommer få skriva mycket mer kod för att hantera databasen

Alla fält som börjar med F ska alltså vara i en egen tabell och lazy loadas när de faktiskt behövs.
Och vipps så har du sparat performance genom att bara ladda den onödiga datan när den faktiskt behövs, och bättre läsbarhet i och med att du bara har en foreign key istället för en massa cols.

Permalänk
Medlem
Skrivet av klk:

*jösses*

Det där måste vara någon form av rekord

Knappast. Fler språk än genomsnittet är det nog, men de flesta duktiga programmerare har lärt sig och använt åtminstone ett dussin olika programmeringsspråk genom åren, även om man kanske inte är expert på alla av dem.

Permalänk
Medlem
Skrivet av klk:

Det är en fördom jag har
För om jag tar embedded utvecklare borträknat de senaste 5 åren så är det här en lite speciell kategori personer. Det är inte förrän först nu på senare tid processorerna och operativsystemen i embedded börjar likna normala datorer.

... ungdomen nu för tiden! På min tid, då ....

När jag började med programmering så var det inte heller så stor skillnad mellan embedded och "normala" datorer.
Men det var för att persondatorerna på den tiden var så pass primitiva. 8-bitars processorer, minimalt "operativsystem", och skulle man göra något mer avancerat var man tvungen att arbeta direkt mot hårdvaran. Dvs, samma som i små inbyggda system då och nu.

Permalänk
Medlem

Jag tror jag börjar förstå vad som menas med 10x-utvecklare nu, det är de som producerar kod som tar 10x så lång tid för alla andra att läsa och förstå och kostar 10x så mycket att underhålla och vidareutveckla...

Visa signatur

Dator: [i5 750 @ 3.6 GHz] [Asus P7P55D Pro] [2x2 GB Corsair Dominator] [Evga GTX 460 SC SLI] [WD Caviar Black 640 GB + 2.5 TB Lagring] [Corsair TX750W] [Corsair Obsidian 800D] [3x Benq 2420HDBE]
Vattenkylning: [EK Supreme HF] [2x EK VGA Supreme HF] [EK DCP 4.0] [EK 250ml Res] [XSPC RX360]