De store sprog er populære af en grund: De tilbyder et stort fundament af open source-kode, biblioteker og rammer, der gør det lettere at afslutte jobbet. Dette er resultatet af mange års fart, hvor de igen og igen vælges til nye projekter, og ekspertise i deres nuancer bliver umagen værd og rigelig.
Nogle gange er de store ressourcer på de populære, almindelige programmeringssprog ikke nok til at løse dit særlige problem. Nogle gange er du nødt til at se ud over det åbenlyse for at finde det rigtige sprog, hvor den rigtige struktur gør forskellen, mens du tilbyder den ekstra funktion til at hjælpe din kode med at køre betydeligt hurtigere uden endeløs tilpasning og optimering. Dette sprog producerer langt mere stabil og nøjagtig kode, fordi den forhindrer dig i at programmere sjusket eller forkert kode.
Verden er fyldt med tusindvis af smarte sprog, der ikke er C #, Java eller JavaScript. Nogle er kun værdsat af nogle få, men mange har blomstrende samfund forbundet med en fælles kærlighed til sprogets facilitet til at løse visse problemer. Der er muligvis ikke titusinder af programmerere, der kender syntaksen, men nogle gange er der værdi i at gøre tingene lidt anderledes, da eksperimentering med ethvert nyt sprog kan betale betydeligt udbytte på fremtidige projekter.
De følgende ni sprog skal være på hver programmørs radar. De er måske ikke de bedste til ethvert job - mange er rettet mod specialiserede opgaver. Men de tilbyder alle ulemper, der er værd at undersøge og investere i. Der kan være en dag, hvor et af disse sprog viser sig at være præcis, hvad dit projekt - eller chef - har brug for.
Kotkin: Java genovervejet
Java er et fantastisk sprog, der understøtter nogle af de mest populære platforme nogensinde, men det bliver lidt gammelt, og smertepunkterne bliver lidt for velkendte. Kotlin er hjernebarn af JetBrains-teamet i Rusland, dem der har bragt os vidunderlige IDE'er som IntelliJ. Kotlin er beregnet til at kompilere hurtigt, eksistere sammen med Java og rette nogle af de værste problemer, der optager Java-udvikleres tid.
Den bedste del kan være opmærksomheden på nullable værdier, banen for alle objektorienterede programmører. Hvis du føler, at halvdelen af din kode kontrollerer for nulværdier, hørte Kotlin-udviklerne dine skrig. Kotlin tager et stort skridt mod at løse dette problem, hvis ikke en gang for alle, så i det mindste det meste af tiden ved at tvinge udviklere til eksplicit at kalde de variabler, der kan være nul. Derefter kontrolleres det automatisk for nogle af de værste fejl, vi kan lave med dem.
Kotlin er designet til at arbejde med eksisterende Java-kode, hvilket gør det til en god mulighed for hold, der gradvist vil forbedre en kodebase. Det kompileres også ned til JavaScript eller native-kode, hvis det er det, du tilfældigvis har brug for. Google anerkendte værdien af sproget, og nu understøttes Android-udviklere, der ønsker at bruge Kotlin.
Denne forsigtige strategi har vist sig at være populær, fordi den gør det muligt for teamet at vedtage sproget langsomt. Kotlin-gruppen har fået mange fans i store udviklingsteams i større banker, konsulentgrupper og appfirmaer.
Erlang: Funktionel programmering til realtidssystemer
Erlang begyndte dybt inde i de uhyggelige områder af telefonswitche hos Ericsson, den svenske teleselskab. Da Ericsson-programmører begyndte at prale af sin "ni 9'ers" ydeevne ved at levere 99,9999999 procent af dataene med Erlang, begyndte udviklerne uden for Ericsson at lægge mærke til det.
Erlangs hemmelighed er det funktionelle paradigme. Det meste af koden er tvunget til at fungere i sin egen lille verden, hvor den ikke kan ødelægge resten af systemet gennem bivirkninger. Funktionerne udfører alt deres arbejde internt og kører i små "processer", der fungerer som sandkasser og kun taler med hinanden via mailbeskeder. Du kan ikke bare gribe en markør og foretage en hurtig ændring af tilstanden hvor som helst i stakken. Du skal forblive inde i opkaldshierarkiet. Det kan kræve lidt mere tanke, men fejl er mindre tilbøjelige til at sprede sig.
Modellen gør det også lettere for runtime-kode at bestemme, hvad der kan køre på samme tid. Med samtidig så let at opdage, kan runtime-planlæggeren drage fordel af den meget lave overhead ved opsætning og nedrivning af en proces. Erlang-fans kan lide at prale med at køre 20 millioner “processer” på samme tid på en webserver.
Hvis du bygger et system i realtid uden plads til tabte data, såsom et faktureringssystem til en mobiltelefon-switch, skal du tjekke Erlang.
Gå: Enkel og dynamisk
Google var ikke den første organisation, der undersøgte samlingen af sprog, kun for at finde dem rodede, komplekse og ofte langsomme. I 2009 frigav virksomheden sin løsning: et statisk skrevet sprog, der ligner C men inkluderer baggrundsintelligens for at redde programmører fra at skulle specificere typer og jonglere malloc-opkald. Med Go kan programmører have hårdhed og struktur af kompileret C sammen med den lette brug af et dynamisk script-sprog.
Mens Sun og Apple fulgte en lignende vej i henholdsvis oprettelse af Java og Swift, tog Google en væsentlig anden beslutning med Go: Sprogets skabere ønskede at holde Go "enkel nok til at holde i en programmers hoved." Rob Pike, en af Go's skabere, fortalte berømt Ars Technica at "nogle gange kan du få mere i det lange løb ved at tage tingene væk." Således er der få zippy-ekstramateriale som generik, arv af typen eller påstande, kun rene, enkle blokke af hvis-så-ellers-kodemanipulerende strenge, arrays og hash-tabeller.
Sproget er efter sigende veletableret inde i Googles store imperium og vinder accept andre steder, hvor dynamiske sprogelskere af Python og Ruby kan lokkes til at acceptere noget af den strenghed, der kommer fra et kompileret sprog.
Hvis du er en opstart, der prøver at fange Googles øje, og du har brug for at opbygge en vis forretningslogik på serversiden, er Go et godt sted at starte.
OCaml: Kompleks datahierarki-jonglør
Nogle programmører ønsker ikke at specificere typerne af deres variabler, og for dem har vi bygget de dynamiske sprog. Andre nyder sikkerheden ved at specificere, om en variabel indeholder et heltal, streng eller måske et objekt. For dem tilbyder mange af de kompilerede sprog al den support, de ønsker.
Så er der dem, der drømmer om udførlige typehierarkier og endda taler om at skabe “algebraer” af typer. De forestiller sig lister og tabeller af heterogene typer, der samles for at udtrykke komplekse, multilevelede data ekstravaganzer. De taler om polymorfisme, mønstermatchende primitiver og datakapsling. Dette er kun begyndelsen på den komplekse, stærkt strukturerede verden af typer, metatyper og metametatyper, de ønsker.
For dem er der OCaml, en seriøs indsats fra programmeringssprogsamfundet for at popularisere mange af de ovennævnte ideer. Der er objektstøtte, automatisk hukommelsesstyring og enhedsportabilitet. Der er endda OCaml-apps tilgængelige fra Apples App Store.
Et ideelt projekt for OCaml kan være at opbygge et symbolsk matematikwebsted for at undervise i algebra.
TypeScript: JavaScript, du kan lide
Alle kan bruge JavaScript, men ingen ser ud til at kunne lide programmering i den. Eller sådan ser det ud, fordi alle i dag har deres yndlingsforprocessor eller superprocessor, der udvider og forbedrer sproget. TypeScript er den nuværende favorit, fordi den tilføjer typer til alle variablerne, noget der får Java-programmørerne til at føle sig lidt mere sikre.
Den største grund til, at flere udviklere er interesseret i TypeScript nu, er Angular, en fantastisk ramme til opbygning af webapplikationer, der tilfældigvis bare er skrevet i TypeScript. Det interessante rynke er, at du ikke behøver at bruge TypeScript til at bruge Angular. Du kan nyde kvaliteten af dens kode og flette den med din ældre JavaScript. Du behøver ikke at vælge.
Årsagen er, at TypeScript er et supersæt af JavaScript. Udviklerne tilføjede typografien på en måde, der spiller godt med gammeldags JavaScript, noget der er ret nyttigt, hvis der er folk på kontoret, der ikke kan lide ideen om typer, eller som har dogmatiske meninger om, hvordan typer kramper deres stil. Typerne er faktisk valgfri, og de mennesker, der lægger sig tid til at specificere typerne, kan høste fordelene.
Stærk typing har mange fordele som at fange nogle bugs tidligt og forbedre den generelle kvalitet af værktøjer. Tilføjelse af typer gør det muligt for de smarte redaktører at hjælpe dig med smarte forslag, når du laver dit mesterværk. Kodefuldførelse er meget hurtigere og mere præcis, når kodefærdiggørelsesrutinerne ved noget om funktionerne og argumenterne. Det betyder mindre bevægelse af fingrene på tastaturet. TypeScript-elskere er sikre på, at fordele som disse vil lokke alle, der er på hegnet, om kraften i et stærkt bestemt sprog.
Rust: Sikkert og brugbart systemsprog
Frontend-programmørerne er ikke de eneste, der har det sjovt. Rust er som en renoveret version af C med masser af polymorf typing blandet ind under emhætten. Det har vundet "mest elskede programmeringssprog" fra Stack Overflow-vælgere i de sidste to år i træk, en ære, der også afspejles i Stack Overflow's indeks over sproglig popularitet. For bare et par år siden svævede Rust omkring 50 på listen, og i år sprang den til 18.
Hvorfor? Måske fordi Rust rydder op i mange af de knasende problemer med C uden at gøre for meget håndhold eller insistere på, at udviklerne ikke har virtuelle straightjakker. Systemprogrammerere elsker ikke at stole på affaldsindsamling, en god service, indtil den sparker ind på nøjagtigt det mest upassende tidspunkt. Rust får dig til at føle, at du har ansvaret for, hvad der sker med nummeret i hukommelsen, og ikke venter på, at nogle tjenester skal udføre arbejdet for dig.
Typesystemet er generelt og fleksibelt og tilbyder den slags polymorfisme, der er inspireret af Haskell, i det mindste abstrakt. Når det implementeres, tilpasser compileren imidlertid strukturen for hver type, noget udviklerne gerne kalder "monomorfisme". Sproget tilføjer et par andre grænser for at forhindre udviklere i at gå ud af skinnerne. Hver værdi er for eksempel "ejet" - hvilket virkelig betyder, at den kun kan forbruges en gang, hvilket forhindrer et sammenfiltret web af referencer fra andre dele af programmet, der fungerer som om de har fuld kontrol over en værdi.
Alle disse funktioner plus et par flere - ligesom race-condition-free threading - betyder, at den nye programmør kan begynde at skrive systemkode uden at løbe ind i nogle af de værste antimønstre, der har længe bedeviled C-programmerere. Du får alt det hårde, højtydende sjov ved at skrive C med en compiler, der fanger mange af de værste fejl, før koden overhovedet kører.
Scala: Funktionel programmering på JVM
Hvis du har brug for kodens enkelhed af objektorienterede hierarkier til dit projekt, men elsker det funktionelle paradigme, har du flere valgmuligheder. Hvis Java er dit rige, er Scala valget for dig.
Scala kører på JVM og bringer alle de rene designstrengninger af funktionel programmering til Java-verdenen ved at levere kode, der passer til Java-klassespecifikationerne og links til andre JAR-filer. Hvis de andre JAR-filer har bivirkninger og andre vigtige ubehagelige hovedpine, så være det. Din kode vil være ren.
Typemekanismen er stærkt statisk, og kompilatoren gør alt for at udlede typer. Der skelnes ikke mellem primitive typer og objekttyper, fordi Scala ønsker, at alt skal stamme fra et ur-objekt-kald Any. Syntaksen er meget enklere og renere end Java; Scala folk kalder det "lav ceremoni." Du kan efterlade dine afsnitslange CamelCase-variabelnavne tilbage i Java Land.
Scala tilbyder mange af de funktioner, der forventes af funktionelle sprog, såsom doven evaluering, hale rekursion og uforanderlige variabler, men er blevet ændret til at arbejde med JVM. De grundlæggende metatyper eller samlingsvariabler, som f.eks. Sammenkædede lister eller hash-tabeller, kan være enten ændrede eller uforanderlige. Hale rekursion fungerer med enklere eksempler, men ikke med detaljerede, gensidigt rekursive eksempler. Idéerne er der alle, selvom implementeringen måske er begrænset af JVM. Derefter kommer det også med al Java-platformens allestedsniveau og den dybe samling af eksisterende Java-kode skrevet af open source-samfundet. Det er ikke en dårlig kompromis med mange praktiske problemer.
Hvis du skal jonglere dataene i en klynge med tusind processorer og have en bunke ældre Java-kode, er Scala en god løsning.
