Hoeveel soorten programmeertalen zijn er? [gesloten]

Het hangt ervan af hoe u talen wilt classificeren. In principe kunnen talen worden onderverdeeld in twee typen: imperative talen waarin u de computer instrueert hoe om een taak uit te voeren, en declaratief talen waarin u de computer wat vertelt te doen. Declaratieve talen kunnen verder worden onderverdeeld in functionele talen, waarin een programma is opgebouwd door functies samen te stellen, en logic programmeertalen, waarin een programma is opgebouwd via een reeks logische verbindingen. Dwingende talen lezen meer als een lijst met stappen voor het oplossen van een probleem, een soort recept. Dwingende talen zijn onder meer C, C ++ en Java; functionele talen omvatten Haskell; logische programmeertalen omvatten Prolog.

Imperatieve talen worden soms onderverdeeld in twee subgroepen: procedureel talen zoals C , en objectgeoriënteerde talen . Objectgeoriënteerde talen zijn echter een beetje orthogonaal ten opzichte van de groeperingen, aangezien er objectgeoriënteerde functionele talen zijn (OCaml en Scala zijn voorbeelden).

U kunt talen ook groeperen door te typen: statisch en dynamisch . Statisch getypeerde talen zijn talen waarin het typen wordt gecontroleerd (en meestal wordt afgedwongen) voordat het programma wordt uitgevoerd (meestal tijdens een compilatiefase); dynamisch getypeerde talen stellen typecontrole uit tot runtime. C, C ++ en Java zijn statisch getypeerde talen; Python, Ruby, JavaScript en Objective-C zijn dynamisch getypeerde talen. Er zijn ook talen zonder type, waaronder de programmeertaal Forth.

U kunt talen ook groeperen op hun type discipline : zwak typen, wat impliciete typeconversies ondersteunt, en sterk typen, wat impliciete typeconversies verbiedt. De lijnen tussen de twee zijn een beetje wazig: volgens sommige definities is C een zwak getypeerde taal, terwijl anderen het als sterk getypeerd beschouwen. Typediscipline is sowieso niet echt een handige manier om talen te groeperen.

Opmerkingen

• Ging iets soortgelijks voorstellen, maar zal een +1 geven en voeg in plaats daarvan opmerkingen toe. Elke categorie of combinatie heeft ook tal van spin-offs die zijn gecreëerd door te focussen op bepaalde elementen. OOP brengt bijvoorbeeld: prototypegebaseerde OOP, aspectgeoriënteerde programmering, componentgebaseerde programmering, enzovoort. Functionele paradigmas ook spin-offs hebben, zoals talen waarin een asynchroon proces of thread de basiseenheid is en u programmeert door samen parallelle processen samen te stellen.
• Hoe passen scripttalen, zoals VBScript, hierin? Het kan een beetje procedureel en een beetje OO aangezien men verschillende typen kan maken, dus zou dat het een hybride maken?
• Dit is precies wat ik zocht. Heel erg bedankt.
• @ JB King OOP-talen zijn meestal procedureel, althans binnen de methodes.Bovendien is het ' een veel voorkomende misvatting dat OOP " objecten " betekent. Veel talen hebben gegevenstypen en objecten. Er is ' veel discussie over wat de exacte definitie van OOP is, maar het bevat gewoonlijk overerving en / of inkapseling (privéstaat) als hoofdthemas. Een taal zonder een van beide in een of andere vorm zou moeilijk te classificeren zijn als een OOP-taal.
• @sova Ik kan maar twee talen bedenken die ongeveer zo werken. Erlang is sterk gebaseerd op parallelle verwerking, maar als je meer wilt zoals waar ik het precies over had, zou je Polyphonic C # moeten bekijken. Het ' is een onderzoekstaal (nu opgevouwen in C-omega) gebaseerd op Pi-Calculus (zoals hoe FP is gebaseerd op lambda-calculatie) Pi-calc is gebaseerd op de eenheid van een proces , en je geeft processen en een combinatie van synchrone en asych-oproepen aan. Kijk ook naar Arrows in FP, vooral Haskell. Pijlen lijken veel op dat.

• Assembly
• Procedureel
  
  • Basis
  • C
• Objectgeoriënteerd
  
  • C #
  • Java
• Declaratief
  
  • Proloog
  • SQL
• Functioneel
  
  • Lisp
  • Haskell

Dit zijn de belangrijkste, maar er “zijn veel andere paradigmas die er zijn, en er is veel overlap tussen hen.

Opmerkingen

• Hoe zit het met declaratief (bijv. Prolog, SQL)?
• @Bruce, heb ze nu.
• Ja, dit was het algemene idee dat ik leerde ergens onderweg.
• Moet niet kan assembly als procedureel worden beschouwd?
• Hoe zit het met aaneenschakelende (stapelgebaseerde) programmeertalen, zoals Forth en Factor? Je zou het als een soort functionele programmering kunnen beschouwen, maar het ' is waarschijnlijk duidelijk genoeg om genoemd te worden. en.wikipedia.org/wiki/Concatenative_programming_language

