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

Permalänk
Medlem
Skrivet av klk:

Programmering är inte att lära sig språk, programmering är att hantera kod. Språket är ett av alla verktyg utvecklaren använder.

Man kan lära sig ett språk som python, javascript, C#, java men det är inte samma sak som att man lärt sig programmera.

Tror det är det vanliga, när skolan började lära ut "programmering" (läs: språk, inte programmering) förstörde de mer än vad de tillförde. Dels klarar inte skolan att locka till sig duktiga utvecklare, pojkens lärare är bedrövlig, han kan inte alls. Eleverna får rätta honom och det är visserligen bra men att en skolan kan sätta en så okunnig person i ämnet att lära ut förstår jag inte.

Exempel (för att få förståelse på lärarens nivå): De skulle göra loopar, då lärde läraren bara ut "while" lopar för han hade inte lärt sig hur man gjorde lopar med "for".

Lär sig någon hantera språk är det inga problem att gå in på nya språk, bara olika syntax för samma sak. Det svåra med "nya" språk handlar oftast mer om vad som följer med i språket. T.ex C#, inte C# som är tar tid utan .NET, Java är det inte språket som är svårt utan runtime biblioteket. JavaScript är det inte språket som är svårt utan det som måste läras upp är hur en browser fungerar (om det är för webutveckling).
Förutom att lära sig vad som följer med behöver man lära sig hur hantering av komponenter och annat fungerar. Hur saker byggs, installeras och så vidare.

Så orsakerna till att jag tycker C i kombination med JavaScript är en bra kombo beror på att C lär ut hårdvara, hur en dator fungerar och att man kan göra i allt med spartanska språk, att exempelvis C++ eller andra språk med smartare syntax mest är syntaktiskt socker.
JavaScript för att skriva bra kod (undvika spagetti mm).

Störst problem med lite svårare språk vad jag upplevt är att det tar tid innan eleven kan göra något, yngre vill snabbt se resultat om de inte skall tröttna.

Att just din son har en enligt dig bedrövlig lärare är en sak och trist naturligtvis men de flesta datalärare som jag stött på är duktiga och de lär ut programmering, att tänka som en utvecklare, inte programspråk i sig, naturligtvis med ett programspråk som hjälpmedel men det viktigaste är att de lär ut just programmering. Hur tänker man som programmerare, hur strukturerar man, hur delar man upp, oftast med en top-down teknik. En enkel while- eller for-loop är bara detaljer i kod, det är det strukturerade tänket man är ute efter.

Jag stötte ihop med en lärare på Stockholms universitet som visade sig vara en tidigare student på en kurs i grundläggande programmering som jag höll på KTH och på den tiden använde Scheme som förstaspråk med Abelsons & Sussmans bok "Structure and Interpretation of Computer Programs". Jag frågade honom vad han hade med sig från den kursen och svaret var intressant.

"Jag har aldrig använt Scheme efter kursen men tänket. Du sa alltid saker som: 'Tänk brett, tänk fritt, tänk vilt, tänk utanför boxen, tänk i rekursiva mönster'. Jag lärde mig att tänka som en programmerare och det har jag haft nytta av inte bara när jag programmerat utan även när jag undervisat i matte och fysik. Vi lärde oss hur man närmar sig ett problem, hur man avgränsar det, hur man bryter ner det, hur man letar efter lösningsmetoder, hur man hittar mönster och hur man utnyttjar dem. Det har jag med mig och det har jag haft en enorm nytta av."

Detaljerna i koden får man naturligtvis från det valda programspråket men det är just bara detaljer och syntax, det är tänket som betyder något.

Permalänk
Medlem
Skrivet av klk:

Fråga: Hur skiljer det sig och varför skiljer det sig om det är möjligt att beskriva?

