Permalänk
Medlem
Skrivet av Yoshman:

Antar att du med "industrin" menar IT-industrin?

För mig har ordet "industri" en smalare betydelse, tänker på "industritillämpningar" och där är C#/.NET allt annat än dominant.

Nej jag tänker på industri som i tillverkningsindustri eller liknande, men jag kunde förstås varit snävare i mitt uttalande. Jag pratar alltså inte om den mjukvara som styr maskiner direkt på någon låg nivå, det är inte det jag pysslar med, utan mer systemen som styr dessa. Vi använder exempelvis en hel del hårdvara från Sick, sensorer, scanners och så vidare, och då använder vi förstås deras mjukvara för att styra deras hårdvara. Den mjukvaran är dock varken användarvänlig eller smidig på något sätt så våra kunder använder inte den utan vårt styrsystem där de inte behöver bry sig om så mycket detaljer. Tanken är också att våra medarbetare ska använda vårt system för att konfigurera kundernas lösningar så långt som möjligt så att de ska slippa gå in i femton olika system och skriva in hundratals extremt känsliga parametrar helt utan något stöd i mjukvaran eller någon indikation på om det är korrekt eller ej förrän man märker att saker inte funkar. Vårt system försöker lösa ett större problem, inte vilken hjulvinkel och hjulhastighet en robot behöver ha för att ta sig igenom en viss kurva utan snarare hur vi kan maximera throughput från hundra robotar över tid i ett givet system med maskininlärning och samtidigt presentera relevant statistik för kunden, i ett användarvänligt system som funkar på alla enheter men ändå med höga säkerhetskrav och så, och samtidigt hålla koll på maskinerna så att de servas eller byts ut innan de går sönder. Mina chefer pratar mycket om "Industry 4.0", vilket väl är vad vi går emot i alla fall.

Jag vet inte vad som är vanligast på arbetsmarknaden förstås, men min uppfattning är att dessa lågnivåsystem är mer färdiga från leverantören. Ska man styra en produktionslina så har varje del där, varje robot eller sensor exempelvis, en mjukvara som fungerar bra för hårdvarans funktionalitet, men utmaningen ligger i att få dessa att fungera tillsammans på ett enkelt sätt, både förstås för själva produktionen men också för statistik, loggning, felsökning och liknande. Därav finns det rätt många jobb där man bygger den typen av kundlösningar, mer eller mindre anpassade för varje miljö de ska verka i.

Citat:

