Hvor mange typer programmeringssprog er der? [lukket]

Det afhænger af, hvordan du vil klassificere sprog. Grundlæggende kan sprog opdeles i to typer: tvingende sprog, hvor du instruerer computeren hvordan at udføre en opgave og erklærende sprog, hvor du fortæller computeren hvad den skal gøre. Deklarative sprog kan yderligere opdeles i funktionelle sprog, hvor et program er konstrueret ved at komponere funktioner, og logik programmeringssprog, hvor et program er konstrueret gennem et sæt logiske forbindelser. Imperative sprog læser mere som en liste over trin til løsning af et problem, ligesom en opskrift. Imperative sprog inkluderer C, C ++ og Java; funktionelle sprog inkluderer Haskell; logiske programmeringssprog inkluderer Prolog.

Imperative sprog er undertiden opdelt i to undergrupper: proceduremæssige sprog som C , og objektorienterede sprog . Objektorienterede sprog er lidt vinkelrette på grupperingerne, da der er objektorienterede funktionelle sprog (OCaml og Scala er eksempler).

Du kan også gruppere sprog ved at skrive: statisk og dynamisk . Statisk typede sprog er sprog, hvor typografi kontrolleres (og normalt håndhæves) inden programmet køres (typisk i en kompileringsfase); dynamisk typede sprog udsætter typekontrol til runtime. C, C ++ og Java er sprog, der er statisk skrevet; Python, Ruby, JavaScript og Objective-C er dynamisk typede sprog. Der er også untyped sprog, der inkluderer programmeringssproget Forth.

Du kan også gruppere sprog efter deres typing disciplin : svag typing, som understøtter implicitte typekonverteringer, og stærk typing, som forbyder implicitte typekonverteringer. Linjerne mellem de to er en smule slørede: ifølge nogle definitioner er C et svagt skrevet sprog, mens andre anser det for at være stærkt skrevet. At skrive disciplin er alligevel ikke en nyttig måde at gruppere sprog på.

Kommentarer

• Skulle udgøre noget lignende, men vil +1 og tilføj kommentarer i stedet. Hver kategori eller kombination har også adskillige spin-offs oprettet ved at fokusere på bestemte elementer. OOP, for eksempel, begynder: Prototype-baseret OOP, aspektorienteret programmering, komponentbaseret programmering osv. Funktionelle paradigmer også har spin-offs, såsom sprog, hvor en asynkron proces eller tråd er basisenheden, og du programmerer ved at komponere parallelle processer sammen.
• Hvordan ville scripting-sprog, f.eks. VBScript, passe ind i dette? Det kan være en lidt proceduremæssigt og lidt OO, da man kan oprette forskellige typer, så ville det gøre det til en hybrid?
• Dette er lige hvad jeg ledte efter. Mange tak.
• @ JB King OOP-sprog er normalt proceduremæssige, i det mindste inden for metodeorganerne.Det er også ' en almindelig misforståelse om, at OOP betyder " objekter ". Mange sprog har datatyper og objekter. Der ' debatteres meget om, hvad den nøjagtige definition af OOP er, men det inkluderer normalt arv og / eller indkapsling (privat stat) som hovedtemaer. Et sprog uden nogen af dem i en eller anden form ville være vanskeligt at klassificere som et OOP-sprog.
• @sova Jeg kan kun tænke på to sprog, der fungerer sådan. Erlang er stærkt baseret på parallel behandling, men hvis du vil have mere som det, jeg talte om nøjagtigt, skal du se nærmere på Polyfonisk C #. Det ' et forskningssprog (nu foldet ind i C-omega) baseret på Pi-Calculus (som hvordan FP er baseret på lambda calc) Pi-calc er baseret på enheden i en proces , og du erklærer processer og en kombination af synkron og asych-opkald til dem. Se også pile i FP, især Haskell. Pile er meget lignende.

• Samling
• Procedurel
  
  • Grundlæggende
  • C
• Objektorienteret
  
  • C #
  • Java
• Deklarativ
  
  • Prolog
  • SQL
• Funktionel
  
  • Lisp
  • Haskell

Disse er de vigtigste, men der er mange andre paradigmer derude, og der er masser af overlap mellem dem.

Kommentarer