Det skiljer sig genom att olika språk har olika egenskaper, olika operatorer och stödjer olika programmeringsparadigmer.
Det som t.ex. i C och andra språk utförs genom en for- eller while-loop, utför man i funktionella språk med rekursion och om språket har stöd för svansrekursion använder man helst det eftersom det är minnesbesparande (och snabbt).
Det skiljer sig också genom att man i vissa språk kan använda objektorienterade konstruktioner medan man i andra språk inte har tillgång till det.
Vi fejkade i o f s objektorientering i både Lisp och C när Simula med sitt klassbegrepp blev poppis på 80-talet men det var definitivt enklare med Simula som hade det inbyggt i språket. Simula kom redan 1967 men det dröjde innan "alla" insåg potentialen med OOP.
Och trots att man i Smalltalk renodlade Simulas objektbegrepp blev det rejält annorlunda att programmera Smalltalk jämför med Simula som förutom klassbegreppet syntaktiskt byggde på Algol-60 och Algol-68.
Så många olika saker gör att programmeringen skiljer sig mellan olika språk även om problemdomänen och tänket är detsamma.
Ser att @Orp och @Yoshman svarat och håller med dem båda.

Inkluderade Yoshman
Permalänk
Medlem
Skrivet av klk:

...
11 stycken metoder såg ut så här
En refaktorering gjordes och efter den (som inte är helt klar) ser metoderna ut så här

Citat:

1. PrepareEmptyXml_s
2. PrepareXml_s
3. XML_AppendEntry_s
4. XML_EntryExists_s
5. XML_ReadFile_s
6. XML_ReadFile_s (overload)
7. CreateTable_s
8. FilePath
9. DATE_CurrentTime_s
10. GetHistoryPath_s
11. CurrentDirectory_s

C kodare känner säkert igen en del av tekniken ...

Från någon som jobbat med främst embedded i C senaste 15 åren så är det ovan farligt nära hjärnblödning.

Visa signatur

Citera mig för svar.
Arch Linux

Permalänk
Medlem
Skrivet av klk:

Området är gigantiskt så svårt att svara kort

Kort förklaring:
När kod skrivs skall man ALLTID (enligt mig) skriva kod som om man vet att den kommer skrivas om. Default läge är att skriva så för då blir det oftast mest rätt. Hur sådan kod skrivs beror på många saker och var i koden logiken befinner sig, vilken logik som hanteras mm.

Om det är arbetskrävande och ändra i kod har man troligen problem i arkitekturen (hur vanlig som helst). Saker som teknisk skuld (beroenden), "coupling" eller något annat.
Mängden energi för mig att förhindra svårigheter att ändra i kod för mig överstiger allt annat. Låt säga att jag fått en större uppgift, kanske en månads jobb. Nästan all tid av det spenderas på hur det skall skrivas så det blir flexibelt och lätt att byta ut. Vet jag det går resten oftast ganska snabbt.

Vad som tar tid är ofta att undersöka annan kod där det skall användas, hur man kan koppla samman och vad de har för krav, andra eventuella problem.
Bland det svåraste som finns är att lägga till logik i annan kod som är dåligt skriven och som används. Dels måste ny kod "fungera" och det kan vara svårt att skriva om större bitar, det behöver delas upp i delar. Kan exempelvis innebära att en omskrivning görs i flera omgångar. Görs det i omgångar är det dubbel logik så ett tag är koden svårare än den var innan.

Oj! Jag skriver kod med tanken fixerad på vad det är för problem jag har att lösa och vad som förväntas vara resultatet av att köra min kod och om det är i ett större projekt förutsätter jag att de andra levererar vad de blivit satta att leverera. Jag ändrar aldrig i annans kod annat än på direkt uppmaning, t.ex. att någon har en bug de inte hittar och vill ha hjälp. Man måste lita på att andra levererar, måste i alla fall kunna lita på det.

Permalänk
Medlem
Skrivet av Dimman:

Från någon som jobbat med främst embedded i C senaste 15 åren så är det ovan farligt nära hjärnblödning.

In i Dimman så att säga? (pun intended)

PS. Håller med. DS.

Permalänk
Medlem
Skrivet av Dimman:

Från någon som jobbat med främst embedded i C senaste 15 åren så är det ovan farligt nära hjärnblödning.

Kan du utveckla?

Har du jobbat i "embedded i C senaste 15 åren" kanske ni inte är så vana att testa olika tekniker

Permalänk
Medlem
Skrivet av serafim:

In i Dimman så att säga? (pun intended)

PS. Håller med. DS.