Inom bilindustrin är C++ väldigt vanligt, bl.a. p.g.a. AUTOSAR.
Inom flygindustrin är C, följt av Ada följt av C++ vanligt p.g.a. kraven från DO178 (lycka till att få igenom ens något form icke-trivialt C# eller Java program genom den standarden...).
Inom robotics är C++ väldigt vanligt, men här har jag i alla fall sett Java eller C#/.NET användas.

Jo visst är det så. Men då har vi väl lämnat "industrin". Vad Volvo har för system som styr sin produktion är ganska skilt från vad de har för mjukvara i sina bilar när de är byggda exempelvis. Jag sysslar med lösningar för industrin, inte för industrins produkter.

Citat:

Givet vem TS är här misstänker jag att kontext för "industri" är just "industritillämpningar / inbyggda-system". Där är fortfarande C och C++ klart dominerade.

Jo visst. Samtidigt vill ju industrin inte bara ha en robot som gör vad den ska när man trycker på knappen längre, utan de vill kunna styra allt centralt, se statistik över tid, få indikationer på när saker inte riktigt fungerar som de ska, få möjligheter att tweaka systemen och minimera handpåläggning. Min uppfattning är att det är en rätt stor andel av mjukvaruutvecklarna i alla fall här i landet som jobbar med den typen av lösningar. ABB eller liknande har säkert en massa utvecklare som sitter och bygger styrningen för deras robotar med, men det är ju fortfarande en lösning för en stor mängd system liksom.

Permalänk
Datavetare
Skrivet av snajk:

Nej jag tänker på industri som i tillverkningsindustri eller liknande, men jag kunde förstås varit snävare i mitt uttalande. Jag pratar alltså inte om den mjukvara som styr maskiner direkt på någon låg nivå, det är inte det jag pysslar med, utan mer systemen som styr dessa. Vi använder exempelvis en hel del hårdvara från Sick, sensorer, scanners och så vidare, och då använder vi förstås deras mjukvara för att styra deras hårdvara. Den mjukvaran är dock varken användarvänlig eller smidig på något sätt så våra kunder använder inte den utan vårt styrsystem där de inte behöver bry sig om så mycket detaljer. Tanken är också att våra medarbetare ska använda vårt system för att konfigurera kundernas lösningar så långt som möjligt så att de ska slippa gå in i femton olika system och skriva in hundratals extremt känsliga parametrar helt utan något stöd i mjukvaran eller någon indikation på om det är korrekt eller ej förrän man märker att saker inte funkar. Vårt system försöker lösa ett större problem, inte vilken hjulvinkel och hjulhastighet en robot behöver ha för att ta sig igenom en viss kurva utan snarare hur vi kan maximera throughput från hundra robotar över tid i ett givet system med maskininlärning och samtidigt presentera relevant statistik för kunden, i ett användarvänligt system som funkar på alla enheter men ändå med höga säkerhetskrav och så, och samtidigt hålla koll på maskinerna så att de servas eller byts ut innan de går sönder. Mina chefer pratar mycket om "Industry 4.0", vilket väl är vad vi går emot i alla fall.

Jag vet inte vad som är vanligast på arbetsmarknaden förstås, men min uppfattning är att dessa lågnivåsystem är mer färdiga från leverantören. Ska man styra en produktionslina så har varje del där, varje robot eller sensor exempelvis, en mjukvara som fungerar bra för hårdvarans funktionalitet, men utmaningen ligger i att få dessa att fungera tillsammans på ett enkelt sätt, både förstås för själva produktionen men också för statistik, loggning, felsökning och liknande. Därav finns det rätt många jobb där man bygger den typen av kundlösningar, mer eller mindre anpassade för varje miljö de ska verka i.
Jo visst är det så. Men då har vi väl lämnat "industrin". Vad Volvo har för system som styr sin produktion är ganska skilt från vad de har för mjukvara i sina bilar när de är byggda exempelvis. Jag sysslar med lösningar för industrin, inte för industrins produkter.
Jo visst. Samtidigt vill ju industrin inte bara ha en robot som gör vad den ska när man trycker på knappen längre, utan de vill kunna styra allt centralt, se statistik över tid, få indikationer på när saker inte riktigt fungerar som de ska, få möjligheter att tweaka systemen och minimera handpåläggning. Min uppfattning är att det är en rätt stor andel av mjukvaruutvecklarna i alla fall här i landet som jobbar med den typen av lösningar. ABB eller liknande har säkert en massa utvecklare som sitter och bygger styrningen för deras robotar med, men det är ju fortfarande en lösning för en stor mängd system liksom.

Ah, då är jag med. Just ABBs robotar har jag lite koll på då de kör VxWorks. Där används primärt C++ (och de använder "modern" C++ nu för tiden, VxWorks stödjer upp till C++17 out-of-the-box) i själva roboten, men de gör mycket av "kringkomponenter" med C#/.Net.

Kuka använder även de VxWorks i sina robotar, de använder i stället Java/JVM för det mesta av "kringkomponenterna".

Båda dessa är ju rätt gamla i gemet, en spännande frågeställning vore: om de startade med rent papper, vad skulle de välja idag för att göra sina kringsystem? Lite svårt att se fördelarna med vare sig C#/.NET (även om det idag finns Linux-stöd är det primärt en Windows-teknik) eller Java, det då de sakerna man gör i dessa ramverk är specifikt de saker som man i "industri 4.0" kommer lägga i molnet.

I "molnet" handlar det om att prisoptimera, även om man kan göra "microservices" i både .NET och JVM finns det andra tekniker som är bättre på detta idag. Framförallt om man börjar snegla på att köra på andra plattformar än x86.

Har absolut inget emot C#/.Net, tycker det tvärtom är av de tekniker jag gärna jobbar med. Men om jag fick starta med rent papper 2021 har jag svårt att egentligen se något fall där det skulle bli förstahandsvalet. I praktiken är det sällan ett val man får göra.

Blir dock lite frustrerande när plattformen är vald och man måste göra saker som inte alls är optimalt. Har bl.a. försökt göra lite mer prestandakritiska saker med C#/TPL (kunde inte välja plattform då allt annat var i C#/.NET). Problemet var trivialt att lösa i teorin, och gjorde även en PoC med C++/OpenMP när det fungerade så pass dåligt i C#/TPL. Ingen fel på min arkitektur, problemet låg helt enkelt i .NET ("p" värdet i Amdals lag är helt enkelt betydligt större för C++/OpenMP än för C#/TPL, så finns långt fler problem som man effektivt kan skala över kärnor med det senare). Nu går det ju naturligtvis att lösa med en "native" modul i C++ som anropas från .NET, men börjar man med sådant är det betydligt enklare att skriva rubbet i "modern" C++ (d.v.s. C++11 eller senare, för den som inte sett "modern" C++ är det som ett annat språk, med C++20 har jag svårt att se något man kan göra i C# som inte nästan exakt 1:1 går att göra i C++).

Permalänk
Datavetare
Skrivet av heretic16:

Jag vet inte. Jag tycker att inbyggda system handlar om system utan operativsystem, dvs system som även kallas realtidssystem.
Också en luddig definition
Om en Volvo V70 skulle haft Windows 98 som styrbox för insprutningen så hade det säkerligen varit ett långsammare system.

System utan OS är ju nästan alltid någon form av mikrokontroller. De är absolut "inbyggda system", men "inbyggda system" är långt bredare.

Ta mobilnätverken. Tror alla är rätt överens om att de ska klassas som "inbyggda system", men de kör ju idag någon form av "realtids Linux" (Linux kan bara hantera "mjuk" realtid, det är inte ett RTOS) typiskt baserad på Yocto. Det är ju i praktiken en Linux-distro. Även om majoriteten av programvaran i de systemen är utvecklare med C eller C++ finns det idag Go (molntjänster), Python (varför ta något annat om prestanda inte är kritiskt?) och garanterat även saker baserade på Java och/eller NodeJS (monitorering etc).

Är antagligen inte speciellt vanligt men i "mjuka" realtidsfall finns det ju system som är skrivna i C#/.NET eller Java/JVM. Men då handlar det i praktiken alltid om "vanliga" PCn som kör Windows/Linux. För "hård" realtid får man endera köra utan OS eller med RTOS och i praktiken fungerar bara språk assembler, C, C++, ObjC och Rust. Är lite osäker på om Swift, men det skulle potentiellt också fungera för "hård realtid" (det har helt deterministisk minneshantering, vilket är ett krav).

Permalänk
Medlem
Skrivet av Yoshman:

System utan OS är ju nästan alltid någon form av mikrokontroller. De är absolut "inbyggda system", men "inbyggda system" är långt bredare.

Ta mobilnätverken. Tror alla är rätt överens om att de ska klassas som "inbyggda system", men de kör ju idag någon form av "realtids Linux" (Linux kan bara hantera "mjuk" realtid, det är inte ett RTOS) typiskt baserad på Yocto. Det är ju i praktiken en Linux-distro. Även om majoriteten av programvaran i de systemen är utvecklare med C eller C++ finns det idag Go (molntjänster), Python (varför ta något annat om prestanda inte är kritiskt?) och garanterat även saker baserade på Java och/eller NodeJS (monitorering etc).

Är antagligen inte speciellt vanligt men i "mjuka" realtidsfall finns det ju system som är skrivna i C#/.NET eller Java/JVM. Men då handlar det i praktiken alltid om "vanliga" PCn som kör Windows/Linux. För "hård" realtid får man endera köra utan OS eller med RTOS och i praktiken fungerar bara språk assembler, C, C++, ObjC och Rust. Är lite osäker på om Swift, men det skulle potentiellt också fungera för "hård realtid" (det har helt deterministisk minneshantering, vilket är ett krav).

Kul!

Du skulle fått kolla upp STM32CubeIDE om du gillar inbyggda system. Dom har nämligen en grafisk applikation inbyggt i STM32CubeIDE som heter CubeMX. Där man kan peka och klicka på vad man vill ha för konfigureringar för projektet, utan att ens skriva en enda rad kod. Supersmidigt.

Vad tror du om Java ME? Står det för Micro Edition eller Mobile Enterprise? Jag har hört båda.
Vad är framtiden med Java ME? Jag har sett så kom senaste uppdateringen vid Januari 2018. Men sedan dess har det varit tyst.

Permalänk
Medlem

min spontana känsla är att .net core inte är så himla hårdvarunära. Då kommer du bli beroende av externa bibliotek /dll/lib som du förhoppningsvis kan anropa från c# / net core

Net Core har just nu inget GUI som är generellt äver plattformarna heller, även om det är på G

Flest hårdvarubibliotek verkar finnas tillgängliga för Python - så Python+QT skulle jag säga om du satsar på att koda mot industri-maskiner

// LZ

Permalänk
Medlem
Skrivet av Tea42BBS:

min spontana känsla är att .net core inte är så himla hårdvarunära. Då kommer du bli beroende av externa bibliotek /dll/lib som du förhoppningsvis kan anropa från c# / net core

Net Core har just nu inget GUI som är generellt äver plattformarna heller, även om det är på G

Flest hårdvarubibliotek verkar finnas tillgängliga för Python - så Python+QT skulle jag säga om du satsar på att koda mot industri-maskiner

// LZ

Är det inte bättre med C++ QT?
Inget illa om Python. Det är ett jättefint språk, men jag ogillar kulturen kring Python. Språket drar till sig lata kodare som är beroende av andras kod. Dessutom har Python en hel uppsjö av tveksamma bibliotek för Pythonkodare tenderar att vara tillfälliga kodare, av just enkelhetens skull. Också tycker jag att traditionella python-kodare verkar få ett intresse att skriva allt på en enda rad, alltså vektorisera. Detta gör koden svår att läsa.

Om man tar ett C-bibliotek som är från 1995 så fungerar den lika bra idag som då.
Om vi tar ett Python-bibliotek som är från 2000 så skulle jag inte köra den. Den fungerar troligtvis inte heller.

Permalänk
Medlem
Skrivet av heretic16:

Är det inte bättre med C++ QT?
Inget illa om Python. Det är ett jättefint språk, men jag ogillar kulturen kring Python. Språket drar till sig lata kodare som är beroende av andras kod. Dessutom har Python en hel uppsjö av tveksamma bibliotek för Pythonkodare tenderar att vara tillfälliga kodare, av just enkelhetens skull. Också tycker jag att traditionella python-kodare verkar få ett intresse att skriva allt på en enda rad, alltså vektorisera. Detta gör koden svår att läsa.

Om man tar ett C-bibliotek som är från 1995 så fungerar den lika bra idag som då.
Om vi tar ett Python-bibliotek som är från 2000 så skulle jag inte köra den. Den fungerar troligtvis inte heller.

jag håller inte med om din kategorisering av Python kodare - sjukt stor community med många duktiga kodare.

IMHO så är chansen att göra fel i C/C++ för stor, för lätt att få något pekarfel i ngn länkad lista eller dynamisk array. Eller någon malloc / calloc som inte matchar o käkar några bytes här o där för att till slut brinna i helvetet

Jag tycker det ska vara enkelt att utveckla kod o man ska använda alla hjälpmedel som finns till buds. Tycker inte om mentaliteten "jag gör detta så svårt o mysko att de aldrig kan byta ut mig"

mvh Lazze

Permalänk
Medlem
Skrivet av Tea42BBS:

jag håller inte med om din kategorisering av Python kodare - sjukt stor community med många duktiga kodare.

IMHO så är chansen att göra fel i C/C++ för stor, för lätt att få något pekarfel i ngn länkad lista eller dynamisk array. Eller någon malloc / calloc som inte matchar o käkar några bytes här o där för att till slut brinna i helvetet

Jag tycker det ska vara enkelt att utveckla kod o man ska använda alla hjälpmedel som finns till buds. Tycker inte om mentaliteten "jag gör detta så svårt o mysko att de aldrig kan byta ut mig"

mvh Lazze

Självklart så är pythonprogrammerare duktiga. Men enkla språk drar till sig programmerare som inte har inte tid att programmera, vilket leder till att det dålig kod.

Stressprogrammerare med andra ord.

Permalänk
Medlem
Skrivet av heretic16:

Självklart så är pythonprogrammerare duktiga. Men enkla språk drar till sig programmerare som inte har inte tid att programmera, vilket leder till att det dålig kod.

Stressprogrammerare med andra ord.

Fast det är snarare programmeraren och jobbet snarare än språket.

Gällande språk, så skulle jag väl titta på Rust/Kotlin istället för C++ och Java. Finns ju anledningar till Varför Linux kerneln börjar närma sig att göra hoppet mot Rust.

Alla våra Java projekt har bytt mot Kotlin och Googles dumpning av Java på alla plan så ser jag liten anledning till att köra Java numera.

C++ => Rust
Java => Kotlin

Själv så kör jag C# .NET men som andra säger .NET 5 har inget gui stöd utanför Windows/Mac men det kanske förändras i framtiden.
Electron är i stort sätt alla program som är crossplatform idag. (Spotify, Insomnia, Discord, Skype, Slack, VScode, Atom, Tusk, Mailspring, OBS, WhatsApp, mm)

Nackdelen med Electron är att den kör Chromium instans för gott och ont, så ingen Electron app lär hamna under 50MB runtime)