Voor typen programmeertalen (paradigmas), kijk hier:
http://en.wikipedia.org/wiki/Programming_paradigm

Voor andere kenmerken van programmeertalen (bijv. Type Systems), kijk hier: http://en.wikipedia.org/wiki/Programming_language

Reacties

• ah! " paradigma " wat een goed woord! dank je.
• @sova Ik zou dit als het beste antwoord accepteren, omdat er simpelweg te veel paradigmas zijn om in een P.SE-antwoord op te noemen, laat staan om de nuances van elk te beschrijven.

_{Klik op de afbeelding om de pdf te zien.}

Je zou moeten kijken naar Programmeerparadigmas voor dummies: wat elke programmeur zou moeten weten door Peter Van Roy. Dit geeft je een overzicht van hoe het buiten verloopt.

Als je verder wilt gaan, kun je Concepten, technieken en modellen van Computerprogrammering . Op deze manier leer je geen banch van talen, maar leer je paradigmas die achter verschillende soorten talen schuilgaan. Het leren van een nieuwe taal zal dus gemakkelijker voor je zijn.

• Procedureel: montage, Java, C #, F #, Lisp, Fortran.

• Set gebaseerd: SQL.

• Patroon gebaseerd: Perl, Regex, Snobol.

• Op structuur gebaseerd: XSLT.

• Op matrix gebaseerd: APL.

Opmerkingen

• +1 voor het gebruik van een ander type classificatie, en ook voor het erkennen dat ' procedureel ' bevat in feite de meeste classificaties van de andere mensen ' s. (dat betekent natuurlijk alleen dat het woord heel weinig betekenis heeft, en het vlees is in dergelijke onderverdelingen)

Er zijn verschillende manieren om dit te beantwoorden, maar in termen kunnen ze worden gecategoriseerd als:

Machinetaal: Machinetaal is een programmeertaal op laag niveau. Het is gemakkelijk te begrijpen door computers, maar moeilijk te lezen door mensen. Dit is de reden waarom mensen programmeertalen van een hoger niveau gebruiken. Programmas geschreven in talen van hoog niveau worden ook ofwel gecompileerd en / of geïnterpreteerd in machinetaal, zodat computers ze kunnen uitvoeren.

Assembly-taal: Assembly-taal is een weergave van machinetaal. Met andere woorden, elke assembleertaalinstructie wordt vertaald in een machinetaalinstructie. Hoewel verklaringen in assembleertaal leesbaar zijn, zijn de verklaringen nog steeds laag. Een nadeel van assembleertaal is dat het niet draagbaar is, omdat elk platform wordt geleverd met een bepaalde assembleertaal.

Taal op hoog niveau: Talen op hoog niveau zijn wat de meeste programmeurs tegenwoordig gebruiken. Talen zoals C, C ++ en Java zijn allemaal talen van hoog niveau. Voordelen van talen op hoog niveau zijn dat ze zeer leesbaar en draagbaar zijn. Een nadeel van talen op hoog niveau is dat ze minder krachtig zijn dan Assembly-talen. Omdat een enkele instructie in een taal op hoog niveau wordt vertaald in veel machinetaalinstructies.

Talen op hoog niveau kunnen verder worden geclassificeerd als:

1. Functionele talen: In Functionele taal is een programma onderverdeeld in functiedefinities. Functionele talen zijn een soort declaratieve taal. Ze zijn meestal gebaseerd op de getypte lambda-calculus met constanten. Enkele van de bekende functietalen zijn Scala, F #, Clojure en Lisp.

2. Proceduretalen: In proceduretalen is een programma geschreven in een reeks stappen die moeten worden gevolgd om een resultaat te produceren. COBOL, FORTRAN en C zijn enkele proceduretalen.

3. Objectgeoriënteerde programmeertalen: In OOP-talen is een programma onderverdeeld in Object dat gegevens bevat en methoden die op de gegevens werken. Java, C # en C ++ zijn OOP-talen.

4. Logica Programmeertalen: Logische talen worden gebruikt om programmas te maken die stelt de computer in staat logisch te redeneren. bijv .: Logische taal

Voor diepgaande studie, kijk op:

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

Ik heb de neiging om in termen van functies te denken:

Syntaxis:

C-gebaseerd of wat dan ook. Java heeft een op C gebaseerde syntaxis. Ik raad ten zeerste aan om zoiets als Python of Ruby uit te proberen om je hoofd uit de syntaxis te halen en meer te denken in termen van de basisprincipes van hoe een bepaalde taal werkt. Ik “ben van mening dat geen syntaxis omvangrijker hoeft te worden dan C-gebaseerd en ik heb geen probleem met het bouwen van blokken rond witruimte.

