Välja programmeringsspråk

[JohanLun]

följer tråden då jag började som mjukvaruutvecklare (eller vad man nu vill kalla det) men när man fick nån över sig som sa både vad och hur man skulle göra och man inte höll med... så tröttnade jag... Och bytte väl roll till en där man projektleder andra, men nu är det inte så mycket mjukvara längre - iallafall är jag så långt bort från utvecklarna att jag inte vet vad de gör... När jag höll på med programmering som hobby och som "egen" så var det skitkul.

...fast som ingenjör så är det lite så att jag faktiskt längtar tillbaka till att själv få utveckla... Men jag vet inte om resan "tillbaka" är möjlig att göra... att det nog är bättre att börja programmera som hobby...

att bli en sån utvecklare som får en spec i handen och ska koda enligt specen, det vill jag inte bli och tyvärr måste man nog börja där om man ska jobba med programmering igen... eller nöja sig att projektleda... jag kan dock tänka mig att om man är i ett mycket avgränsat område där det bara är ett par tre utvecklare totalt så kan det nog vara kul och möjligt att komma in i det igen...

Men, med allt nytt som kommit sen jag höll på ca 2000 så kanske det har blivit bättre. På den tiden behövde man förstå och optimera koden mot hårdvaran, men det gjorde många inte. Jag som kom från assembler och hårdvarunära programmering blev bara frustrerad hur jäkla uselt allt blev för att man var fast i att återanvända urusla färdiga komponenter. Nu misstänker jag att man antingen väljer att jobba hårdvarunära, eller att lösa logiska problem. Att man inte kräver båda, vilket kanske gör att utvecklarna mer hittar den miljö de vill jobba i.

Vore kul att höra om det finns några exempel på folk som "på gamla dar" gått tillbaka till eller börjat programmera och lyckats få kvalificerade uppgifter rätt snabbt...

 

[AndersMalmgren]

följer tråden då jag började som mjukvaruutvecklare (eller vad man nu vill kalla det) men när man fick nån över sig som sa både vad och hur man skulle göra och man inte höll med... så tröttnade jag... Och bytte väl roll till en där man projektleder andra, men nu är det inte så mycket mjukvara längre - iallafall är jag så långt bort från utvecklarna att jag inte vet vad de gör... När jag höll på med programmering som hobby och som "egen" så var det skitkul.

...fast som ingenjör så är det lite så att jag faktiskt längtar tillbaka till att själv få utveckla... Men jag vet inte om resan "tillbaka" är möjlig att göra... att det nog är bättre att börja programmera som hobby...

att bli en sån utvecklare som får en spec i handen och ska koda enligt specen, det vill jag inte bli och tyvärr måste man nog börja där om man ska jobba med programmering igen... eller nöja sig att projektleda... jag kan dock tänka mig att om man är i ett mycket avgränsat område där det bara är ett par tre utvecklare totalt så kan det nog vara kul och möjligt att komma in i det igen...

Men, med allt nytt som kommit sen jag höll på ca 2000 så kanske det har blivit bättre. På den tiden behövde man förstå och optimera koden mot hårdvaran, men det gjorde många inte. Jag som kom från assembler och hårdvarunära programmering blev bara frustrerad hur jäkla uselt allt blev för att man var fast i att återanvända urusla färdiga komponenter. Nu misstänker jag att man antingen väljer att jobba hårdvarunära, eller att lösa logiska problem. Att man inte kräver båda, vilket kanske gör att utvecklarna mer hittar den miljö de vill jobba i.

Vore kul att höra om det finns några exempel på folk som "på gamla dar" gått tillbaka till eller börjat programmera och lyckats få kvalificerade uppgifter rätt snabbt...

Jag tar bara Systemarkitekt / tech lead-uppdrag. Eftersom man då är ansvarig för arkitekturen så får man bestämma i princip allt. Beror ju lite på kunden självklart. Men jag har då inte haft något problem. PÅ något uppdrag har de velat att man ska använda något mossigt intern-ramverk. Men då har man ju bara sett till att skrota den policyn.

 

[anders07]

följer tråden då jag började som mjukvaruutvecklare (eller vad man nu vill kalla det) men när man fick nån över sig som sa både vad och hur man skulle göra och man inte höll med... så tröttnade jag... Och bytte väl roll till en där man projektleder andra, men nu är det inte så mycket mjukvara längre - iallafall är jag så långt bort från utvecklarna att jag inte vet vad de gör... När jag höll på med programmering som hobby och som "egen" så var det skitkul.