• Hvad med erklærende (f.eks. Prolog, SQL)?
• @Bruce, fik dem nu.
• Ja, det var den generelle idé, jeg lærte et eller andet sted undervejs.
• Skal t-samling betragtes som proceduremæssig?
• Hvad med sammenkædende (stakbaserede) programmeringssprog, såsom Forth og Factor? Du kan betragte det som en type funktionel programmering, men det ' er sandsynligvis tydeligt nok til at fortjene omtale. da.wikipedia.org/wiki/Concatenative_programming_language

_{Klik på billedet for at se PDF.}

Du bør se på Programmeringsparadigmer for dummies: Hvad enhver programmør burde vide af Peter Van Roy. Dette giver dig et overblik over, hvordan det foregår udenfor.

Hvis du vil gå længere, kan du læse Koncepter, teknikker og modeller af Computerprogrammering . Du lærer ikke en gren af sprog på denne måde, men du lærer paradigmer, der ligger bag forskellige slags sprog. Så det bliver lettere for dig at lære et nyt sprog.

• Procedurelt: Samling, Java, C #, F #, Lisp, Fortran.

• Sætbaseret: SQL.

• Mønsterbaseret: Perl, Regex, Snobol.

• Træbaseret: XSLT.

• Arraybaseret: APL.

Kommentarer

• +1 for at bruge en anden type klassifikation og også for at anerkende, at ' proceduremæssig ' indeholder faktisk de fleste andre ' s klassifikationer. (selvfølgelig betyder det kun, at ordet har meget ringe betydning, og kødet er i sådanne underinddelinger)

Der er forskellige måder at besvare dette på, men i termer kan de kategoriseres som:

Maskinsprog: Maskinsprog er et programmeringssprog på lavt niveau. Det er let at forstå af computere, men svært at læse af folk. Derfor bruger folk programmeringssprog på højere niveau. Programmer skrevet på sprog på højt niveau er også enten kompileret og / eller fortolket til maskinsprog, så computere kan udføre dem.

Samlingssprog: Samlingssprog er en gengivelse af maskinens sprog. Med andre ord oversættes hver montagesproginstruktion til en maskinsproginstruktion. Selvom udsagn om forsamlingssprog er læselige, er udsagnene stadig lavt En ulempe ved monteringssprog er, at det ikke er bærbart, fordi hver platform leveres med et bestemt monteringssprog.

Sprog på højt niveau: Sprog på højt niveau er, hvad de fleste programmører bruger i dag. Sprog som C, C ++ og Java er alle sprog på højt niveau. Fordele ved sprog på højt niveau er, at de er meget læsbare og bærbare. En ulempe ved sprog på højt niveau er, at de er mindre magtfulde end forsamlingssprog. Fordi en enkelt erklæring på et højt sprog er oversat til mange udsagn om maskinsprog.

Sprog på højt niveau kan yderligere klassificeres som:

1. Funktionelle sprog: På funktionelt sprog er et program opdelt i funktionsdefinitioner. Funktionelle sprog er en slags deklarativt sprog. De er for det meste baseret på den typede lambda-calculus med konstanter. Nogle af de berømte funktionssprog er Scala, F #, Clojure og Lisp.

2. Processprog: I proceduremæssige sprog er et program skrevet i en sekvens af trin, der skal følges for at give et resultat. COBOL, FORTRAN og C er nogle proceduremæssige sprog.

3. Objektorienteret programmeringssprog: På OOP-sprog er et program opdelt i objekt, der indeholder data samt metoder, der fungerer på dataene. Java, C # og C ++ er OOP-sprog.

4. Logik Programmeringssprog: Logiske sprog bruges til at oprette programmer, der gør det muligt for computeren at logisk logiske. f.eks: Logisk sprog

For dybdegående undersøgelse, tjek:

• http://en.wikipedia.org/wiki/List_of_programming_languages_by_type og
• http://en.wikipedia.org/wiki/Programming_paradigm

Jeg har tendens til at tænke i form af funktioner:

Syntaks:

C-baseret eller hvad-har-dig. Java har en C-baseret syntaks. Jeg kan varmt anbefale at prøve noget som Python eller Ruby for at få hovedet ud af syntaksen og tænke mere med hensyn til fundamentet for, hvordan et givet sprog fungerer. Jeg er af den opfattelse, at ingen syntaks behøver at blive større end C-baseret og ikke har problemer med at bygge blokke omkring det hvide rum.