Gecompileerd vs. geïnterpreteerd w. Build-Process vs. Interpreted / Console:

Ik ben zeer weinig bekend met compilatietijd vs. run-time omgevingskwesties, maar dat begrijp ik er is daar een hele hoop zorgen waar ik zelden over nadenk.

Evenzo zijn er tal van geïnterpreteerde talen die nog steeds een soort compileerproces hebben om binnen een virtuele machine te draaien zoals Java dat doet. Je moet nog steeds opnieuw opbouwen om wijzigingen aan dingen te zien.

En dan is er JavaScript en Python die je direct kunt uitvoeren, commando voor commando in een console in een live omgeving. Alle drie kunnen ze leiden tot zeer verschillende manieren om code te schrijven.

Dynamisch versus strikt typen:

Ik zie de twee vaak als afwegingen bij het ontwerp. Als je op een veel lager niveau zit en de prestaties van cruciaal belang zijn, is statisch typen logisch. Ik heb nooit begrepen dat de ene veiliger is dan de andere, maar ik kwam op in een zeer plastische / dynamische taal waarin je gewoon leert hoe het typensysteem werkt en wat je eigenlijk kunt verwachten. Type shenanigans zijn zelden een probleem voor mij in JS. In sommige opzichten kan de flexibiliteit de dingen robuuster maken, hoewel het weliswaar een beetje geheimzinniger is voor een meer Jr.-level-ontwikkelaar als je niet weet wat de gaten in de taal zijn.

Scope op blokniveau vs. functiescope vs.?:

Blokniveau komt het meest voor (alles tussen {} in de meeste c-gebaseerde syntaxis-talen). JavaScript-bereik is gebouwd rond functies (die ook worden gebruikt om objecten zo effectief ook objecten te bouwen). Er is ook een grote variatie in wat voor soort toegang je hebt van binnenuit naar een buitenste scope. Ik “ben niet bekend met andere scoping-schemas, maar ik” weet zeker dat ze bestaan.

Klassieke OOP vs. Prototypal OOP vs. Bijna-OOP (structs in C ?) vs Non-OOP:

Zelfs in klasse-gebaseerde OOP is er veel ruimte voor variatie. Of je meervoudige overerving kunt doen (ieuw, ruim boven, ieuw), interfaces kunt definiëren, enz …

In JavaScript hebben we een soort van onvolgroeide hybride prototypische OOP waar objecten aanzienlijk eenvoudiger en in hoge mate veranderlijk zijn, maar we hebben nog steeds de mogelijkheid om de interface te scheiden van interne zorgen, wat IMO het belangrijkste aspect van inkapseling is .

Het ding over OOP is dat er echt veel dingen zijn die je kunt doen die in wezen OOP-gericht zijn zonder technisch OOP te zijn. Er zijn natuurlijk puristen, maar uiteindelijk gaat het bij Design Patterns om het bereiken van bepaalde abstracties die in bepaalde situaties goed werken. Ga er niet te snel van uit dat ideeën uit een OOP-gebaseerde taal niet bruikbaar zijn in iets dat meer procedureel georiënteerd is. En ik “heb het niet over JavaScript. Het wordt helemaal niet beperkt door de gekke versie van een op prototypes gebaseerd OOP-paradigma.

Eersteklas functies :

Als ik deze niet in een taal heb, is het moeilijk om op te geven. U kunt functies doorgeven alsof het gegevens zijn voor gebruik in andere contexten. Dit maakt met name schemas voor het afhandelen van gebeurtenissen heel gemakkelijk te implementeren, maar het maakt het ook heel gemakkelijk om de taal aan te passen om te werken zoals u dat wilt. Het is meer dan wat dan ook datgene dat JavaScript tot het succes heeft gemaakt. dat het de ultieme is, ondanks het feit dat het in twee weken tijd is ontworpen en er een syntaxis van ongeveer Java aan is toegevoegd als marketingschema.

Sluitingen:

Ik “weet niet zeker waar het debat over Java is, maar ik weet dat veel Java-ontwikkelaars een jaar of twee geleden om deze functie riepen. In een niet-afsluitende taal, wanneer een functie wordt gesloten, kan alles dat op de een of andere manier naar dingen van binnen die functie kan verwijzen, er geen toegang toe krijgen omdat het vuilnis is verzameld. Bij een afsluiting is de uitvoeringscontext zo gebonden dat als u “in staat zijn om naar dingen in die gesloten functie te verwijzen vanuit een ander bereik, zoals in een geretourneerd object of functie, krijg je die variabelen in feite zoals ze waren toen de functie werd gesloten. Het is alsof je je voet tussen de deur van garbage collection stoort, hoewel ik vermoed dat het meer is geïmplementeerd als kopieën van die vars die zijn gemaakt in lokale vars van de verwijzende entiteit.