Varför håller du med? Hur mycket olika tekniker har du testat att skriva kod för du nämnde just att du aldrig ändrar i andras kod, att du förväntar dig att andras kod skall fungera och så vidare. Vad är det för team du jobbat i

Permalänk
Medlem
Skrivet av serafim:

Detaljerna i koden får man naturligtvis från det valda programspråket men det är just bara detaljer och syntax, det är tänket som betyder något.

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

Permalänk
Medlem
Skrivet av Yoshman:

Om det bara var en träningssak, hur kommer det sig att Microsoft, Google, Facebook, Apple, m.fl. nu har "war-stories" där de flyttat projekt från C och C++ till "minnessäkra språk" och sett hur den typen av problem nästan helt försvinner?

Ja varför tror jag det, är inte det uppenbart varför

Så stora bolag har mycket svårt att få tag på komptens. Och varje utvecklare på de här företagen brukar normalt inte producera speciellt mycket kod. De kanske möjligen har special team där utvecklare får mer frihet men generellt så måste de anpassa sig efter vad de kan få tag på.

Permalänk
Medlem
Skrivet av klk:

Har du jobbat i "embedded i C senaste 15 åren" kanske ni inte är så vana att testa olika tekniker

Det beror nog lite på vad man menar med olika tekniker, men nej generellt inom embedded så håller vi oss mestadels till gammalt beprövat som fungerar och är effektivt. Man kan väl säga att det finns fler lösningar än vad det finns problem generellt, i min uppfattning. Brukar hålla oss till KISS-principen med insikten också att den bästa tekniska lösningen inte alltid är den bästa lösningen.

Skrivet av klk:

Kan du utveckla?

Behövs det? Bara snabbt:

_s? Really?
"prepare", prepare för vad? Varför skulle man vilja ha olika funktioner för en tom xml eller ej...
XML/Xml, bestäm dig
...Xml/XML_... really
CreateTable .. var? vad är kontexten?
FilePath .. Är det en setter eller getter? båda? Du har en Get-funktion längre ner för ""GetHistoryPath"
CurrentDirectory .. gissar att det är en getter, inkonsekvent igen i namngivningen
DATE_CurrentTime .. Mhm, här var vi ett prefix igen, men det har vi inte ovan.. set/get?

EntryExists låter mer som en static helper till typ insert/remove, vill man ha nått sånt i API:et och förenkla så borde en Get kunna agera dubbelt

Fullständigt inkonsekvent och dåligt namngivet.

Visa signatur

Citera mig för svar.
Arch Linux

Permalänk
Datavetare
Skrivet av klk:

Ja varför tror jag det, är inte det uppenbart varför

Så stora bolag har mycket svårt att få tag på komptens. Och varje utvecklare på de här företagen brukar normalt inte producera speciellt mycket kod. De kanske möjligen har special team där utvecklare får mer frihet men generellt så måste de anpassa sig efter vad de kan få tag på.

Rätt säker på att du inte har en aning om genomsnittlig kompetens hos dessa. Både Google och Meta har väldigt höga löner för programmerare, runt 350k USD i median. Ovanpå det har båda väldigt stor påverkan på saker som C++ ISO standarden.

Och även om du var helt spot on så ändrar det inte på faktum att C och C++ i så fall är så hopplösa att använda på rätt sätt att de ändå inte borde används. Vilket i.o.f.s. är lite det som hänt, de används idag främst för att man av någon anledning måste, inte för att det vore ett bra val idag.

Skrivet av klk:

Kan du utveckla?

Har du jobbat i "embedded i C senaste 15 åren" kanske ni inte är så vana att testa olika tekniker

Säger den som programmerar C++98 och prestanda-optimerar som det vore 1993

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av klk:

...
Så stora bolag har mycket svårt att få tag på komptens. Och varje utvecklare på de här företagen brukar normalt inte producera speciellt mycket kod. ...

Det är ett typiskt nybörjarmisstag (även på managernivå) att försöka mäta kvalitet i antal rader kod. Det finns nästan aldrig något egenvärde i "mycket kod". Riktigt duktiga ingenjörer förstår problematiken på en högre nivå och löser problemen på enklaste och effektivaste sätt, det innebär sällan mer kod. Snarare tvärtom.