Permalänk
Medlem
Skrivet av Commander:

Fast det är snarare programmeraren och jobbet snarare än språket.

Gällande språk, så skulle jag väl titta på Rust/Kotlin istället för C++ och Java. Finns ju anledningar till Varför Linux kerneln börjar närma sig att göra hoppet mot Rust.

Alla våra Java projekt har bytt mot Kotlin och Googles dumpning av Java på alla plan så ser jag liten anledning till att köra Java numera.

C++ => Rust
Java => Kotlin

Själv så kör jag C# .NET men som andra säger .NET 5 har inget gui stöd utanför Windows/Mac men det kanske förändras i framtiden.
Electron är i stort sätt alla program som är crossplatform idag. (Spotify, Insomnia, Discord, Skype, Slack, VScode, Atom, Tusk, Mailspring, OBS, WhatsApp, mm)

Nackdelen med Electron är att den kör Chromium instans för gott och ont, så ingen Electron app lär hamna under 50MB runtime)

Tror inte Linus Torvalds skulle acceptera att Rust ersätter C i linuxkärnan. Samma sak som Oracle kommer inte acceptera att Kotlin ersätter Java.

Övrigt så har jag personligen lust att testa Kotlin för att se om det blir mindre kod än Java.

Permalänk
Medlem
Skrivet av heretic16:

Tror inte Linus Torvalds skulle acceptera att Rust ersätter C i linuxkärnan. Samma sak som Oracle kommer inte acceptera att Kotlin ersätter Java.

Övrigt så har jag personligen lust att testa Kotlin för att se om det blir mindre kod än Java.

Vad Oracle säger spelar ju ingen roll, de brände sig rejält med nya commercial licenserna och stämningen av Google gällande Java APIer.
Gällande C så lär han inte släppa det men Rust kommer att börja gå in:
https://itwire.com/open-source/rust-support-in-linux-may-be-p...

Permalänk
Medlem
Skrivet av Commander:

Vad Oracle säger spelar ju ingen roll, de brände sig rejält med nya commercial licenserna och stämningen av Google gällande Java APIer.
Gällande C så lär han inte släppa det men Rust kommer att börja gå in:
https://itwire.com/open-source/rust-support-in-linux-may-be-p...

Ja det gjorde dom. Men dom äger ändå rätten till Java och Kotlin kör ju på java.

Twivlar på att Rust kommer bli ett lyckat språk i nivå med C eller C++. Alltså det kommer nå upp till fordonsindustrin.

Permalänk
Medlem
Skrivet av Yoshman:

Ah, då är jag med. Just ABBs robotar har jag lite koll på då de kör VxWorks. Där används primärt C++ (och de använder "modern" C++ nu för tiden, VxWorks stödjer upp till C++17 out-of-the-box) i själva roboten, men de gör mycket av "kringkomponenter" med C#/.Net.

Kuka använder även de VxWorks i sina robotar, de använder i stället Java/JVM för det mesta av "kringkomponenterna".

Båda dessa är ju rätt gamla i gemet, en spännande frågeställning vore: om de startade med rent papper, vad skulle de välja idag för att göra sina kringsystem? Lite svårt att se fördelarna med vare sig C#/.NET (även om det idag finns Linux-stöd är det primärt en Windows-teknik) eller Java, det då de sakerna man gör i dessa ramverk är specifikt de saker som man i "industri 4.0" kommer lägga i molnet.

I "molnet" handlar det om att prisoptimera, även om man kan göra "microservices" i både .NET och JVM finns det andra tekniker som är bättre på detta idag. Framförallt om man börjar snegla på att köra på andra plattformar än x86.

Har absolut inget emot C#/.Net, tycker det tvärtom är av de tekniker jag gärna jobbar med. Men om jag fick starta med rent papper 2021 har jag svårt att egentligen se något fall där det skulle bli förstahandsvalet. I praktiken är det sällan ett val man får göra.

Nej, rent papper är inte så vanligt och även om man verkligen börjar om på nytt med koden har man ju i allmänhet andra saker som påverkar val av språk, ramverk eller teknik än just vad som passar absolut bäst för den specifika uppgiften. Som att man har en utvecklingsavdelning som är bekväma eller har mest erfarenhet med något, kan och har redan verktygen som behövs och liknande, men också förstås rädsla/konservatism hos de som bestämmer vilket gör att de vill att man kör något de känner till eller i alla fall något stabilt och välanvänt i den bransch eller nisch företaget verkar inom.

Citat:

Blir dock lite frustrerande när plattformen är vald och man måste göra saker som inte alls är optimalt. Har bl.a. försökt göra lite mer prestandakritiska saker med C#/TPL (kunde inte välja plattform då allt annat var i C#/.NET). Problemet var trivialt att lösa i teorin, och gjorde även en PoC med C++/OpenMP när det fungerade så pass dåligt i C#/TPL. Ingen fel på min arkitektur, problemet låg helt enkelt i .NET ("p" värdet i Amdals lag är helt enkelt betydligt större för C++/OpenMP än för C#/TPL, så finns långt fler problem som man effektivt kan skala över kärnor med det senare). Nu går det ju naturligtvis att lösa med en "native" modul i C++ som anropas från .NET, men börjar man med sådant är det betydligt enklare att skriva rubbet i "modern" C++ (d.v.s. C++11 eller senare, för den som inte sett "modern" C++ är det som ett annat språk, med C++20 har jag svårt att se något man kan göra i C# som inte nästan exakt 1:1 går att göra i C++).

