QT Creator VS Visual Studio

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.

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.

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.

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.

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

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?

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.