Visa signatur

Citera mig för svar.
Arch Linux

Permalänk
Medlem
Skrivet av Dimman:

Det är ett typiskt nybörjarmisstag (även på managernivå) att försöka mäta kvalitet i antal rader kod. Det finns nästan aldrig något egenvärde i "mycket kod". Riktigt duktiga ingenjörer förstår problematiken på en högre nivå och löser problemen på enklaste och effektivaste sätt, det innebär sällan mer kod. Snarare tvärtom.

Så kan det säkert vara, dock så av de jag träffat som varit riktigt duktiga har de alla varit "skapare". De trivs inte om de inte får skapa och man får inte träna sig om man inte skriver mycket kod. Oavsett om koden blir använd eller inte. Om de inte producerar kod på jobbet så har de suttit hemma.

De jag känt som jobbat på Microsoft var har inte varit imponerade, kan bero på vart för det är som sagt gigantiskt företag och finns andra områden där stjärnorna sitter.

Här i Sverige jobbade jag under 3 års tid väldigt nära dem eftersom vi utvecklade ett CRM system som var anpassat för att köra mot deras inköpta MS SQL Server och det var en en strategiskt viktig produkt för Microsoft. Fick de in databasen på stora företag och företaget lärde sig databasen fortsatte de och bygga system på databasen och sedan satt de fast Microsoft hjälpte till (med allt) för att det var nog mer lönsamt för dem än för oss om vi sålde.

CRM systemet vi skrev (gjorde backenden bl.a.) slog det mesta och hade några saker de andra CRM företagen saknade (replikering bl.a.)

Microsoft köpte (delade, forkade) databasen (hela produkten) från Sybase för tror inte de själva hade klarat av att skriva en egen databas, gissningsvis köpte de med sig programmerarna

Permalänk
Medlem
Skrivet av klk:

Varför håller du med? Hur mycket olika tekniker har du testat att skriva kod för du nämnde just att du aldrig ändrar i andras kod, att du förväntar dig att andras kod skall fungera och så vidare. Vad är det för team du jobbat i

Jag har jobbat med en mängd olika saker, bland annat i flera större utvecklingsprojekt och med utbildning, är ursprungligen matematiker men har jobbat mest med programmering och utbildning. Jag har programmerat i ett stort antal språk, bl. a.
Ada, Algol60 (inte mycket), Algol68 (inte mycket), APL, Assembly (ASM), Basic (usch!), BETA, C, C++, C# (inte mycket), Caml, CLP(R), COBOL (värsta språket någonsin), Common Lisp, Delphi, ECMAScript, Eiffel (bara tester inga stora grejer), Erlang, Forth, Fortran, Go, Groovy, Haskell, HTML, Informix-4GL, Java, JavaScript, LaTeX, LISP, Maple, MATLAB, Miranda, ML, Modula, Modula-2, Modula-3, Napier88 (bara tester och en del lek), OCaml, Octave, Oberon, Object Pascal, Objective-C, Oz, PHP, PL/I, Pascal, Perl, Pizza (intressant men inte mycket), PostScript, Prolog, Python, R, Ruby, Self, SQL, Scheme, Simula, Smalltalk, SQL, Tcl, TECO (kul men jobbigt, inga projekt), XML, XPath, XSLT.

Där det står "inte mycket" så har jag bara testat men inte åstadkommit något rejält, en hel del experimentella språk har jag också testat men minns inte vad de hette. Kan nog hitta mer eftersom jag sparat det mesta inklusive all mail-konversation, totalt c:a 27 TB som numera komprimerats till ynka 6 TB, vill inte gärna packa upp det och kommer nog slänga det mesta snart.