Jo absolut är det frustrerande, men det är ju så det ser ut. Så länge man måste samarbeta med andra människor så kommer man aldrig att få det precis så som man själv tycker att det borde vara, och det gäller inte bara utvecklare utan också produktägare, arkitekter och så vidare.

Permalänk
Medlem
Skrivet av heretic16:

Ja det gjorde dom. Men dom äger ändå rätten till Java och Kotlin kör ju på java.

Twivlar på att Rust kommer bli ett lyckat språk i nivå med C eller C++. Alltså det kommer nå upp till fordonsindustrin.

Beror på vad du targettar i Kotlin, Den kan köra mot JVM, Javascript, och Native. Även med JVM så kan du köra mot Openjdk istället för Oracles.

Minns att det tidigare har varit skillnader mellan prestanda och funktionalitet (~5 år sen) men idag tror jag det inte finns en anledning alls till att köra Oracle's JVM om man specifikt inte behöver just deras libs av någon okänd anledning).

Personligen tror jag att Rust kan bli större än C++ bara man ger det tid. Speciellt iom trycket på säkerhet de senaste åren, man programmerar inte längre en applikation som sitter i en källare med en admin. Allt är uppkopplat antingen på interna nätverket eller utåt och som du nämner finnas i cloud. Detta ställer mycket högre krav på stabilitet och säkerhet.

Permalänk
Medlem
Skrivet av Commander:

Beror på vad du targettar i Kotlin, Den kan köra mot JVM, Javascript, och Native. Även med JVM så kan du köra mot Openjdk istället för Oracles.

Minns att det tidigare har varit skillnader mellan prestanda och funktionalitet (~5 år sen) men idag tror jag det inte finns en anledning alls till att köra Oracle's JVM om man specifikt inte behöver just deras libs av någon okänd anledning).

Personligen tror jag att Rust kan bli större än C++ bara man ger det tid. Speciellt iom trycket på säkerhet de senaste åren, man programmerar inte längre en applikation som sitter i en källare med en admin. Allt är uppkopplat antingen på interna nätverket eller utåt och som du nämner finnas i cloud. Detta ställer mycket högre krav på stabilitet och säkerhet.

Visst är OpenJDK alltså JVM?
Jag kör alltid OpenJDK. Jag vet inte av som är skillnaden mellan OpenJDK och OracleJDK jämfört med att med OracleJDK så får man uppdateringar. I Linux spelar det ingen roll för då är det pakethanteraren som sköter uppdateringarna åt en.

Jag väntar med att ISO standaliserar Rust. Då kan jag kan acceptera Rust som med i gänget.

Permalänk
Datavetare
Skrivet av snajk:

Nej, rent papper är inte så vanligt och även om man verkligen börjar om på nytt med koden har man ju i allmänhet andra saker som påverkar val av språk, ramverk eller teknik än just vad som passar absolut bäst för den specifika uppgiften. Som att man har en utvecklingsavdelning som är bekväma eller har mest erfarenhet med något, kan och har redan verktygen som behövs och liknande, men också förstås rädsla/konservatism hos de som bestämmer vilket gör att de vill att man kör något de känner till eller i alla fall något stabilt och välanvänt i den bransch eller nisch företaget verkar inom.
Jo absolut är det frustrerande, men det är ju så det ser ut. Så länge man måste samarbeta med andra människor så kommer man aldrig att få det precis så som man själv tycker att det borde vara, och det gäller inte bara utvecklare utan också produktägare, arkitekter och så vidare.

Att inte välja det som man identifierat som tekniskt bästa lösningen bara för att man för tillfället råkar ha anställda som inte från dag #1 är inläst på den bästa tekniken måste ju vara en gigantiska anti-pattern?

Bra kod tenderar leva både en, två och tre decennium. Bra programmerare kommer inte ha något problem att lära sig ny teknik och om inte annat är anställda typiskt mer volatila än resultatet av ett någorlunda lyckat projekt.

Så enda problemet här är just: är väldigt sällan man faktiskt har möjlighet att starta med blankt papper. När det händer, för mig har det hänt några gånger i karriären, finns ingen anledningen att inte dra maximal nytta av tillfället. Kommer få använda Rust just p.g.a. at detta i höst (hyfsat prestandakritisk fall som startas från scratch, så står mellan C++17 eller Rust2018)

Angående det sista: självklart är det bara anpassa sig, i detta fall fick det bli "är 'tillräckligt' snabbt ändå". Men för egen del känns det fel att lämna så pass mycket prestanda på bordet, men man måste vara pragmatisk...

Permalänk
Datavetare
Skrivet av heretic16:

Jag gillar när det finns bara en väg att koda. Det blir liksom en standard då och alla gör exakt likadant. Då är det enkelt att läsa andras koder.

BTW: då lär du få problem med C# också... I C# version 9 kan detta

using System; using System.Collections.Generic; namespace foo { class Program { static void Main(string[] args) { foreach (var msg in new List<String> { "Hello", " ", "world!", "\n" }) { Console.Write(msg); } } } }

kortas ned till detta

using System; using System.Collections.Generic; foreach (var msg in new List<String> { "Hello", " ", "world!", "\n" }) { Console.Write(msg); }

Varför man lade till detta är för mig en högst relevant fråga, känns långt mindre användbart i ett språk som normalt alltid har ett kompileringssteg. I skript-språk är det primärt användbart när man skriver enklare one-file-script.

