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

Själv skulle jag gissa att de där var felstavade och att det skulle stå "Created" och "Updated" - vilket dessutom är mer språkligt korrekt.
Att ha ett "D" suffix bara för att ange att det har något med datum eller tid att göra är ju helt onödigt - det kan man ju se direkt från typdeklarationen.

Där ser man, jag inbillade mig att det var någon liten grupp fantaster som hobbyprogrammerade i Erlang men att det i övrigt var ett dött språk. Men kul att ha fel i det sammanhanget.

WhatsApp har jag som huvudsaklig kanal för att hålla kontakt med mina söner och deras respektive.
Kivra får jag all mydighetspost och alla kvitton i.

Kanske ska jag pilla lite mer på Erlang om det blir tid till det.

Precis, jag var inne på det samma. Om man nu är allergisk mot ORMer så skulle jag ju använd tabell-schemat eller typspecifikationen, vilket håll man nu vill gå från, istället för en namnkonvention som garanterat inte kommer att testas om jag lärt känna @klk genom denna tråden

Har du utvecklat databaser med så många tabeller? Och programvaror som hanterar databaserna?

När man utvecklar mjukvara som hanterar databaser börjar man med att modellera applikationsprogrammet för sig och databasen för sig och vad gäller just databasen så skapar man (oftast) en grafisk modell i enlighet med någon känd grafisk notation. Jag brukar använda den som Elmasri & Navathe använder i sin bok "Fundamentals of database systems" med en liten skillnad för att modellen inte ska bli för plottrig. I sak är det en notation för "Entity-Relationship-modelling" som är ekvivalent med alla andra notationer (men i mina ögon enklare att följa).
Den modellen ligger sedan till grund för en överföring till en matematisk notation som sedan använda för att normalisera databasen inna man för över den slutliga strukturen till den deklarationsnotation du ger exempel på. Din deklaration av en tabell är alltså det sista steget för att skapa tabellerna i databasen.
Det är en formell metod som gör att det inte spelar någon större roll om det är tio eller tvåhundra tabeller i databasen. Ett litet exempel som jag använt i undervisning:
En databas över fastighetsbolag och deras hyreslägenheter (någonstans i Sverige)

Alla rektanglar bildar tabeller, alla streck med gaffel i båda ändar och alla streck som binder ihop fler än två rektanglar bildar också tabeller och alla streck med gaffel i ena änden kommer att ha en främmande nyckel i tabellen på gaffelsidan som refererar till en rad i tabellen som bildas av rektangeln på den sidan där det inte är en gaffel. Alla andra egenskaper finns i tabellform och både den tabellen och modellen ligger till grund för de deklarationer som skapar tabellerna i databasen. Räknar man lite grand kommer man fram till att databasen kommer att ha 23 tabeller.
Dessutom kommer man i reella fall inte skapa tabellerna förrän man räknat på alla de tabller man först får fram för att vara säker på att man minimerar redundans i databasen.

Nu är du ute och cyklar igen. Alla "fält" som du kallar dem är viktiga om du byggt din databas korrekt, annars har de inte i databasen att göra.

När du programmerar mot en databas, kontrollerar du alltid mot tabelldeklarationerna vilka typer som "fält"-namnen har eftersom du inte chansar på att den som implementerade databasen följer någon egenpåhittad norm.

jag skriver "fält" eftersom du kallar dem det, i tabellerna kallar man dem annars för kolumnnamn.

Kul och intressant. Jag behöver läsa på en del, verkar det som. Elixir ser jag kör på Erlangs VM men jag har ingen kunskap om Elixir annat att det är ett programspråk. Det lilla jag har läst hittills får mig att tro att det är en utveckling av Erlang med en mer lättillgänglig syntax och att rebar3 är byggverktyget för Erlang-kod

Ja, Scala propagerade min äldste son för, jag läste lite förstrött om språket men gjorde aldrig något mer än så. Kanske kollar....

PLT är ju intressant, höll på en del med lambdakalkyl en gång i tiden, halkade in på kombinatorisk logik men i o m att jag slutade hålla en kurs där det var relevant så slutade jag hålla på med det. Har fortfarande "The Lambda Calculus" av Barendregt i bokhyllan men den var svår. Föredrog "Lambda-Calculus and Combinators" av Hindley & Seldin (som också står i bokhyllan). Har inte underhållit de kunskaperna så de har säkert eroderat en hel del.

Med Speciellt angående APL avsåg jag att man åtminstone dåförtiden behövde specialtangentbord, gick i o f s att mappa om tangentbordet men det var knöligt. Vore kul att testa igen kanske.
Men nu när ni har väckt intresset igen blir det lite för mycket. Får ta det lite pö om pö...