Några har jag nog glömt att nämna och om jag ska vara ärlig har jag nog glömt en hel del av de här språken men skulle tro att med en snabb uppfräschning kan jag vara igång igen. Några språk kommer jag inte programmera i igen:
TECO, Algol60, Algol68, BETA, CLP(R), Forth, Napier88 är väl ingen som använder längre.
APL, Modula (alla varianter), Pizza är väl också helt ute numera och APL har jag inte stött på de senaste 25 åren. Väldigt speciellt språk...
COBOL kommer jag vägra oavsett betalning, historiens värsta programspråk.
Oz var kul men inget jag gjort något allvarligt i.
Matematisk programvara som Maple, MATLAB och Octave har jag inte använt i kommersiella projekt, bara som verktyg på någon kurs
Prolog var intressant och användes i ett par databascentrerade projekt men kommer jag nog inte göra mer i.

De jag gjort mest i är Java, Groovy, Javascript (olika varianter och derivat), SQL, PHP, C och Python. Groovy var trevligt att jobba med.
LaTeX använde jag för all dokumentation och allt kursmaterial (fenomenalt för att skriva matematiska formler och ekvationer och snyggt blir det). Var p.g.a. mina kunskaper t.o.m. s.k. TeX-master på KTH under en kort period, den som servar alla med TeX- och LaTeX-mallar och underhåller de mallar som frekvent användes på KTH.

Efter allt prat (b.l.a. här) ska jag testa Rust, det har inte blivit mer än ett par små tester som inte gav mersmak men, vem vet, kanske ökar aptiten med lite träning. C/C++ har jag tröttnat på, alldeles för bökigt och alldeles för många standarder som gör att jag måste ändra en del i redan skrivna program då jag uppgraderar gcc.
En del bibliotek i Python, speciellt på UI-ramverkssidan, har gått ur tiden så en hel del programvaror måste antingen skrivas om eller så måste jag hitta gamla versioner av bibliotek.

Tänkte hålla det här kort men det blev en hel del text ändå...

Permalänk
Medlem
Skrivet av klk:

Så kan det säkert vara, dock så av de jag träffat som varit riktigt duktiga har de alla varit "skapare". De trivs inte om de inte får skapa och man får inte träna sig om man inte skriver mycket kod. Oavsett om koden blir använd eller inte. Om de inte producerar kod på jobbet så har de suttit hemma.

De jag känt som jobbat på Microsoft var har inte varit imponerade, kan bero på vart för det är som sagt gigantiskt företag och finns andra områden där stjärnorna sitter.

Här i Sverige jobbade jag under 3 års tid väldigt nära dem eftersom vi utvecklade ett CRM system som var anpassat för att köra mot deras inköpta MS SQL Server och det var en en strategiskt viktig produkt för Microsoft. Fick de in databasen på stora företag och företaget lärde sig databasen fortsatte de och bygga system på databasen och sedan satt de fast Microsoft hjälpte till (med allt)

CRM systemet vi skrev (gjorde backenden bl.a.) slog det mesta och hade några saker de andra CRM företagen saknade (replikering bl.a.)

Well Microsoft och imponerande är väl inte två ord som jag skulle säga hör ihop, i min erfarenhet. Behövde en custom USB-implementation i ett tidigare uppdrag (testutrustning för PCBA i fabrik) och det tog ~2mån att få det att fungera tillförlitligt med winapi och helt baklänges. Samma sak tog mig en eftermiddag att fixa på linux, no joke. (Bara kika på kommentarerna i koden för libusb om man vill läsa lite rant).

Det finns tillfällen där man behöver producera mycket och bra, och i min erfarenhet är de två inte heller synonyma (därav att jag skrev "nästan aldrig"). Jag känner flera riktigt duktiga programmerare, vissa av dom självutnämnda experter, men återigen så är koden bara ett verktyg för att lösa ett eller flera problem. Har du en dålig plan på hur du går an problemet så kan du ha skrivit världens bästa kod till en dålig lösning ändå.

Visa signatur

Citera mig för svar.
Arch Linux

Permalänk
Medlem
Skrivet av serafim:

Ada, Algol60 (inte mycket), Algol68 (inte mycket), APL, Assembly (ASM), Basic (usch!), BETA, C, C++, C# (inte mycket), Caml, CLP(R), COBOL (värsta språket någonsin), Common Lisp, DCL, Delphi, ECMAScript, Eiffel (bara tester inga stora grejer), Erlang, Forth, Fortran, Go, Groovy, Haskell, HTML, Informix-4GL, Java, JavaScript, LaTeX, LISP, Maple, MATLAB, Miranda, ML, Modula, Modula-2, Modula-3, Napier88 (bara tester och en del lek), OCaml, Octave, Oberon, Object Pascal, Objective-C, Oz, PHP, PL/I, Pascal, Perl, Pizza (intressant men inte mycket), PostScript, Prolog, Python, R, Ruby, Self, SQL, Scheme, Simula, Smalltalk, SQL, Tcl, TECO (kul men jobbigt, inga projekt), XML, XPath, XSLT.

*jösses*

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

Permalänk
Medlem
Skrivet av Dimman:

Jag känner flera riktigt duktiga programmerare, vissa av dom självutnämnda experter, men återigen så är koden bara ett verktyg för att lösa ett eller flera problem. Har du en dålig plan på hur du går an problemet så kan du ha skrivit världens bästa kod till en dålig lösning ändå.

Och jag håller alltså med om att den bästa koden är den man rensat bort, men har aldrig träffat någon riktigt duktig utvecklare som inte skrivit väldigt mycket kod och gillar att skriva kod. Tror inte det är möjligt att bli duktig utvecklare om man inte skriver mycket kod.

Det är många som "tror" de är bra trots att de inte skrivit så mycket kod däremot. Men det är nog mest en tro

Permalänk
Medlem
Skrivet av klk:

*jösses*

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

Tror jag inte, jag har hållit på i många år. Oftast har man inte möjlighet att välja språk, man tar det som finns tillgängligt på företaget.

Jag är numera pensionär men fortsätter programmera en hel del, mest elektroniska leksaker som oftast drivs av en Raspberry Pi Pico med några små servomotorer. Programmeras med fördel i C eller Python. Riktigt kul att pyssla med.

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

Jag har jobbat med en mängd olika saker, bland annat i flera större utvecklingsprojekt och med utbildning, är ursprungligen matematiker men har jobbat mest med programmering och utbildning. Jag har programmerat i ett stort antal språk, bl. a.
Ada, Algol60 (inte mycket), Algol68 (inte mycket), APL, Assembly (ASM), Basic (usch!), BETA, C, C++, C# (inte mycket), Caml, CLP(R), COBOL (värsta språket någonsin), Common Lisp, Delphi, ECMAScript, Eiffel (bara tester inga stora grejer), Erlang,Forth, Fortran, Go, Groovy, Haskell, HTML, Informix-4GL, Java, JavaScript, LaTeX, LISP, Maple, MATLAB, Miranda, ML, Modula, Modula-2, Modula-3, Napier88 (bara tester och en del lek), OCaml, Octave, Oberon, Object Pascal, Objective-C, Oz, PHP, PL/I, Pascal, Perl, Pizza (intressant men inte mycket), PostScript, Prolog, Python, R, Ruby, Self, SQL, Scheme, Simula, Smalltalk, SQL, Tcl, TECO (kul men jobbigt, inga projekt), XML, XPath, XSLT.

Av ren nyfikenhet, vad programmerade du i Erlang och vad tyckte du om det?
Jag är smått förbluffad över att erlang inte är större än vad det är med tanke på hur kraftfullt det är.

Jobbade själv med erlang i några år, men fick aldrig utnyttja skalbarheten i språket då produkten i sig inte utnyttjade det fullt ut. Men tycker språket i sig är fenomenalt, om än lite svårt med såpass liten community.

Permalänk
Medlem
Skrivet av klk:

Och jag håller alltså med om att den bästa koden är den man rensat bort, men har aldrig träffat någon riktigt duktig utvecklare som inte skrivit väldigt mycket kod och gillar att skriva kod. Tror inte det är möjligt att bli duktig utvecklare om man inte skriver mycket kod.

Det är många som "tror" de är bra trots att de inte skrivit så mycket kod däremot. Men det är nog mest en tro

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.

Visa signatur

Citera mig för svar.
Arch Linux

Permalänk
Medlem
Skrivet av klk:

Kan du utveckla?

Har du jobbat i "embedded i C senaste 15 åren" kanske ni inte är så vana att testa olika tekniker

