ett svårlöst problem vid programkörning: det att resultatet av programkörningen förändras beroende på tid och ordningsföljd för indata: det kan antingen bero på exakt på mikrosekunden när indata blir inlästa eller på i vilken ordning de blir inlästa. Detta förutsätts vara något som programmeraren inte kan påverka. – Race conditions nämns ofta som exempel på heisenbuggar: när man försöker rätta till dem försvinner de – för att senare återkomma. Att förebygga och rätta till race conditions är ett klassiskt problem i datorvetenskap. (Se också funnel.) Någon etablerad svensk översättning av race condition finns inte, förutom den ovanliga termen loppskick med oklar förklaring. – Jämför med data race, se kapplöpning.
[datorvetenskap] [programkörning] [ändrad 17 maj 2020]
datakapplöpning, kapplöpningsproblem, på engelska: data race – det att två eller flera trådar i samma process samtidigt försöker få tillgång till samma del av minnet. Om den ena tråden ska läsa och den andra ska skriva kan resultatet bli helt olika, beroende på vilken tråd som kommer åt minnet först. – Läs också om race condition.
[programkörning] [28 maj 2018]
om datorprogram: som ger exakt samma resultat varje gång programmet körs, förutsatt att indata är identiska. Rena matematiska beräkningar är deterministiska (12+3 blir alltid 15), men sökningar på Google är inte deterministiska. (Som indata räknas då sökorden.) – På engelska: deterministic. – Determinism är den filosofiska åskådningen att allt som händer är förutbestämt, betingat av vad som har hänt tidigare.
[datorvetenskap] [filosofi] [programmering] [ändrad 28 juni 2018]
i JavaScript: en operator som ställer frågan om ett visst objekt är en instans av en överordnad klass och får svaret ja eller nej (true / false). Det kallas för class checking. Exempel: är objektet ”Fido” (en hund) en instans av klassen Hund? (True.) Man kan också fråga om ”Fido” är en instans av klassen Djur (true) eller av klassen Katt (false). I omfattande och mindre uppenbara klasshierarkier är det ett användbart verktyg. – Mer här.
[programmering] [21 maj 2018]
– the rule of least power – regeln om minst kraftfulla språket – principen att programmerare bör välja det minst kraftfulla av de programspråk som kan användas för att lösa en uppgift. – Man bör, om det går, välja ett språk som steg för steg och med lättfattliga kodord beskriver vad som ska göras, eller hur en datamängd är uppbyggd. – Principen formulerades 1998 av Tim Berners‑Lee (se denna länk), som motiverar den med att program och datamängder som ska göras tillgängliga på webben och återanvändas bör vara enkla för andra än upphovspersonen att förstå, bearbeta och analysera. Man bör kunna förstå delar av koden oberoende av helheten. Koden till webbsidor som är skrivna i HTML är till exempel lätt att förstå, förutsatt att man har vissa förkunskaper, medan koden till en Java-applikation inte går att genomskåda på något enkelt sätt. – Regeln om minst kraftfulla språket går på tvärs mot decennier av utveckling av programspråk. Utvecklare har strävat efter att göra språken så kraftfulla som möjligt, men det kräver förkunskaper på hög nivå av programmerarna, och gör det svårt för utomstående att förstå programkoden. – Läs mer i detta dokument från W3C.
[lagar] [programmering] [17 maj 2018]
struktur eller organisation som har en rangordning där varje person eller annat ingående element är överordnad, underordnad eller någonstans emellan. Man kan skilja mellan två typer av hierarkier:
- – Ett vanligt filsystem med kataloger (mappar) kan vara hierarkiskt upplagt. Filerna läggs i kataloger som kan finnas inuti andra kataloger som i sin tur kan finnas i andra kataloger i flera led. Men det är i princip godtyckligt var en viss fil placeras i filsystemet. Filsystemet tvingar inte filer till en bestämd katalog. Ett filsystem kan därför i princip vara hur rörigt som helst, trots att det har en hierarkisk struktur;
- – Objekten i ett objektorienterat system är däremot hierarkiskt ordnade i strikt bemärkelse: underordnade objekt ”ärver” egenskaper från överordnade objekt. Det går därför inte att flytta ett objekt till en annan plats i systemet, utom möjligtvis i speciella fall och med modifieringar.
– Ordet hierarki användes från början om kyrkans uppbyggnad, men det har överförts till alla slags organisationer, från arméer till företag. Där har vi krav på att de underordnade ska rätta sig efter de överordnade. (Hierarki kommer av de grekiska orden för präst och styrelse.) – Om man ritar en hierarkisk struktur som en graf är det en riktad trädstruktur. – På engelska: hierarchy.
[datastrukturer] [informationshantering] [ändrad 7 augusti 2020]
en variant av hierarkiskt ordnad information där element kan ligga under två eller flera överordnade kategorier. – Exempel: piano kan klassificeras både som stränginstrument (pianon har strängar, som gitarr och fiol) och som tangentinstrument (som orgel och synt). Om man använder en polyhierarkisk struktur för att ordna information på webben ger man användarna flera vägar till det de söker, och utvecklaren slipper välja (stränginstrument eller tangentinstrument?). Det gör det lättare att till exempel hitta en produkt i en postorderkatalog på webben. – Om man ser den polyhierarkiska strukturen som en graf kan man säga att en nod kan ha två eller fler föräldrar. En vanlig (enkel) hierarki kan ritas upp som en trädstruktur, men en polyhierarki är mer som en buske och förgrenar sig både uppåt och nedåt. – Jämför med multipelt arv.
[datastrukturer] [14 maj 2018]
(low-code) – utveckling av applikationer med lite kodning: applikationerna sätts samman huvudsakligen, men inte enbart, av färdigskrivna komponenter. Utvecklarna lägger till handskriven kod bara för speciella funktioner. Det är alltså låg kod i betydelsen lite kod – inte kodning på låg (maskinnära) nivå. – Utveckling i låg kod görs i ett grafiskt användargränssnitt: programmeraren markerar vilka komponenter som ska höra ihop och hur de ska interagera. – Låg kod gör att utvecklingsprojekt kan genomföras på kort tid och utföras av mindre erfarna programmerare eller andra anställda. Samtidigt finns möjlighet att vid behov lägga till vanlig programkod. Verktyg för lågkodsutveckling tillhandahålls av olika leverantörer, oftast som en molntjänst. Sådana verktyg ser automatiskt till att det färdiga programmet har sådana funktioner som alla program behöver och förväntas ha. – Benämningen low code förekom första gången 2014 i en rapport från Forrester Research. Det bör tilläggas att arbetssättet inte är något radikalt nytt, utan ett steg i en långvarig utveckling för att förenkla programutveckling med hjälp av färdigskrivna komponenter. Ett syfte är att personal utan kunskaper i programmering ska kunna sätta samman program som de behöver i sitt arbete – se medborgarutveckling. – Man talar också om no code, alltså ingen kodning alls. – Se också komponerbar (composable).
[programmering] [ändrad 25 november 2021]