Permalänk
Hedersmedlem
Skrivet av Yoshman:

Varför man lade till detta är för mig en högst relevant fråga, känns långt mindre användbart i ett språk som normalt alltid har ett kompileringssteg. I skript-språk är det primärt användbart när man skriver enklare one-file-script.

Kanske vill de bara minska mängden boilerplate-kod för små program och experimenterande, men de har löst det lite udda; det är snarare som att de bara har gömt de oönskade raderna:

using System; Console.WriteLine(String.Join(',', args));

(Det går bra att använda det vanliga argumentet till Main-funktionen som man trodde att man inte hade...)

Permalänk
Datavetare
Skrivet av Elgot:

Kanske vill de bara minska mängden boilerplate-kod för små program och experimenterande, men de har löst det lite udda; det är snarare som att de bara har gömt de oönskade raderna:

using System; Console.WriteLine(String.Join(',', args));

(Det går bra att använda det vanliga argumentet till Main-funktionen som man trodde att man inte hade...)

Tur att det är en så pass irrelevant finess i det stora hela, för där har man nog inte riktigt tänkt hela vägen. Implicita saker tenderar dra saker mot "write-only" hållet, man sparar ett par knapptryck när man skriver något men gör det svårare för alla andra att läsa...

Hur gör jag om jag vill döpa det implicita argumentet till något annat än args?

Permalänk
Medlem
Skrivet av Yoshman:

BTW: då lär du få problem med C# också... I C# version 9 kan detta

using System; using System.Collections.Generic; namespace foo { class Program { static void Main(string[] args) { foreach (var msg in new List<String> { "Hello", " ", "world!", "\n" }) { Console.Write(msg); } } } }

kortas ned till detta

using System; using System.Collections.Generic; foreach (var msg in new List<String> { "Hello", " ", "world!", "\n" }) { Console.Write(msg); }

Varför man lade till detta är för mig en högst relevant fråga, känns långt mindre användbart i ett språk som normalt alltid har ett kompileringssteg. I skript-språk är det primärt användbart när man skriver enklare one-file-script.

Jag föredrar den övre koden, för de innehåller ett "main". Då vet man vart man ska börja. Hade jag fått bestämma så hade C# skrivits så här.

Vad tycker du om Java ME då? Dött?

Permalänk
Medlem
Skrivet av Yoshman:

Att inte välja det som man identifierat som tekniskt bästa lösningen bara för att man för tillfället råkar ha anställda som inte från dag #1 är inläst på den bästa tekniken måste ju vara en gigantiska anti-pattern?

Nja, samtidigt blir ju vad man än väljer en kompromiss någonstans liksom. Vill man alltid ha den bästa tekniken riskerar man att hamna i andra problem istället. Jag lever varje dag med konsekvenserna av arkitekter som tycker det är viktigare att använda nya coola/smarta lösningar än att faktiskt bli färdig eller bygga saker bra från början exempelvis. Börjar man ställa frågor, eller kanske snarare kräva svar på ens frågor, om arkitekturen eller strukturen eller varför vi ska använda en specifik teknik (när det går emot arbetsmetodiken att styra i sådan detalj) så får man höra att det inte är så viktigt för det kommer ändå att bytas ut snart i alla fall.

Visst kan en bra utvecklare byta språk eller ramverk utan större problem, men frågan är hur effektivt det är liksom. Ständiga diskussioner om vad som är bästa lösningen eller tekniken för ett specifikt problem tar inte bara tid utan också energi från utvecklarteamen exempelvis. Och man får ju se till vilken kompetens som finns tillgänglig, både inom företaget men också som går att rekrytera och så.

Mitt team var exempelvis tänkt att bygga en mjukvara som ersatte delar av en tredjepartsmjukvara som alla tycker är kass och föråldrad och som håller tillbaka oss på en massa områden. Alltså har teamet haft bland annat en utvecklare som doktorerat inom just denna typ av algoritmer, en grym integrationsutvecklare för att få sakerna att fungera ihop, en testkonsult med expertis inom just automatisering av den typen av tester som vi behöver och så vidare. Alltså ett väldigt bra team för den specifika uppgift vi hade. Sen byttes chefer ut och vi anställde en före detta chef från företaget som byggde denna tredjepartsmjukvara, oklart vad hans roll var tänkt att vara, som agerar som ifall han fortfarande fick betalt av dem och av någon anledning så lyssnar cheferna på denna person, så de la ned vårt projekt innan vi hade fått en riktig chans att visa hur mycket bättre än det befintliga det var. Alltså sitter jag med ett team som är experter på ett område som inte är relevant längre (eller satt med i alla fall, de bästa har förstås sagt upp sig nu). Många turer senare så jobbar vi nu med att bygga simpla gränssnitt i Angular och hyfsat triviala micro services. Jag säger inte att det inte går, vi kan hantera sakerna vi har att göra, men det känns som slöseri med kompetens och väldigt ineffektivt. Som att anställa ett gäng grymma kockar till sin lyxrestaurang och sen byta inriktning till ett simpelt gatukök men behålla kockarna. "Ni är ju grymma kockar! Ni kan säkert hantera att vända burgare...".

Citat:

Bra kod tenderar leva både en, två och tre decennium. Bra programmerare kommer inte ha något problem att lära sig ny teknik och om inte annat är anställda typiskt mer volatila än resultatet av ett någorlunda lyckat projekt.

Jo men ska kod leva länge så måste den bli klar. Man kan inte byta tekniken varje månad för att det kommer något nytt som, i teorin i alla fall, passar bättre för att lösa problemet. Nu är språk inte så flyktiga för det mesta, men det finns ju många mindre komponenter eller bibliotek som man lägger tid på att implementera och så där det alltid finns något bättre runt hörnet liksom.