Innan du skriver sådana inlägg, frågar du aldrig dig själv "varför skulle embedded C inte testa olika tekniker"? :S

Hårdvara utvecklas ju och funktionaliteten mappas ju i C, utöver det så kommer det ju nya protokoll, OS-features(select, poll, epoll, io_uring osv), säkerhetskrav som gör att nya tekniker används. Utöver så påverkar trender inom open-source-kod industrin. Kort och gott embedded C lever inte i en isolerad bubbla utan utvecklas ständigt.

Permalänk
Medlem
Skrivet av huttala:

Av ren nyfikenhet, vad programmerade du i Erlang och vad tyckte du om det?
Jag är smått förbluffad över att erlang inte är större än vad det är med tanke på hur kraftfullt det är.

Jobbade själv med erlang i några år, men fick aldrig utnyttja skalbarheten i språket då produkten i sig inte utnyttjade det fullt ut. Men tycker språket i sig är fenomenalt, om än lite svårt med såpass liten community.

Jag kodar Erlang(som hobby) och gillar det. Jag har blivit lite intresserad av Elixir och Gleam för att kunna få in starkare typer. Vi kanske skulle dragit igång en BEAM-tråd? *wink* *wink*

Permalänk
Medlem
Skrivet av orp:

Innan du skriver sådana inlägg, frågar du aldrig dig själv "varför skulle embedded C inte testa olika tekniker"? :S

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.
Att exempelvis vara haj på AUTOSAR eller ens klara av att sitta med det, då har man andra intressen än att programmera

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.
Att exempelvis vara haj på AUTOSAR eller ens klara av att sitta med det, då har man andra intressen än att programmera

Woop woop, magnetpolerna är tillbaks 🙌. Vad hade vi gjort utan din erfarenhet och expertis här i världen är frågan 😃 Btw, året är 2025.

Visa signatur

Citera mig för svar.
Arch Linux

Permalänk
Medlem
Skrivet av huttala:

Av ren nyfikenhet, vad programmerade du i Erlang och vad tyckte du om det?
Jag är smått förbluffad över att erlang inte är större än vad det är med tanke på hur kraftfullt det är.

Jobbade själv med erlang i några år, men fick aldrig utnyttja skalbarheten i språket då produkten i sig inte utnyttjade det fullt ut. Men tycker språket i sig är fenomenalt, om än lite svårt med såpass liten community.

Jag har bara nämnt att jag programmerat i det, inte att jag varit produktiv i det.
Det var för länge sen (på 90-talet) i samband med ett projekt på Ericsson och tester av nya telefonväxlar. Gillade språket, men min bekantskap med det var kort. Min inblandning var minimal, jag var handledare för ett par studenter som gjorde sina exjobb där men jag satte mig in i språket och programmerade en del i det mest för att kunna handleda studenterna på ett konstruktivt sätt och för att kunna begripa och resonera även kring koden de framställde. Trevligt språk.

Gillade framförallt att det var funktionellt och hade svansrekursion, list comprehension (hittar ingen bra svensk term), mönstermatchning, inbyggda primitiver för parallellprogrammering. Påminde en del om ML.

Men språket var en ren Ericsson-produkt och trots att det publicerades med öppen källkod och generösa licensvillkor blev det mest ett forskningsspråk förutom på Ericsson där det användes i deras telefonväxlar. Bra att de ersatte PLEX som var förfärligt.

Vet inte om det används utanför Ericsson och forskningsvärlden idag. Vet inte ens om Ericsson fortfarande avänder det, de har ju en historia av språkbyten (ibland med katastrofala följder)...

Fanns en Erlang community (kanske lever fortfarande)

Permalänk
Medlem

WhatsApp är skrivet i Erlang....

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

Jag kodar Erlang(som hobby) och gillar det. Jag har blivit lite intresserad av Elixir och Gleam för att kunna få in starkare typer. Vi kanske skulle dragit igång en BEAM-tråd? *wink* *wink*

Jag har faktiskt kodat lite Elixir nu på fritiden för att det är "det nya" och chansen att få jobb där är större än som erlang utvecklare. Men ser ärligt talat inte poängen med det mer än att det finns mer community support för språket, vilket gör att det antagligen är Elixir som är det man ska hålla på med om man vill ha en chans att få jobb inom något roligare än .NET/Java svängen.
Sen gillar jag Erlang syntaxen betydligt mer än Elixir.