Rigide / Streng / Veilig versus u alle touw geven dat u wilt:

JS-ontwikkelaars en Java-ontwikkelaars begrijpen meestal niet elk überhaupt anders en ik denk dat het veel te maken heeft met de twee talen die bijna tegenover elkaar liggen in dit specifieke ontwerpspectrum. Ik wil niet dat je me beschermt tegen mezelf of tegen de andere ontwikkelaars in mijn team. Ik wil veel meer doen met veel minder code en alles op heel verschillende (maar consistente voor een bepaald domein) manieren doen, afhankelijk van over de situatie. Er zijn absoluut afwegingen voor beide en veel talen vallen meer in het midden.

Reacties

• Goh bedankt. ' is erg leuk om de moeite te nemen voor een neerwaartse stemming zonder uitleg.

Ik denk dat een kortere weg naar al deze is om genoeg Lisp te leren om een aantal semi-nuttige dingen te doen. De meeste van deze paradigmas zijn begonnen als manieren om Lisp te gebruiken, dus het is een eenvoudige manier om dingen te proberen.

Er zijn een aantal “soorten” talen in de buurt, maar er kunnen altijd nieuwe verschijnen. In wezen is het doel van een taal om het coderen van ideeën, concepten of vereisten zo direct mogelijk mogelijk te maken. Daartoe kunnen er situaties zijn waarin bestaande paradigmas ontbreken en misschien een nieuwe nodig is.

Een manier om naar te kijken is in termen van oppervlaktestructuur. Hoe kunt u hiermee ideeën beknopt coderen, zodat als u van gedachten verandert over wat u wilt, de overeenkomstige wijziging van de code ook gemakkelijk is, met weinig kans om bugs te introduceren.

Een andere manier om kijk naar het is in termen van controlestructuur. Wanneer de taal wordt uitgevoerd (als dat zo is), wat is de volgorde waarin de dingen gebeuren, om te bereiken wat u wilt? Voorbeelden zijn: eenvoudige directe uitvoering, recursie, backtrack, parallellisme. Een die ik (bescheiden hoest) ontdekte was differentiële uitvoering .

Een ander nuttig standpunt is dat elke keer dat een datastructuur wordt ontworpen, een taal is geboren. Gegevens worden “uitgevoerd” door de applicatieprogrammas die er doorheen kammen en dingen doen, net zoals een programma slechts een hoop gegevens is (zoals bytecodes) die door een tolk worden gebruikt om dingen te doen.

Opmerkingen

• Cool. Ik zal LISP leren en verlicht worden. Spannend: D
• Als je echter zegt dat het gebruik van een datastructuur een nieuwe tussenliggende taal creëert, dan zou je ook kunnen beweren dat er in elk algoritme een nieuwe taal wordt geboren (alle bewerkingen worden noodzakelijkerwijs uitgevoerd op een data structuur), en met reductie wordt een nieuwe taal geboren in elke coderegel. Ik denk dat je echter iets anders bedoelt, maar ik ' weet niet zeker of ik het nog begrijp?
• @sova: Voor mij was informatietheorie een grote openbaring (zowel Shannon als Kolmogorov). Het ' gaat over hoe betekenissen worden gecodeerd en door kanalen worden doorgegeven, met concepten van bandbreedte, foutdetectie, minimale codering, willekeur, enzovoort. Gegevens coderen voor informatie en algoritmen zijn kanalen . Programmas coderen informatie en programmeren is een kanaal. Dus, welke informatie is gecodeerd? waar komt het vandaan en wanneer? waar gaat het heen? wat zijn de bronnen van fouten (ruis)? hoe worden ze gecorrigeerd? Ik vond dat een nuttig perspectief.
• @sova: (vervolg) Je hoeft ' niet alle onaangename wiskunde onder de knie te krijgen. Wat voor mij van belang was, was het kader dat het me gaf om over dingen na te denken.

Ik moet voeg toe dat er programmeertalen zijn voor specifieke toepassingen. Degene die in me opkomt is APT (Automatic Programmed Tool), een taal die wordt gebruikt in de productie van werktuigmachines.

Opmerkingen

• Ik herinner me die. Ik heb het misschien zelfs gebruikt. Jongen, dat was state-of-the-art. U hoeft de freesmachine niet ' handmatig te sturen, druk gewoon op de startknop. En als er een bug was, zou de hel losbarsten.
• Ik ' heb gewerkt aan programmas die gcode genereren voor freesmachines. Ik ' heb letterlijk de resultaten van programmeerfouten vastgehouden en gezien, vaak de mijne.
• Ik heb 20 jaar lang postprocessors geïnstalleerd op grote hoeveelheden systemen.