Citat:

Så enda problemet här är just: är väldigt sällan man faktiskt har möjlighet att starta med blankt papper. När det händer, för mig har det hänt några gånger i karriären, finns ingen anledningen att inte dra maximal nytta av tillfället. Kommer få använda Rust just p.g.a. at detta i höst (hyfsat prestandakritisk fall som startas från scratch, så står mellan C++17 eller Rust2018)

Nej så är det absolut. Men även när man faktiskt börjar på "helt ny kula" så är det ju samma organisation liksom, och då är det lätt att man faller tillbaka i samma mönster som ställde till det tidigare. Vi bytte ut en hemsk monolit som krävde anpassningar i kod för i princip varje kund till något som enligt visionen skulle vara standardiserat och konfigurerbart. Men en del av de utvecklare som jobbat i tre-fem år med monoliten och lärt sig hur den fungerar drar hela tiden den nya kodbasen mot samma skitlösningar som den förra bestod av.

Citat:

Angående det sista: självklart är det bara anpassa sig, i detta fall fick det bli "är 'tillräckligt' snabbt ändå". Men för egen del känns det fel att lämna så pass mycket prestanda på bordet, men man måste vara pragmatisk...

Jo. Någonstans är ju inte prestandakraven lika höga idag på många områden, i relation till tillgänglig prestanda alltså, samtidigt lyckas man ju för det mesta äta upp alla prestandaförbättringar genom nya "smarta" lösningar. Microservices är jättetrevligt exempelvis och de skalar ju bra över flera maskiner och så, men när det gäller hur mycket prestanda som krävs för att göra några enkla uppgifter så är det ju någonstans mellan en katastrof och "inte jättedåligt" beroende på hur bra man har lyckats med implementationen.

Permalänk
Datavetare
Skrivet av heretic16:

Jag föredrar den övre koden, för de innehåller ett "main". Då vet man vart man ska börja. Hade jag fått bestämma så hade C# skrivits så här.

Vad tycker du om Java ME då? Dött?

Aldrig använt Java ME, så ingen aning.

Lite google ger: verkar som Nokia sitter vid rodret för Java ME, senaste uppdatering av standard 2009? Så totalt stendött?

Närmaste jag kommit Java ME är att jobbat med att få in någon embedded variant av Java i VxWorks. I efterhand visade det sig nog vara ett typexempel på XY-problemet. Vissa kunder noterade att det finns långt fler utvecklare som kan Java än som kan C eller C++, samtidigt "visste" de att man kan vara mer produkt i Java jämfört med framförallt C men även "gamla" C++.

Problemet är att om man vill ha något som faktiskt påminner om Java och på något sätt använda "vanlig" Java-kod måste man minst behålla GC. Med GC är det totalkört att erbjuda hård realtid. Om man inte behöver hård realtid, varför ska man då köra med ett RTOS?

Finns absolut saker man kan göra på ett RTOS där det finns bättre alternativ än C, C++ (och nu för tiden Rust). Ett uppenbart sådant är Python, VxWorks stödjer just av den anledningen Python3 "out-of-the-box". Rätt svar för de som hoppades på Java är naturligtvis "modern C++" och/eller Rust, båda dessa stöds och Java-stödet levde bara några år.

Men som sagt: har ingen aning om status hos Java ME.

Skrivet av snajk:

Nja, samtidigt blir ju vad man än väljer en kompromiss någonstans liksom. Vill man alltid ha den bästa tekniken riskerar man att hamna i andra problem istället. Jag lever varje dag med konsekvenserna av arkitekter som tycker det är viktigare att använda nya coola/smarta lösningar än att faktiskt bli färdig eller bygga saker bra från början exempelvis. Börjar man ställa frågor, eller kanske snarare kräva svar på ens frågor, om arkitekturen eller strukturen eller varför vi ska använda en specifik teknik (när det går emot arbetsmetodiken att styra i sådan detalj) så får man höra att det inte är så viktigt för det kommer ändå att bytas ut snart i alla fall.

Visst kan en bra utvecklare byta språk eller ramverk utan större problem, men frågan är hur effektivt det är liksom. Ständiga diskussioner om vad som är bästa lösningen eller tekniken för ett specifikt problem tar inte bara tid utan också energi från utvecklarteamen exempelvis. Och man får ju se till vilken kompetens som finns tillgänglig, både inom företaget men också som går att rekrytera och så.