...fast som ingenjör så är det lite så att jag faktiskt längtar tillbaka till att själv få utveckla... Men jag vet inte om resan "tillbaka" är möjlig att göra... att det nog är bättre att börja programmera som hobby...

att bli en sån utvecklare som får en spec i handen och ska koda enligt specen, det vill jag inte bli och tyvärr måste man nog börja där om man ska jobba med programmering igen... eller nöja sig att projektleda... jag kan dock tänka mig att om man är i ett mycket avgränsat område där det bara är ett par tre utvecklare totalt så kan det nog vara kul och möjligt att komma in i det igen...

Men, med allt nytt som kommit sen jag höll på ca 2000 så kanske det har blivit bättre. På den tiden behövde man förstå och optimera koden mot hårdvaran, men det gjorde många inte. Jag som kom från assembler och hårdvarunära programmering blev bara frustrerad hur jäkla uselt allt blev för att man var fast i att återanvända urusla färdiga komponenter. Nu misstänker jag att man antingen väljer att jobba hårdvarunära, eller att lösa logiska problem. Att man inte kräver båda, vilket kanske gör att utvecklarna mer hittar den miljö de vill jobba i.

Vore kul att höra om det finns några exempel på folk som "på gamla dar" gått tillbaka till eller börjat programmera och lyckats få kvalificerade uppgifter rätt snabbt...

Jag började som programmerare, efter drygt 10 år blev jag lösningsarkitekt och körde som konsult i drygt 10 år.
Sedan 6 år tillbaka tog jag rollen jag har idag som CTO men jag programmerar ca. 50% av min arbetstid för det är vad jag tycker är roligast!

 

[skaraborgsfakir]

Men ganska begränsad använding i arbetslivet.
Dock lite beroende av vilken sektor man jobbar i såklart.

Hmm, jag vet inte . Med tanke på hur mycket IBM nu försöker kränga Python för z/OS-miljön (som lockvara mot programmerare/utvecklare från Linux-sidan) likaså är RH ganska mycket igång med samma sak men för Linux.

IBM har iofs ganska länge puffat för Java i de miljöerna (inklusive i AS/400 / iSeries.)

 

[Danieln84]

Om pengar är din drivkraft skulle jag säga lär dig Cobol. En Cobol-guru bestämmer själv hur mycket han vill ta betalt.
Är det teknik som driver dig finns det sannolikt bättre förslag.

/Höghus

Jag tycker nog att det är lite överdrivet. Visst, storbanker kör fortfarande mainframe men på de 7 år som jag har arbetat med stordator har flera större aktörer bytt plattform - t ex polisen, SJ, södra skogsägarna. Även lantmäteriet är på god väg om de inte redan är klara. Men visst, det är stora pensionsavgångar nu, så det finns fortfarande ett behov.

För att, som konsult, lösa ett akut problem kan man såklart ta bra betalt men det är ju inga längre uppdrag då.

Jag jobbar med COBOL, JCL, viss kunskap om IBM MQ köhanterare i stordator samt en hel del med databas och transaktionshanteraren CA IDMS. Tycker det är en intressant miljö men det är inget jag skulle rekommendera någon som vill skola om sig att satsa på. Jag gled in på ett bananskal utan att ha någon it-bakgrund då jag jobbade på företaget i fråga fast med helt andra saker.

 

[AndersMalmgren]

Hmm, jag vet inte . Med tanke på hur mycket IBM nu försöker kränga Python för z/OS-miljön (som lockvara mot programmerare/utvecklare från Linux-sidan) likaså är RH ganska mycket igång med samma sak men för Linux.

IBM har iofs ganska länge puffat för Java i de miljöerna (inklusive i AS/400 / iSeries.)

Har inte jobbat med stordator/AS400 sedan typ 2011 så ingen koll på den marknaden idag. Men det är ju mest gamla banker som kör det. Molntjänster som Azure är ju vanligare idag skulle jag säga men det beror ju lite på sektor osv.

 

[AndersMalmgren]