Gleam känns för nytt för att lägga ner allt för mycket tid på, men det kanske är jag som är tråkig som bara vill lära mig saker jag eventuellt någon gång, kanske kan få jobb inom.
Med det sagt skulle jag nog hellre leka vidare med gleam än elixir då gleam känns mer "hemma" för mig.

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.
Att exempelvis vara haj på AUTOSAR eller ens klara av att sitta med det, då har man andra intressen än att programmera

Nu har jag ju framförallt arbetat med C-utveckling i embedded Linux(ca 12 år) och jag skulle väl vilja påstå att embedded utvecklare är bland dom vanligare utvecklarna kring Lund(iaf med min uppfattning) som en följd av att det kommit och gått företag som varit embeddedtunga(Sony, Ericsson, Intel, Apple, Volvo, Axis).

Men embedded står inte still, en hel del har hänt inom Linux som fortsätter att gå fram som en raket. FreeRTOS fick ett uppsving med Amazons (temporära?) satsning. ZephyrRTOS har tillkommit som en del av Linux Foundation. Gällande kompilatorer så kändes det som att GCC fick lite eld i baken allt eftersom clang blev produktionsklar och fick uppmärksamhet. Gällande byggverktyg så har det gått från autotools, cmake, meson(ninja) och bazel. På libc fronten har jag sett uClibc komma och gå och övergången till glibc eller musl. Utöver detta så finns det en rad lib:ar och protokoll som kommit och gått. Allt detta ger ju inflytande på industrin och kan på verka tekniker.

Permalänk
Medlem
Skrivet av orp:

Nu har jag ju framförallt arbetat med C-utveckling i embedded Linux(ca 12 år) och jag skulle väl vilja påstå att embedded utvecklare är bland dom vanligare utvecklarna kring Lund(iaf med min uppfattning) som en följd av att det kommit och gått företag som varit embeddedtunga(Sony, Ericsson, Intel, Apple, Volvo, Axis).

Men embedded står inte still, en hel del har hänt inom Linux som fortsätter att gå fram som en raket. FreeRTOS fick ett uppsving med Amazons (temporära?) satsning. ZephyrRTOS har tillkommit som en del av Linux Foundation. Gällande kompilatorer så kändes det som att GCC fick lite eld i baken allt eftersom clang blev produktionsklar och fick uppmärksamhet. Gällande byggverktyg så har det gått från autotools, cmake, meson(ninja) och bazel. På libc fronten har jag sett uClibc komma och gå och övergången till glibc eller musl. Utöver detta så finns det en rad lib:ar och protokoll som kommit och gått. Allt detta ger ju inflytande på industrin och kan på verka tekniker.

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

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

Jag har bara nämnt att jag programmerat i det, inte att jag varit produktiv i det.
Det var för länge sen (på 90-talet) i samband med ett projekt på Ericsson och tester av nya telefonväxlar. Gillade språket, men min bekantskap med det var kort. Min inblandning var minimal, jag var handledare för ett par studenter som gjorde sina exjobb där men jag satte mig in i språket och programmerade en del i det mest för att kunna handleda studenterna på ett konstruktivt sätt och för att kunna begripa och resonera även kring koden de framställde. Trevligt språk.

Gillade framförallt att det var funktionellt och hade svansrekursion, list comprehension (hittar ingen bra svensk term), mönstermatchning, inbyggda primitiver för parallellprogrammering. Påminde en del om ML.

Men språket var en ren Ericsson-produkt och trots att det publicerades med öppen källkod och generösa licensvillkor blev det mest ett forskningsspråk förutom på Ericsson där det användes i deras telefonväxlar. Bra att de ersatte PLEX som var förfärligt.

Vet inte om det används utanför Ericsson och forskningsvärlden idag. Vet inte ens om Ericsson fortfarande avänder det, de har ju en historia av språkbyten (ibland med katastrofala följder)...

Fanns en Erlang community (kanske lever fortfarande)

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).