Mitt team var exempelvis tänkt att bygga en mjukvara som ersatte delar av en tredjepartsmjukvara som alla tycker är kass och föråldrad och som håller tillbaka oss på en massa områden. Alltså har teamet haft bland annat en utvecklare som doktorerat inom just denna typ av algoritmer, en grym integrationsutvecklare för att få sakerna att fungera ihop, en testkonsult med expertis inom just automatisering av den typen av tester som vi behöver och så vidare. Alltså ett väldigt bra team för den specifika uppgift vi hade. Sen byttes chefer ut och vi anställde en före detta chef från företaget som byggde denna tredjepartsmjukvara, oklart vad hans roll var tänkt att vara, som agerar som ifall han fortfarande fick betalt av dem och av någon anledning så lyssnar cheferna på denna person, så de la ned vårt projekt innan vi hade fått en riktig chans att visa hur mycket bättre än det befintliga det var. Alltså sitter jag med ett team som är experter på ett område som inte är relevant längre (eller satt med i alla fall, de bästa har förstås sagt upp sig nu). Många turer senare så jobbar vi nu med att bygga simpla gränssnitt i Angular och hyfsat triviala micro services. Jag säger inte att det inte går, vi kan hantera sakerna vi har att göra, men det känns som slöseri med kompetens och väldigt ineffektivt. Som att anställa ett gäng grymma kockar till sin lyxrestaurang och sen byta inriktning till ett simpelt gatukök men behålla kockarna. "Ni är ju grymma kockar! Ni kan säkert hantera att vända burgare...".
Jo men ska kod leva länge så måste den bli klar. Man kan inte byta tekniken varje månad för att det kommer något nytt som, i teorin i alla fall, passar bättre för att lösa problemet. Nu är språk inte så flyktiga för det mesta, men det finns ju många mindre komponenter eller bibliotek som man lägger tid på att implementera och så där det alltid finns något bättre runt hörnet liksom.
Nej så är det absolut. Men även när man faktiskt börjar på "helt ny kula" så är det ju samma organisation liksom, och då är det lätt att man faller tillbaka i samma mönster som ställde till det tidigare. Vi bytte ut en hemsk monolit som krävde anpassningar i kod för i princip varje kund till något som enligt visionen skulle vara standardiserat och konfigurerbart. Men en del av de utvecklare som jobbat i tre-fem år med monoliten och lärt sig hur den fungerar drar hela tiden den nya kodbasen mot samma skitlösningar som den förra bestod av.
Jo. Någonstans är ju inte prestandakraven lika höga idag på många områden, i relation till tillgänglig prestanda alltså, samtidigt lyckas man ju för det mesta äta upp alla prestandaförbättringar genom nya "smarta" lösningar. Microservices är jättetrevligt exempelvis och de skalar ju bra över flera maskiner och så, men när det gäller hur mycket prestanda som krävs för att göra några enkla uppgifter så är det ju någonstans mellan en katastrof och "inte jättedåligt" beroende på hur bra man har lyckats med implementationen.

Fast gav du inte just flera lysande exempel på varför det är en anti-pattern att inte välja det man identifierat som bästa teknik?

Bästa teknik är väldigt sällan "det senaste coola ramverk som ingen kommer minnas tre år från nu". Men självklart kan det vara lockade för vissa att hoppa på sådant, gör man det som arkitekt kanske man inte är någon vidare arkitekt?

Du ger exempel där du hade ett team med domänexperter. Det är ju ett skolboksfall där man definitivt inte ska hålla fast vid ett specifik språk eller ramverk "för vi använder ju alltid det", domänexpertisen är exempel på saker som utan problem flyttas mellan programspråk/ramverk.

På förra jobbet fick jag kämpa rätt länge för att vi skulle välja "modern C++" ihop med Google Test (och jag valde Google Test specifikt då det hade "proven track record", finns "sexigare" projekt...) som ramverk att skriva unit-tester. Mothuggen var: men våra utvecklare är ju primärt C-programmerare. Problemet är att det inte finns några vettiga unit-test ramverk skrivna i C och en fördel med C++ är att det är trivialt att anropa C-kod därifrån.

Med "modern C++" blev det också enkelt att göra mock-ing, det gick att göra ett klisterlager som gjorde det otroligt intuitivt att sätta upp förväntat beteende hos koden med Google Test ramverket. Det så faktiskt rätt "C-aktigt" ut, även om det under huven fanns en hel del "C++ magi" för att få till den känslan.

De som enbart använde ramverket behövde förstå väldigt lite C++. De som klarade av det hela sämst var, föga oväntat, de som hade utdaterad kunskap om C++. De som aldrig sett C++ lärde sig snabbt den lilla delmängd av C++14 som behövdes.

Sökte också lite på AUTOSAR ihop med Rust. AUTOSAR innehåller en stor mängd regler kring hur man bör skriva C++ för att det ska fungera i säkerhetkritiska miljöer. Finns företag som lever på att bygga verktyg som m.h.a. statisk analys verifierar en stor andel att dessa regler följs i praktiken.

Det som vissa noterat är att en rätt stor andel av dessa regler skulle överhuvudtaget inte behövas om man går till Rust, därför att det man försöker skydda sig emot är just sådana saker som Rust specifikt designats för att hantera. D.v.s. kod som bryter mot flertalet av AUTOSAR reglerna skulle inte kompilera i Rust, m.a.o. automatiskt verifikation enbart genom "rätt" val av teknik.

Permalänk
Medlem
Skrivet av heretic16:

Jag har kört många olika språk. Jag kör dagligen C för inbyggda system där jag själv gör kretskorten för hand.

Annars så har jag kört:
Visual Basic.NET
JavaFX
Arduino
STM32
Spring Boot
C++
C
Python

osv

Jag efterfrågar bara efter vad marknaden efterfrågar.

Jag får inte riktigt ihop dina inlägg. Du skriver att du har bra koll på C och använder det dagligen. I inlägget jag citerar skriver du att du kört C++, sen några inlägg senare skriver du att du har 0% koll på C++.

Sen att inte få igång GIT i VS Code, oavsett vad du föredrar för IDE så bör alla utvecklare fixa det. Det enda som krävs är att installera, klart. Vill man ha det integrerat mot GitHub loggar man in.

Dina inlägg ger en otroligt splittrad bild av din kunskapsnivå.

Men för att ge min syn på saken. Att lära sig ett språk gör inte att man blir utvecklare, men är man utvecklare så kan man någorlunda lätt komma igång med ett språk. Dessutom om du kan C så bra som du skriver, då bör i stort sett vilket språk som helst inte vara några problem att komma igång med.

Ang. arbetsmarknad, sluta tänka på språk / ramverk. Du kan ju C, varför inte jobba med det?
Även om inte C ligger i topp när det gäller platsannonser så betyder inte det att det inte finns ett behov av det. De flesta jobb som utvecklare annonseras inte ens ut.

Om du har svårt att hitta jobb inom C, prova kontakta några rekryteringsbolag så löser det sig.

Men ett tips, när du är på intervju, säg inte att du är grym på C men fattar inget av C++ eller javascript.