Kompileret vs. fortolket m. Build-proces vs. fortolket / konsol:

Jeg har meget lidt fortrolighed med kompileringstid vs. miljømæssige bekymringer, men jeg får det der er en hel pose med bekymringer der, som jeg sjældent tænker på.

Ligeledes er der masser af fortolkede sprog, der stadig har noget af en kompileringsproces til kørsel inde i en virtuel maskine som Java gør. Du er stadig nødt til at genopbygge for at se ændringer i tingene.

Og så er der JavaScript og Python, som du kan udføre på farten, kommando for kommando i en konsol i et levende miljø. Alle tre kan føre til meget forskellige måder at skrive kode på.

Dynamisk kontra streng skrivning:

Jeg har en tendens til at se de to som designkompromiser. Når du er på et meget lavere niveau, og ydeevnen er kritisk, giver statisk typografi meget mening. Jeg har aldrig forstået denne forestilling om, at den ene er “sikrere” end en anden, men jeg kom op på et meget plastisk / dynamisk sprog, hvor du bare lærer, hvordan typesystemet fungerer, og hvad man kan forvente, grundlæggende. Type shenanigans er sjældent en bekymring for mig i JS. På nogle måder kan fleksibiliteten gøre tingene mere robuste, selvom det ganske vist er et strejf mere uklar for en mere Jr. niveauudvikling, hvis du ikke kender til nogle af pottehullerne i sproget.

Block-Level Scope vs. Function Scope vs.?:

Block-Level er det mest almindelige (alt mellem {} i de fleste c-baserede syntaks-sprog). JavaScript-omfang er bygget op omkring funktioner (som også bruges til at opbygge objekter så effektive objekter også). Der er også en stor variation i, hvilken slags adgang du har fra det indre omfang til en ydre rækkevidde. Jeg er ikke bekendt med andre scoping-ordninger, men jeg er sikker på, at de findes.

Klassisk OOP vs. Prototypal OOP vs Næsten-OOP ?) vs Non-OOP:

Selv i klassebaseret OOP er der meget plads til variation. Uanset om du kan udføre flere arv (ew, godt i overskud, ew), definere grænseflader osv …

I JavaScript har vi en slags forkrøblet hybrid prototypisk OOP, hvor objekter er betydeligt mere enkle, meget mutable, men vi har stadig evnen til at adskille interface fra interne bekymringer, hvilket IMO er det vigtige aspekt ved indkapsling .

Sagen ved OOP er, at der virkelig er mange ting, du kan trække af, der i det væsentlige er OOP-orienteret uden teknisk at være OOP. Der er selvfølgelig purister, men i slutningen af dagen handler designmønstre om at opnå visse abstraktioner, der fungerer godt i visse situationer. Vær ikke for hurtig til at antage ideer fra et OOP-baseret sprog, har ingen brug for noget, der er mere proceduremæssigt orienteret. Og jeg taler ikke om JavaScript. Det er slet ikke begrænset af sin tåbelige version af en prototype baseret OOP-paradigme.

Førsteklasses funktioner :

At have disse på et sprog er en svær ting for mig at give op. Du kan videregive funktioner som om de var data til brug i andre sammenhænge. Dette gør specielt begivenhedshåndteringsordninger meget nemme at implementere, men det gør det også meget let at tilpasse sproget til at fungere, som du gerne vil have det. Det er mere end noget, jeg har mistanke om, det, der har gjort JavaScript til en succes at det ultimative har været på trods af at være designet om to uger og få Java-tilnærmelsesvis syntaks slået til det som et marketingskema.

Lukninger:

Jeg er ikke sikker på, hvor debatten er til for Java, men jeg ved, at mange Java-devs klagede på denne funktion for et år eller to siden. I et sprog, der ikke lukkes, når en funktion lukkes, vil alt, hvad der på en eller anden måde er i stand til at henvise til ting inde fra den funktion, ikke kunne få adgang til det, fordi det blev indsamlet skrald. I en lukning er eksekveringskontekst bundet sådan, at hvis du “er i stand til at henvise til ting inde i den lukkede funktion fra et andet omfang som i et returneret objekt eller en funktion, får du dybest set de vars, som de var, da funktionen lukkede. Det er som at sætte en fod fast i døren til affaldsindsamling, selvom jeg formoder, at den er mere implementeret som kopier af de vars, der er lavet til lokale vars fra den henvisende enhed.