Jag tycker nog att det är lite överdrivet. Visst, storbanker kör fortfarande mainframe men på de 7 år som jag har arbetat med stordator har flera större aktörer bytt plattform - t ex polisen, SJ, södra skogsägarna. Även lantmäteriet är på god väg om de inte redan är klara. Men visst, det är stora pensionsavgångar nu, så det finns fortfarande ett behov.

För att, som konsult, lösa ett akut problem kan man såklart ta bra betalt men det är ju inga längre uppdrag då.

Jag jobbar med COBOL, JCL, viss kunskap om IBM MQ köhanterare i stordator samt en hel del med databas och transaktionshanteraren CA IDMS. Tycker det är en intressant miljö men det är inget jag skulle rekommendera någon som vill skola om sig att satsa på. Jag gled in på ett bananskal utan att ha någon it-bakgrund då jag jobbade på företaget i fråga fast med helt andra saker.

Är det SHB du jobbar på? Mins det var många gamla omskolade ekonomer som satt på kobolt-sidan där

 

[Danieln84]

Är det SHB du jobbar på? Mins det var många gamla omskolade ekonomer som satt på kobolt-sidan där

Nix, jag jobbar på en större tillverkningsindustri

Vi har ett egenutvecklat stordatorbaserat ERP som firar 40 år i år, och vi är ett team på (ungefär) 8 utvecklare som förvaltar och vidareutvecklar det. Men det är samma sak hos oss, de flesta i gruppen kommer från verksamhetssidan då det är mer värt att få in någon med bred verksamhetskunskap med rätt intresse än någon som råkar kunna Cobol, jcl, ispf/PDF osv om man nu mot förmodan råkar hitta någon sådan.

 

[MrJay]

Det är ju fortfarande c# vilket i grunden är OOP. Men de flesta seniora utvecklare kodar mer funktionellt eller producurellt. Även inom OOP så frångår man mycket av de klassiska problemen tex använder man komposition istället för arv (Composition over inheritance). Själv kör jag ganska funktionellt även i C#

Exempel från min domän på jobbet

public class RefundStrategy : IAmountDeviationStrategy
{
   public AmountDeviationStrategy Strategy => AmountDeviationStrategy.Refund;

   public PaymentInvoiceMatchResult Execute(MatchJob job)
   {
       if (job.Diff < 0)
           return new PaymentInvoiceMatchResultBuilder(job)
               .PaymentCategory(PaymentCategory.WrongPayment)
               .RefundAll(RefundReason.UnderPaid);

       var invoiceAmount = Math.Abs(job.Invoice.Amount);
       var payingPayments = GetPaymentsComboClosestToInvoiceAmount(job.Payments, invoiceAmount);

       var refunds = job.Payments.Except(payingPayments).ToList();
       var result = new PaymentInvoiceMatchResultBuilder(job, refunds)
           .PaymentCategory(PaymentCategory.WrongPayment)
           .Refund(refunds);

       if (payingPayments.Sum(p => p.Amount) != invoiceAmount)
           result.Refund<RefundSplitPaymentCommand>(payingPayments.First(p => p.Amount >= job.Diff), split => split.Amount = payingPayments.Sum(p => p.Amount) - invoiceAmount);

       return result
           .QueueCommand(new MapInvoicePaymentsCommand { InvoiceId = job.Invoice.ExternalId, Payments = payingPayments.Select(p => p.ExternalId) });
   }