Absolut, han hade helt rätt!

Sen var den minst lika viktiga insikten att för vissa fall, inklusive detta, får man nog acceptera "svengelska" då "överskuggning" inte är en nomenklatur speciellt många kommer känna igen.

Kör man med "override" och "overload" lär de flesta fatta även i ett svenskt kontext.

Kanske, verkar likna scheme, jag har ju jobbat med Lisp både som undervisningsspråk (scheme) och utvecklat ett objektsystem i Lisp. Det slog aldrig eftersom Dan Bobrow samma år presenterade CLOS (Common Lisp Object System) som en utvidgning av Common Lisp.
Det var ju mycket mer genomarbetat än mitt "hack" (och våldsamt mycket större). Häcklarna av CLOS kallade det för COLOSSAL, mest för att reta Dan, som var lite känd för häftigt humör. Testade aldrig CLOS, kanske bitter över mitt eget "nederlag". Det var ett kul hack, dock.

Men kanske testar clojure först. Vill dock att mitt "Flashcards" inte ska ta för lång tid att realisera i något språk. Har hjälpt mig mycket, ser ut så här:

och om man "fusktittar":

Inte mer än c:a 750 rader kod tack vare den eleganta strukturen hos PySimpleGUI (som alltså inte finns längre)

Det här var nog ditt värsta inlägg hittills och det gör att jag tror att vad du än var inblandad i i projektet du skrev om tidigare så var det definitivt inte databasen. Jag börjar mer och mer tro att du trollar, kanske sitter och fnittrar förtjust åt dina egna inlägg och tänker: "Där fick de något att kommentera, det här blir kul"

Den formella metoden jag delvis beskrev görs inte i ett steg, man gör en initial modell som man sedan itererar över tills man är nöjd, somliga använder metoden jag beskrev andra använder annan notation, inte nödvändigtvis grafisk.
När man så är nöjd, för man över databasen på en form som tillåter normalisering, man normaliserar och testar sedan. Kan databasstrukturen lagra alla data man behöver, kan alla frågor man vill ställla till den besvaras, är strukturen tillräckligt dynamisk för att kunna byggas ut?
Inte förrän man är nöjd bygger man databasen. Klart att det kan bli fel men de gånger jag har sett felbyggda databaser har det alltid varit databaser byggda av folk som inte har den formella utbildningen eller som bortsett från formalia för att de upplevt att de är duktiga nog för att kunna klara jobbet ändå.

Det här tror jag överhuvudtaget inte på. Det mest korkade jag någonsin hört i samband med databaser.
Resten av ditt inlägg bortser jag ifrån.

1.
Jag är inte irriterad bara trött på din fåniga inlägg, även det här är ett sammelsurium av påståenden som är svåra att bemöta för att de är så spretiga och delvis rejält korkade.
2.
De som designar databasen vet när de kan vara nöjda för att de har erfarenhet, är välutbildade, kan databasmatematiken, är noggranna och är medvetna om att kunden också måste vara nöjd.
3.
Jag behöver inte kolla Act!, de skulle inte vara kvar på marknaden om de gjorde som du skrev.
4.
Om du höll på med databaser innan relationsdatabaserna så är du minst lika gammal som jag (och jag är gammal). Codd skrev sitt första papper 1969, ett papper som fick hela branchen att haja till och 1970 publicerade han en forskningsrapport "A Relational Model of Data for Large Shared Data Banks". Strax därefter började det dyka upp databashanteringssystem på marknaden, runt 1974. Jag började jobba med relationsdatabaser 1982, ett svenskt databashanteringssystem som hette MIMER och som på den tiden programmerades i Fortran IV (det var inte kul). Sedan dess har jag jobbat med flera andra relationsdatabshanteringssystem: Oracle (som är långt ifrån så uselt som du påstod i ett tidigare inlägg), Ingres, Informix, DB2 (IBM), MySql, PostgreSQL och SQLite. Jag har också jobbat med andra typer av databaser men mest med relationsdatabaser.
5.
Jag har visst hört talas om att man kan koppla ihop data från olika tabeller med hjälp av värden i andra tabeller. Det är just sådana värden som definierar databasens semantik. I mitt exempel kommer t.ex. kopplingen "Kö" att bilda en tabell med (minst) fyra kolumner som kopplar ihop rader i tabellerna som bildas av de rektanglar den sammanbinder.
6.
Jag kommer från och med nu betrakta dig som troll och inte besvara dina inlägg. Det förekommer flera andra diskussioneer i tråden som är värda att lägga krutet på.

Någon annan som undrar om @klk ens arbetat med SQL efter att ha läst detta?

Jag har hört om att folk i Silicon valley microdoserat LSD men här misstänker jag macrodosering av LSD