Stiv / streng / sikker vs. at give dig alt det reb, du vil have:

JS devs og Java devs har tendens til ikke at forstå hver andet overhovedet, og jeg tror, det har meget at gøre med de to sprog, der falder på næsten modsatte sider af dette specifikke designspektrum. Jeg vil ikke have dig til at beskytte mig mod mig selv eller fra de andre devs på mit team. Jeg vil gøre meget mere med meget mindre kode og gøre det hele på meget forskellige (men konsekvente for et givet domæne) måder afhængigt af om situationen. Der er absolut kompromiser med begge, og mange sprog har en tendens til at falde mere i midten.

Kommentarer

• Hej tak. Det ' er virkelig rart at gå igennem indsatsen for en nedstemning uden forklaring.

Jeg tror, at en genvej til alle disse er at lære nok Lisp til at gøre nogle semi-nyttige ting. De fleste af disse paradigmer startede som måder at bruge Lisp på, så det er en enkel måde for at prøve ting.

Der er en række “slags” sprog rundt, men nye kan altid vises. Grundlæggende er formålet med et sprog at tillade kodning af ideer, koncepter eller krav så direkte som muligt. Til dette formål kan der være situationer, hvor eksisterende paradigmer er ønsket, og der kan være behov for en ny.

En måde at se på er med hensyn til overfladestruktur. Hvor direkte giver det dig mulighed for at indkode ideer kortfattet, så hvis du skifter mening om, hvad du vil, er den tilsvarende ændring af koden også let med lille chance for at introducere bugs.

En anden måde at se på det er med hensyn til kontrolstruktur. Når sproget udføres (hvis det er), i hvilken rækkefølge tingene sker, for at opnå det, du ønsker? Eksempler er: simpel gennemføring, rekursion, backtrack, parallelisme. En jeg (beskeden hoste) opdagede var differentiel udførelse .

Et andet nyttigt synspunkt er, at når som helst en datastruktur designes, er et sprog Født. Data “udføres” af applikationsprogrammerne, der kæmper igennem dem og gør ting, ligesom et program bare er en flok data (som byte-koder), der bruges af en tolk til at gøre ting.

Kommentarer

• Cool. Jeg vil lære LISP og blive oplyst. Spændende: D
• Men hvis du siger, at handlingen ved at bruge en datastruktur skaber et nyt mellem sprog, kan du også argumentere for, at et nyt sprog er født i hver algoritme (alle operationer udføres nødvendigvis på en data struktur), og med reduktion fødes et nyt sprog i hver kodelinje. Jeg tror, du mener noget andet, men jeg ' er jeg ikke helt sikker på, at jeg forstår endnu?
• @sova: For mig var informationsteori en stor åbenbaring (både Shannon og Kolmogorov). Det ' handler om, hvordan betydningen kodes og føres gennem kanaler med begreber båndbredde, fejlregistrering, minimal kodning, tilfældighed osv. Så data koder information og algoritmer er kanaler . Programmer koder for information, og programmering er en kanal. Så hvilke oplysninger er kodet? hvor kommer det fra, og hvornår? hvor skal det hen? hvad er kilderne til fejl (støj)? hvordan rettes de? Jeg fandt det et nyttigt perspektiv.
• @sova: (fortsat) Du behøver ikke ' behøver ikke at mestre al den modbydelige matematik. For mig var det vigtige rammen, det gav mig til at tænke på tingene.

Jeg skal tilføj, at der er programmeringssprog til specifikke applikationer. Den, der kommer til at tænke på, er APT (Automatic Programmed Tool), et sprog der bruges til fremstilling af værktøjsmaskiner.

Kommentarer

• Jeg husker den ene. Jeg har måske endda brugt det. Dreng, det var topmoderne. Du behøvede ikke ' at styre fræseren manuelt, bare tryk på startknappen. Og hvis der var en fejl, ville helvede bryde løs.
• Jeg ' har arbejdet med programmer, der genererer gcode til fræsemaskiner. Jeg ' har bogstaveligt talt holdt og set resultaterne af programmering af fejl, ofte mine.
• Jeg brugte 20 år på at installere postprocessorer på gobs af systemer.