   private IReadOnlyCollection<IPaymentMatchInfo> GetPaymentsComboClosestToInvoiceAmount(IReadOnlyCollection<IPaymentMatchInfo> payments, decimal invoiceAmount)
   {
       var combos = Enumerable.Range(1, payments.Count)
           .SelectMany(i => new Combinations<IPaymentMatchInfo>(payments, new ReferenceCompare<IPaymentMatchInfo>(), i))
           .ToList();

       var payingPayments = combos
           .Where(c => c.Sum(p => p.Amount) >= invoiceAmount)
           .OrderBy(combo => Math.Abs(combo.Sum(p => p.Amount) - invoiceAmount))
           .First();

       return payingPayments;
   }

Hmm, du bryter ingen NDA genom att publicera kod som tillhör kund i ett publikt forum?

 

[AndersMalmgren]

Hmm, du bryter ingen NDA genom att publicera kod som tillhör kund i ett publikt forum?

Inte den där koden nej.
Brukar även blogga koden jag skriver för kunder tex

https://andersmalmgren.com/2019/03/20/flexible-integration-tests-with-dacpac-support/

Eller

https://andersmalmgren.com/2020/08/...currency-management-in-entity-framework-core/


Det avslöjar inte kundens domän

 

[tommib]

Utmaningen där är nog snarast att tränga igenom den massiva teknikfientligheten när det gäller allt inom medicinskt diagnosstöd.

Visste ni t.ex. att en patient inte får vistas närmare än X antal meter från ett journalsystem?

Det är ju bara ett stöd, fortfarande en mänsklig läkare som granskar diagnosen. Förstår inte hur man kan vara motståndare till det.

Detta blir ju rätt OT för tråden men jag kan slänga in min syn på det hela.

På det hela taget är läkarkåren i någon mån teknikfientlig, det måste jag hålla med om. Detta gäller framför allt de äldre läkarna. De yngre är istället otroligt teknikoptimistiska och har svårt att se riskerna med t.ex. att alla har en smartphone för kommunikation. Jag intar personligen något slags mellanposition där jag ser stora fördelar med ML och "AI"/Expertsystem men samtidigt ser stora problem med den data som ska matas in i dessa system och hur systemen sedan ska kommunicera resultatet till de som ska använda det.

För att ta ett exempel, som vi diskuterade en hel del när jag jobbade med FVM för några år sedan: Du har ett beslutsstöd som ska hjälpa dig att detektera t.ex. ett riskbeteende hos en patient. Vilken information matar du detta beslutsstöd med? Allt som finns i systemet? Allt som du får se i "din" sekretessbubbla? Ja, vi har avgränsningar i våra journalsystem där jag bara får se det som hör till min bubbla. I praktiken är det min vårdenhet. Denna begränsning kan jag sedan överskrida genom att klicka i en liten ruta i gränssnittet och då får jag se allt som hör till min vårdgivare. Med patientens explicita medgivande (eller i en nödsituation) kan jag sedan klicka i en ytterligare ruta där jag får se även de andra vårdgivarna i vårt system (t.ex. andra sjukhus). Dessutom finns det dolda vårdenheter som jag aldrig kan se om jag inte specifikt är inloggad på dem, oavsett vad jag klickar i. Om svaret på frågan är att beslutsstödet får se det jag ser så har det inte komplett information och kommer sannolikt dra felaktiga slutsatser. Om beslutsstödet får se mer än mig så kan det landa i slutsatser som jag inte kan förstå (och därmed inte kommer följa). Ett neuralt nätverk kommer nästan oavsett kunna generera slutsatser som är obegripliga i betydelsen att jag inte kan förstå vad som ledde till en viss slutsats. Att blint följa uppmaningen från ett system är rätt riskabelt.

Ett annat exempel från min specifika specialitet är anestesidjupsmonitorer, t.ex. BIS. Det är mer av karaktären medicinteknisk utrustning och här kommer det cpalm pratade om in. Det handlar inte om att journalsystem inte får vara närmare patienten än två meter. Det handlar om att elektronisk utrustning som är närmare än så klassas som medicinteknisk utrustning och hanteras på ett annat sätt än annan IT-utrustning. Regelverket kring den är t.ex. betydligt besvärligare och därför vill man inte ha datorer nära patienten eftersom de blir dyrare och sämre. För den specifika apparaten, BIS, så är problemet att det är en svart låda. Den tittar på EEG och gör lite magi med det för att få fram en siffra. Denna siffra ska representera anestesidjupet. Hög siffra, patienten vaken, låg siffra patienten sövd. Tillverkaren publicerar inte sin algoritm för detta och det gör att jag (och större delen av mina kollegor) blir misstänksamma mot den. Om vi inte kan förstå hur siffran genereras vill vi inte använda den. Dessutom visar just den apparaten väldigt tveksamma resultat i studier.

Sedan håller jag också med om det @fredrik.johansson skriver. Vi är väldigt vana vid att IT-systemen i huvudsak är ett hinder som ska övervinnas och att de försvårar för oss att göra ett bra arbete. Inte så att vi är ludditer men när man ska mata in en orimlig mängd siffror och rutindata (=skit som borde gå in automatiskt) för att t.ex. mata ett framtida ML/AI-system så blir vi lite anti. Jag tror att det är svårt att förstå hur usla system vi ibland jobbar i. Det systemet vi har i region stockholm (TakeCare) är överlägset det minst usla jag har jobbat med och formuleringen är helt avsiktlig. Det sämsta är nog BMS/Systeam Cross som är ett aktivt hinder i arbetet.

Precis, läs på lite vad IBM gjort i USA med diagnostisering av tex hjärtsjukdomar och cancerdiagnoser. Rätt coolt!

Läs lite till om watson for oncology failure...
https://spectrum.ieee.org/how-ibm-watson-overpromised-and-underdelivered-on-ai-health-care
https://www.technologynetworks.com/...atson-why-hasnt-ai-taken-over-oncology-333571
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7105853/
Det är tyvärr klyddigt med medicin.

Jag tror absolut att det finns en framtid för AI/ML inom sjukvården, men det är en lång uppförsbacke till de spektakulära applikationerna.



TS, jag ber om ursäkt för den långa utvikningen.

 

[AndersMalmgren]

Detta blir ju rätt OT för tråden men jag kan slänga in min syn på det hela.

På det hela taget är läkarkåren i någon mån teknikfientlig, det måste jag hålla med om. Detta gäller framför allt de äldre läkarna. De yngre är istället otroligt teknikoptimistiska och har svårt att se riskerna med t.ex. att alla har en smartphone för kommunikation. Jag intar personligen något slags mellanposition där jag ser stora fördelar med ML och "AI"/Expertsystem men samtidigt ser stora problem med den data som ska matas in i dessa system och hur systemen sedan ska kommunicera resultatet till de som ska använda det.

För att ta ett exempel, som vi diskuterade en hel del när jag jobbade med FVM för några år sedan: Du har ett beslutsstöd som ska hjälpa dig att detektera t.ex. ett riskbeteende hos en patient. Vilken information matar du detta beslutsstöd med? Allt som finns i systemet? Allt som du får se i "din" sekretessbubbla? Ja, vi har avgränsningar i våra journalsystem där jag bara får se det som hör till min bubbla. I praktiken är det min vårdenhet. Denna begränsning kan jag sedan överskrida genom att klicka i en liten ruta i gränssnittet och då får jag se allt som hör till min vårdgivare. Med patientens explicita medgivande (eller i en nödsituation) kan jag sedan klicka i en ytterligare ruta där jag får se även de andra vårdgivarna i vårt system (t.ex. andra sjukhus). Dessutom finns det dolda vårdenheter som jag aldrig kan se om jag inte specifikt är inloggad på dem, oavsett vad jag klickar i. Om svaret på frågan är att beslutsstödet får se det jag ser så har det inte komplett information och kommer sannolikt dra felaktiga slutsatser. Om beslutsstödet får se mer än mig så kan det landa i slutsatser som jag inte kan förstå (och därmed inte kommer följa). Ett neuralt nätverk kommer nästan oavsett kunna generera slutsatser som är obegripliga i betydelsen att jag inte kan förstå vad som ledde till en viss slutsats. Att blint följa uppmaningen från ett system är rätt riskabelt.

Ett annat exempel från min specifika specialitet är anestesidjupsmonitorer, t.ex. BIS. Det är mer av karaktären medicinteknisk utrustning och här kommer det cpalm pratade om in. Det handlar inte om att journalsystem inte får vara närmare patienten än två meter. Det handlar om att elektronisk utrustning som är närmare än så klassas som medicinteknisk utrustning och hanteras på ett annat sätt än annan IT-utrustning. Regelverket kring den är t.ex. betydligt besvärligare och därför vill man inte ha datorer nära patienten eftersom de blir dyrare och sämre. För den specifika apparaten, BIS, så är problemet att det är en svart låda. Den tittar på EEG och gör lite magi med det för att få fram en siffra. Denna siffra ska representera anestesidjupet. Hög siffra, patienten vaken, låg siffra patienten sövd. Tillverkaren publicerar inte sin algoritm för detta och det gör att jag (och större delen av mina kollegor) blir misstänksamma mot den. Om vi inte kan förstå hur siffran genereras vill vi inte använda den. Dessutom visar just den apparaten väldigt tveksamma resultat i studier.

Sedan håller jag också med om det @fredrik.johansson skriver. Vi är väldigt vana vid att IT-systemen i huvudsak är ett hinder som ska övervinnas och att de försvårar för oss att göra ett bra arbete. Inte så att vi är ludditer men när man ska mata in en orimlig mängd siffror och rutindata (=skit som borde gå in automatiskt) för att t.ex. mata ett framtida ML/AI-system så blir vi lite anti. Jag tror att det är svårt att förstå hur usla system vi ibland jobbar i. Det systemet vi har i region stockholm (TakeCare) är överlägset det minst usla jag har jobbat med och formuleringen är helt avsiktlig. Det sämsta är nog BMS/Systeam Cross som är ett aktivt hinder i arbetet.



Läs lite till om watson for oncology failure...
[länk]
[länk]
[länk]
Det är tyvärr klyddigt med medicin.

Jag tror absolut att det finns en framtid för AI/ML inom sjukvården, men det är en lång uppförsbacke till de spektakulära applikationerna.



TS, jag ber om ursäkt för den långa utvikningen.

Tycker inte det är OT då TS är intresserad av just ML inom medicin

 

[tommib]

Då kan jag komplettera mitt väldigt röriga inlägg med att det som används mest inom ML/AI i medicin är Python och R (som jag tror att någon redan nämnde). För att skriva R-bibliotek så är det mest C/C++ som gäller utöver R, om man behöver något som inte redan finns.

 

[guggen]

Python är väl fortfarande överlägset störst inom ml pga av just att de första vettiga libbarna för ml kom just till Python. Oavsett om man snurrar det på aws, Azure eller egna lådor. Ganska kul att ett dött språk som Python seglat upp och på senare år blivit ett av världens mest använda språk just pga av detta (körde själv lite Python på skoj när det kom i slutet av nittiotalet). Eg samma sak med objektive c för några år sedan, helt dött tills Steve lanserade en lur där man initialt var tvungen att bygga alla appar i oc, tidigare något man bara lärde och använde sig i plugget före c++ tiden.
Så jag håller med, språket i sig är inte så viktigt, är man duktig behärskar man eller åtminstone förstår ett flertal. Så välj ett som inte gör starten på karriären för svår.
JavaScript och Node är nog ett bra val (och man överlever inte därute utan grundläggande kunskap i js).
Min nya personliga favorit är Go, kompakt och compilerande (native, det finns pekare!), sjukt liten footprint för micro services. Skrivet av bla en av skaparna av C. Lätt att komma igång med men svårt att behärska.

 

[sjoelund]

Python är väl fortfarande överlägset störst inom ml pga av just att de första vettiga libbarna för ml kom just till Python. Oavsett om man snurrar det på aws, Azure eller egna lådor. Ganska kul att ett dött språk som Python seglat upp och på senare år blivit ett av världens mest använda språk just pga av detta (körde själv lite Python på skoj när det kom i slutet av nittiotalet). Eg samma sak med objektive c för några år sedan, helt dött tills Steve lanserade en lur där man initialt var tvungen att bygga alla appar i oc, tidigare något man bara lärde och använde sig i plugget före c++ tiden.
Så jag håller med, språket i sig är inte så viktigt, är man duktig behärskar man eller åtminstone förstår ett flertal. Så välj ett som inte gör starten på karriären för svår.
JavaScript och Node är nog ett bra val (och man överlever inte därute utan grundläggande kunskap i js).
Min nya personliga favorit är Go, kompakt och compilerande (native, det finns pekare!), sjukt liten footprint för micro services. Skrivet av bla en av skaparna av C. Lätt att komma igång med men svårt att behärska.

Python var aldrig döende och blev inte populär för att ML-ramverk kom till Python. De kom till Python för Python var populärt.
Egentligen är Python rätt långsamt, men det är snabbt att köras eftersom det inte behöver kompileras om och bra att göra prototyper i. Hastigheten man får är för att nästan alla viktiga Python-bibliotek använder sig av C i grunden och man mest skriver små script som använder sig av bibliotek.

Vill man få riktig snabb ML-kod skriver man den i Julia. Men det är långsammare för små prototyper eftersom man behöver JIT-kompilera hela tiden... Python är mycket enklare att lära sig eftersom man kan köra små program snabbare, och är ett mycket bra val om man vill lära sig ett språk för att automatisera uppgifter på jobbet. Lite som att Excel är smidigt att använda om man får en massa data i tabeller och behöver beräkna något genomsnitt enkelt.