Historien om, utviklingen av og fremtiden til programmeringsspråk

Abstract

De fleste programmerere har møtt på en eller flere av følgende «skrekkhistorier»: Man må lete i en gigantisk trestruktur, for å finne ut hvor koden er, og hva den gjør. Eller man må bruke all sin tid på å jobbe med selve strukturen i stedet for selve problemet. Eller man lager tester som av og til feiler uten å forandre på noe som helst. Eller det tar ekstremt lang tid til å få koden til en kjørbar tilstand, noe som stjeler tid til testing og feilretting. Eller man bruker enormt lang tid til å utvikle effektiv kode uten særlig forbedring i ytelse.

Ved slik bortkastet tid, er det vanskelig for bedrifter å innovere og utvikle gode systemer, og de kan bli mer avhengig av utdaterte programmeringsspråk som hindrer progresjon. Mens for programmererne er det frustrerende å arbeide innenfor et programmeringsspråk som ikke sammenfaller med deres ønsker for hva et programmeringsspråk kan gjøre, og unødvendig tid brukes til å arbeide mot programmeringsspråket i stedet med selve problemet. Hvis du skulle havne i en slik situasjon, ville du ha akseptert dette som «status quo»? Eller ville du ha prøvd å forandre arbeidssituasjonen til noe bedre?

For de som ønsker forandring, vet at det ikke alltid er enkelt å finne fram en bedre løsning når man ikke har mye kunnskap om andre programmeringsspråk med dets fordeler og ulemper. Derfor er formålet med dette dokumentet å gi programmerere et bedre grunnlag over hvilke programmeringsspråk som finnes, og gi dem redskap til å finne ut hvilke som fungerer i ulike situasjoner, og om noen er generelt bedre enn andre.

Most programmers have encountered one or more of the following "horror stories": You have to search in a giant tree structure to find out where the code is and what it does. Or you have to spend all your time working on the structure itself instead of the problem. Or you create tests that occasionally fail without changing anything. Or it takes an extremely long time to get the code to an executable state, which steals time for testing and debugging. Or you spend an enormous amount of time developing efficient code without much improvement in performance.

With such wasted time, it is difficult for companies to innovate and develop good systems, and they may become more dependent on outdated programming languages ​​that hinder progression. Whereas for the programmers, it is frustrating to work within a programming language that does not coincide with their expectations for programming language's capabilities, and unnecessary time is spent working against the programming language instead of the problem itself. If you were to find yourself in such a situation, would you have accepted this as the "status quo"? Or would you have tried to change the work situation fot the better?

For those who want change, know that it is not always easy to find a better solution when you do not have much knowledge of other programming languages ​​with their advantages and disadvantages. Therefore, the purpose of this document is to give programmers a better basis on which programming languages ​​exist, and to give them tools to find out which ones work in different situations, and if some are generally better than others.