Wat is verklarende programmering?[gesluit]

StackOverflow https://stackoverflow.com/questions/129628

Vra

Ek hoor steeds hoe hierdie term in verskillende kontekste rondgeslinger word.Wat is dit?

Was dit nuttig?

Oplossing

Verklarende ontwikkeling is wanneer jy jou kode te skryf op so 'n manier dat dit beskryf wat jy wil doen, en nie hoe jy dit wil doen. Dit is oorgelaat aan die samesteller om uit te vind die hoe.

Voorbeelde van verklarende programmeertale is SQL en Prolog.

Ander wenke

Die ander antwoorde reeds doen 'n fantastiese werk te verduidelik wat verklarende programmeertaal is, so ek gaan net na 'n paar voorbeelde van hoekom dit nuttig kan wees bied.

Konteks Independence

Verklarende Programme is konteks-onafhanklike . Omdat hulle net te kenne gee wat die uiteindelike doel is, maar nie die tussenganger stappe om daardie doel te bereik, kan dieselfde program gebruik word in verskillende kontekste. Dit is moeilik om te doen met noodsaaklik programme , omdat hulle dikwels afhang van die konteks (bv verborge staat).

Neem yacc as 'n voorbeeld. Dit is 'n parser generator aka. samesteller samesteller, 'n eksterne verklarende DSL vir die beskrywing van die grammatika van 'n taal, sodat 'n ontleder vir daardie taal outomaties gegenereer kan word uit die beskrywing. As gevolg van sy konteks onafhanklikheid, kan jy baie verskillende dinge te doen met so 'n grammatika:

  • Genereer 'n C parser vir daardie taal (die oorspronklike gebruik geval vir yacc)
  • Genereer 'n C ++ parser vir daardie taal
  • Genereer 'n Java ontleder vir daardie taal (met behulp van Jay)
  • Genereer 'n C # parser vir daardie taal (met behulp van GPPG)
  • Genereer 'n Ruby parser vir daardie taal (met behulp van RACC)
  • Genereer 'n boom visualisering vir daardie taal (met behulp van Graphviz)
  • eenvoudig doen 'n paar mooi-drukwerk, fancy-uitleg en accentuering van die yacc, ens bron lêer self en sluit dit in jou Reference Manual as 'n sintaktiese spesifikasie van jou taal

En nog vele meer ...

Optimization

Omdat jy nie die rekenaar watter stappe om te neem en in watter volgorde te skryf, kan dit herrangskik jou program baie meer vrylik, miskien selfs 'n paar take uit te voer in parallel. 'N Goeie voorbeeld is 'n navraag beplanner en navraag optimizer vir 'n SQL databasis. Die meeste SQL databasis toelaat om die navraag dat hulle vertoon eintlik uitvoering teen die navraag wat jy gevra hulle uit te voer. Dikwels is dié navrae kyk niks soos elke ander. Die navraag beplanner neem dinge in ag neem dat jy sou nie eens gedroom van: rotasie latency van die skyf skinkbord, byvoorbeeld of die feit dat 'n paar heel ander aansoek om 'n heeltemal ander gebruiker net 'n soortgelyke navraag uitgevoer en die tafel dat jy aansluiting met en dat jy so hard om die laai te vermy gewerk is reeds in die geheue in elk geval.

Daar is 'n interessante trade-off hier: die masjien het om harder te werk om uit te vind hoe om iets te doen as wat dit sou in 'n noodsaaklik taal, maar wanneer dit nie figuur dit uit, dit het veel meer vryheid en nog baie meer inligting vir die optimalisering stadium.

Losweg:

Verklarende programmering neig na:-

  • Stel verklarings, of verklarende stellings, wat elk betekenis het (dikwels in die probleemdomein) en onafhanklik en in isolasie verstaan ​​kan word.

Imperatiewe programmering neig na:-

  • Opeenvolgings van opdragte, wat elkeen een of ander aksie uitvoer;maar wat in die probleemdomein betekenis mag hê of nie.

As gevolg hiervan help 'n imperatiewe styl die leser om die meganika van wat die stelsel eintlik doen te verstaan, maar kan min insig gee in die probleem wat dit bedoel is om op te los.Aan die ander kant help 'n verklarende styl die leser om die probleemdomein en die benadering wat die sisteem tot die oplossing van die probleem volg, te verstaan, maar is minder insiggewend oor meganika.

Regte programme (selfs dié wat geskryf is in tale wat die uiteinde van die spektrum bevoordeel, soos ProLog of C) is geneig om beide style in verskillende grade op verskillende punte aan te bied, om die verskillende kompleksiteite en kommunikasiebehoeftes van die stuk te bevredig.Een styl is nie beter as die ander nie;hulle dien net verskillende doeleindes, en, soos met baie dinge in die lewe, is moderering die sleutel.

Ek is jammer, maar ek moet saamstem met baie van die ander antwoorde. Ek wil graag van hierdie vaag misverstand van die definisie van verklarende programmeertaal te stop.

Definisie

Verwysings- deursigtigheid (RT) van die sub-uitdrukkings is die enigste vereiste kenmerk van 'n verklarende programmeertaal uitdrukking , want dit is die enigste eienskap wat nie gedeel word met noodsaaklik programmering.

Ander aangehaal eienskappe van verklarende programmeertaal, trek uit hierdie RT. Klik op die skakel hierbo vir die volledige uiteensetting.

Spreadsheet voorbeeld

Twee antwoorde genoem spreadsheet program. In die gevalle waar die sigblad program (ook bekend as formules) nie wispelturig toegang globale staat, dan is dit verklarende programmeertaal. Dit is omdat die wispelturig sel waardes is die monolitiese insette en uitset van die main() (die hele program). Die nuwe waardes is nie geskryf om die selle na elke formule voltrek word nie, daarom is hulle nie wispelturig vir die lewe van die verklarende program (uitvoering van al die formules in die sigblad). So relatief tot mekaar, die formules te sien hierdie wispelturig selle as onveranderlike. 'N RT funksie is toegelaat om toegang onveranderlike globale staat (en wispelturig plaaslike toestand ).

So het die vermoë om die waardes in die selle muteer wanneer die program beëindig (as 'n uitset van main()), nie hulle wispelturig gestoor waardes maak in die konteks van die reëls. Die sleutel onderskeid is die sel waardes is nie opgedateer na elke spreadsheet formule uitgevoer word, dus aan die orde van die uitvoering van die formules maak nie saak. Die sel waardes opgedateer na al die verklarende formules is uitgevoer.

Hier is 'n voorbeeld.

In CSS (wat gebruik word om styl HTML bladsye), as jy wil 'n beeld element te wees 100 pixels hoog en 100 pixels wyd, jy eenvoudig "verklaar" dat dit is wat jy wil as volg: 

#myImageId {
height: 100px;
width: 100px;
}

Jy kan oorweeg CSS n verklarende "stylblad" taal.

Die leser enjin wat lees en interpreteer hierdie CSS is vry om te maak die beeld verskyn hierdie lang en hierdie wye egter dit wil. Ander leser enjins (bv die enjin vir Internet Explorer, die enjin vir Chrome) sal hierdie taak anders te implementeer.

Die unieke implementering is, natuurlik, nie geskryf in 'n verklarende taal, maar in 'n prosedurele een soos Vergadering, C, C ++, Java, JavaScript, of Python. Wat-kode is 'n klomp van die stappe om stap vir stap uitgevoer word (en kan insluit funksie oproepe). Dit mag dalk dinge doen soos Interpoleer pixel waardes, en lewer op die skerm.

Verklarende ontwikkeling is die prentjie, waar noodsaaklik programmering is instruksies vir die verf van die foto.

Jy skryf in 'n verklarende styl as jy "Vertel dit wat dit is", eerder as die beskrywing van die stappe wat die rekenaar moet neem na die plek waar jy dit wil kry.

As jy XML gebruik om te merk-up data, gebruik jy verklarende programmeertaal omdat jy sê: "Dit is 'n persoon, dit is 'n verjaarsdag, en daar is 'n straat adres".

'n Paar voorbeelde van waar verklarende en noodsaaklik programmering kry gekombineer vir 'n groter effek:

  • Windows Presentation Foundation gebruik verklarende XML sintaks om te beskryf wat 'n gebruikerskoppelvlak lyk, en wat die verhoudings (bindings) is tussen die kontrole en onderliggende data strukture.

  • Gestruktureerde konfigurasielêers gebruik verklarende sintaksis (so eenvoudig soos "sleutel = waarde" pare) te identifiseer wat 'n string of waarde van data beteken.

  • HTML punte tot teks met etikette wat beskryf watter rol elke stuk van die teks het met betrekking tot die hele dokument.

verbeel 'n Excel bladsy. Met kolomme wat gevul is met formules om jou te bereken belastingopgawe.

Al die logika gedoen verklaar in die selle, is aan die orde van die berekening deur te bepaal deur formule self eerder as prosedureel.

Dit is 'n soort van watter verklarende programmeertaal is alles oor. Jy verklaar die probleem ruimte en die oplossing eerder as om die vloei van die program.

Prolog is die enigste verklarende taal Ek het gebruik. Dit vereis 'n ander soort van denke, maar dit is goed om te leer as net om jou bloot te stel aan iets anders as die tipiese prosedurele programmeertaal.

Sedert ek my vorige antwoord geskryf het, het ek 'n geformuleer nuwe definisie van die verklarende eiendom wat hieronder aangehaal word.Ek het ook noodsaaklike programmering gedefinieer as die dubbele eienskap.

Hierdie definisie is beter as die een wat ek in my vorige antwoord verskaf het, want dit is bondig en dit is meer algemeen.Maar dit kan moeiliker wees om te grok, want die implikasie van die onvoltooidheidstellings wat van toepassing is op programmering en die lewe in die algemeen is moeilik vir mense om hul gedagtes om te draai.

Die aangehaalde verduideliking van die definisie bespreek die rol suiwer funksionele programmering speel in verklarende programmering.

Verklarend vs.Noodsaaklik

Die verklarende eienskap is vreemd, stomp en moeilik om vas te vang in 'n tegnies presiese definisie wat algemeen en nie dubbelsinnig bly nie, want dit is 'n naïewe opvatting dat ons die betekenis (a.k.a. semantiek) van die program kan verklaar sonder om onbedoelde newe-effekte op te doen.Daar is 'n inherente spanning tussen uitdrukking van betekenis en vermyding van onbedoelde effekte, en hierdie spanning spruit eintlik voort uit die onvoltooidheidstellings van programmering en ons heelal.

Dit is oorvereenvoudig, tegnies onakkuraat en dikwels dubbelsinnig om verklarend te definieer as “wat om te doen” en noodsaaklik as “hoe om te doen”.'n Dubbelsinnige geval is die "wat" is die "hoe” in 'n program wat 'n program uitvoer— 'n samesteller.

Klaarblyklik die onbeperkte rekursie wat 'n taal Turing volledig maak, is ook analoog in die semantiek - nie net in die sintaktiese struktuur van evaluering nie (a.k.a.operasionele semantiek).Dit is logies 'n voorbeeld analoog aan Gödel se stelling— "enige volledige stelsel van aksiomas is ook inkonsekwent”.Dink na oor die teenstrydige vreemdheid van daardie aanhaling!Dit is ook 'n voorbeeld wat demonstreer hoe die uitdrukking van semantiek nie 'n bewysbare grens het nie, dus kan ons nie bewys nie2 dat 'n program (en analoog die semantiek daarvan) a.k.a.die Stopstelling.

Die onvoltooidheidstellings spruit voort uit die fundamentele aard van ons heelal, wat soos gestel in die Tweede Wet van Termodinamika is "die entropie (a.k.a.die aantal onafhanklike moontlikhede) neig vir ewig na maksimum”.Die kodering en ontwerp van 'n program is nooit klaar nie - dit is lewendig! - want dit poog om 'n werklike wêreldbehoefte aan te spreek, en die semantiek van die regte wêreld verander altyd en neig na meer moontlikhede.Mense hou nooit op om nuwe dinge te ontdek nie (insluitend foute in programme ;-).

Om hierdie bogenoemde gewenste idee presies en tegnies vas te lê binne hierdie vreemde heelal wat geen voorsprong het nie (bedink dit!daar is geen "buitekant" van ons heelal nie), vereis 'n bondige maar bedrieglik-nie-eenvoudige definisie wat verkeerd sal klink totdat dit diep verduidelik word.

Definisie:

Die verklarende eienskap is waar daar slegs een moontlike stel stellings kan bestaan ​​wat elke spesifieke modulêre semantiek kan uitdruk.

Die noodsaaklike eiendom3 is die tweeledige, waar semantiek inkonsekwent is onder samestelling en/of uitgedruk kan word met variasies van stelle stellings.

Hierdie definisie van verklarend is kenmerkend plaaslike in semantiese omvang, wat beteken dat dit vereis dat 'n modulêre semantiek sy konsekwente betekenis handhaaf, ongeag waar en hoe dit geïnstansieer en gebruik word in wêreldwyd omvang.Dus moet elke verklarende modulêre semantiek intrinsiek ortogonaal wees tot alle moontlike ander - en nie 'n onmoontlike nie (as gevolg van onvolledigheidstellings) wêreldwyd algoritme of model om konsekwentheid te sien, wat ook die punt is van "Meer is nie altyd beter nie” deur Robert Harper, professor in rekenaarwetenskap aan die Carnegie Mellon Universiteit, een van die ontwerpers van Standard ML.

Voorbeelde van hierdie modulêre verklarende semantiek sluit kategorie teorie funktore in, bv. die Applicative, nominale tik, naamruimtes, benoemde velde, en w.r.t.tot operasionele vlak van semantiek dan suiwer funksionele programmering.

So kan goed ontwerpte verklarende tale betekenis duideliker uitdruk, alhoewel met 'n mate van verlies aan algemeenheid in wat uitgedruk kan word, tog 'n wins in wat met intrinsieke konsekwentheid uitgedruk kan word.

'n Voorbeeld van die voorgenoemde definisie is die stel formules in die selle van 'n sigbladprogram— wat nie na verwagting dieselfde betekenis sal gee wanneer na verskillende kolom- en ryselle geskuif word nie, d.w.s.sel identifiseerders verander.Die sel-identifiseerders is deel van en nie oorbodig vir die beoogde betekenis nie.So elke sigbladresultaat is uniek w.t.t.na die sel-identifiseerders in 'n stel formules.Die konsekwente modulêre semantiek in hierdie geval is die gebruik van sel-identifiseerders as die inset en uitvoer van suiwer funksies vir selle formules (sien hieronder).

Hyper Text Markup Language a.k.a.HTML - die taal vir statiese webblaaie - is 'n voorbeeld van 'n hoogs (maar nie perfek nie3) verklarende taal wat (ten minste voor HTML 5) geen vermoë gehad het om dinamiese gedrag uit te druk nie.HTML is miskien die maklikste taal om te leer.Vir dinamiese gedrag is 'n noodsaaklike skriftaal soos JavaScript gewoonlik gekombineer met HTML.HTML sonder JavaScript pas by die verklarende definisie omdat elke nominale tipe (d.w.s.die etikette) behou sy konsekwente betekenis onder samestelling binne die reëls van die sintaksis.

'n Mededingende definisie vir verklarend is die kommutatief en idempotent eienskappe van die semantiese stellings, m.a.w.dat stellings herrangskik en gedupliseer kan word sonder om die betekenis te verander.Byvoorbeeld, stellings wat waardes toeken aan benoemde velde kan herrangskik en gedupliseer word sonder om die betekenis van die program te verander, as daardie name modulêr is w.r.t.na enige stilswyende bevel.Name impliseer soms 'n volgorde, bv.sel-identifiseerders sluit hul kolom- en ryposisie in - om 'n totaal op sigblad te skuif, verander die betekenis daarvan.Andersins vereis hierdie eienskappe implisiet wêreldwyd konsekwentheid van semantiek.Dit is oor die algemeen onmoontlik om die semantiek van stellings te ontwerp sodat hulle konsekwent bly as dit lukraak georden of gedupliseer word, want volgorde en duplisering is intrinsiek aan semantiek.Byvoorbeeld, die stellings "Foo bestaan" (of konstruksie) en "Foo bestaan ​​nie" (en vernietiging).As 'n mens ewekansige inkonsekwentheid endemies van die beoogde semantiek beskou, dan aanvaar 'n mens hierdie definisie as algemeen genoeg vir die verklarende eienskap.In wese is hierdie definisie leeg as 'n algemene definisie omdat dit poog om konsekwentheid ortogonaal tot semantiek te maak, m.a.w.om die feit te trotseer dat die heelal van semantiek dinamies onbeperk is en nie vasgevang kan word in 'n wêreldwyd koherensie paradigma.

Deur die kommutatiewe en idempotente eienskappe vir die (strukturele evaluasieorde van die) laervlak operasionele semantiek te vereis, word operasionele semantiek omgeskakel na 'n verklarende gelokaliseer modulêre semantiese, bv. suiwer funksionele programmering (insluitend rekursie in plaas van noodsaaklike lusse).Dan het die operasionele volgorde van die implementeringbesonderhede geen impak nie (d.w.s.versprei wêreldwyd in) die konsekwentheid van die hoërvlak semantiek.Byvoorbeeld, die volgorde van evaluering van (en teoreties ook die duplisering van) die sigbladformules maak nie saak nie, want die uitsette word nie na die insette gekopieer totdat alle uitsette bereken is nie, d.w.s.analoog aan suiwer funksies.

C, Java, C++, C#, PHP en JavaScript is nie besonder verklarend nie.Copute se sintaksis en Python se sintaksis is meer verklarend gekoppel aan beoogde resultate, d.w.s.Konsekwente sintaktiese semantiek wat die vreemdeling uitskakel, sodat 'n mens die kode maklik kan begryp nadat hulle dit vergeet het.Kopieer en Haskell handhaaf determinisme van die operasionele semantiek en moedig aan “Moenie jouself herhaal nie” (DROOG), want hulle laat net die suiwer funksionele paradigma toe.

2 Selfs waar ons die semantiek van 'n program kan bewys, bv.met die taal Coq is dit beperk tot die semantiek waarin uitgedruk word die tik, en tik kan nooit al die semantiek van 'n program vasvang nie - selfs nie vir tale wat nie Turing volledig is nie, bv.met HTML+CSS is dit moontlik om inkonsekwente kombinasies uit te druk wat dus ongedefinieerde semantiek het.

3 Baie verduidelikings beweer verkeerdelik dat slegs noodsaaklike programmering sintakties geordende stellings het.Ek het dit uitgeklaar verwarring tussen imperatiewe en funksionele programmering.Byvoorbeeld, die volgorde van HTML-stellings verminder nie die konsekwentheid van hul betekenis nie.

Wysig:Ek het die volgende kommentaar na Robert Harper se blog:

in funksionele programmering ...die omvang van variasie van 'n veranderlike is 'n tipe

Afhangend van hoe 'n mens funksioneel van imperatiewe programmering onderskei, kan u 'toewysbare' in 'n noodsaaklike program ook 'n tipe hê wat 'n grens op die veranderlikheid daarvan plaas.

Die enigste definisie wat ek nie vir funksionele programmering waardeer nie, is a) funksies as eersteklas voorwerpe en -tipes, b) voorkeur vir rekursie bo lusse, en/of c) suiwer funksies-dwsDaardie funksies wat nie die gewenste semantiek van die program beïnvloed wanneer dit gemem word nie (Dus bestaan ​​perfek suiwer funksionele programmering nie in 'n algemene denotasionele semantiek nie as gevolg van die gevolge van operasionele semantiek, bvGeheue -toekenning).

Die idempotente eienskap van 'n suiwer funksie beteken dat die funksie -oproep op sy veranderlikes deur die waarde daarvan vervang kan word, wat nie oor die algemeen die geval is vir die argumente van 'n noodsaaklike prosedure nie.Suiwer funksies blyk verklarende WRT te weesna die ongekomponeerde toestandsoorgange tussen die inset- en resultaattipes.

Maar die samestelling van suiwer funksies handhaaf nie so 'n konsekwentheid nie, omdat dit moontlik is om 'n newe-effek (wêreldtoestand) noodsaaklike proses in 'n suiwer funksionele programmeringstaal te modelleer, bvHaskell se IOMonad en dit is boonop heeltemal onmoontlik om te voorkom dat u dit doen in enige volledige suiwer funksionele programmeringstaal.

Soos ek geskryf het in 2012 wat vir die soortgelyke konsensus van kommentaar in jou onlangse blog, dat verklarende programmering 'n poging is om die idee vas te lê dat die beoogde semantiek nooit ondeursigtig is nie.Voorbeelde van ondeursigtige semantiek is afhanklikheid van orde, afhanklikheid van die uitwissing van hoërvlak semantiek by die operasionele semantieklaag (bv Rolvergies is nie omskakelings nie en het die generiese generika op hoër vlak semantiek beperk), en afhanklikheid van veranderlike waardes wat nie deur die programmeringstaal gekontroleer kan word nie.

Ek het dus tot die gevolgtrekking gekom dat slegs nie-ture volledige tale verklaar kan wees.

Dus kan 'n ondubbelsinnige en duidelike kenmerk van 'n verklarende taal wees dat die uitset daarvan bewys kan word om 'n paar onheilspellende stel generatiewe reëls te gehoorsaam.Byvoorbeeld, vir enige spesifieke HTML -program (ignoreer verskille in die manier waarop tolke uiteenlopend is) wat nie geskrewe is nie (dit wil sêis nie volledig volledig nie), dan kan die uitsetveranderlikheid dit ontelbaar wees.Of meer bondig 'n HTML -program is 'n suiwer funksie van die veranderlikheid daarvan.Ditto 'n sigbladprogram is 'n suiwer funksie van sy insetveranderlikes.

Dit lyk dus vir my of verklarende tale die antitese van is onbeperkte rekursie, d.w.s.Per Gödel se tweede onvolledigheid-stelling Selfverwysende stellings kan nie bewys word nie.

Lesie Lamport geskryf het 'N Sprokie oor hoe Euclid kon gewerk het rondom Gödel se onvolledigheidstesigings wat op wiskundebewyse in die programmeringstaalkonteks toegepas is deur die kongruensie tussen tipes en logika (korrespondensie van kerrie -hartigheid, ens.).

Dit is 'n metode van programmering gebaseer rondom die beskrywing van wat iets moet doen of wees in plaas van die beskrywing van hoe Dit behoort te werk.

Met ander woorde, jy hoef nie algoritmes gemaak van uitdrukkings skryf, jy moet net uitleg hoe jy wil hê dinge moet wees. Twee goeie voorbeelde is HTML en WPF.

Hierdie artikel Wikipedia is 'n goeie oorsig: http://en.wikipedia.org/wiki/Declarative_programming

Die beskrywing van 'n rekenaar wat jy wil hê, nie hoe om iets te doen.

Ek het my begrip van verklarende programmeertaal verfyn, aangesien Desember 2011 toe ek met dien verstande 'n antwoord op hierdie vraag. Hier volg my huidige begrip.

Die lang weergawe van my verstand (navorsing) is uiteengesit op hierdie skakel , wat jy moet lees om 'n diep begrip van die opsomming ek sal hieronder verskaf verkry.

Imperatief ontwikkeling is waar wispelturig staat is gestoor en lees, dus die bestelling en / of duplisering van program instruksies kan die gedrag (semantiek) van die program te verander (en selfs veroorsaak dat 'n fout, dit wil sê onbedoelde gedrag).

In die meeste naïef en uiterste sin (wat ek beweer in my vorige antwoord), verklarende programmeertaal (DP) is die voorkoms van al gestoor wispelturig staat, dus die bestelling en / of duplisering van program instruksies kan nie verander die gedrag (semantiek) van die program.

Maar so 'n uiterste definisie sou nie baie nuttig in die werklike wêreld te wees, aangesien byna elke program behels gestoor wispelturig staat. Die spreadsheet voorbeeld voldoen aan hierdie uiterste definisie van DP, want die hele program kode uitgevoer word na voltooiing met een statiese afskrif van die insette staat, voor die nuwe state gestoor. As iemand toestand verander, is dit herhaal. Maar die meeste werklike wêreld programme kan nie beperk word tot so 'n monolitiese model van die staat veranderinge.

'n meer bruikbare definisie van DP is dat die bestelling en / of duplisering van programme instruksies het nie ondeursigtig semantiek verander. Met ander woorde, is daar nie verborge ewekansige veranderinge in semantiek occurring-- enige veranderinge in programinstruksie orde en / of duplisering oorsaak slegs bedoel en deursigtige veranderinge aan gedrag van die program.

Die volgende stap sou wees om te praat oor wat programmeringsmodelle of paradigmas hulp in DP, maar dit is nie die vraag hier.

Verklarende Programmering is programme met verklarings, dit wil sê verklarende sinne. Verklarende sinne het 'n aantal eienskappe wat hulle onderskei van noodsaaklik sinne. In die besonder, verklarings is:

  • kommutatiewe (kan bijgesteld)
  • assosiatiewe (kan hergroepeer)
  • idempotente (kan herhaal sonder verandering in betekenis)
  • monotoniese (verklarings nie inligting aftrek)

'n relevante punt is dat dit al die strukturele eienskappe en is ortogonaal op aangeleentheid onderwerp. Verklarende gaan nie oor "Wat vs. Hoe" . Ons kan verklaar (verteenwoordig en dwing) 'n "hoe" net so maklik as ons verklaar 'n "wat" . Verklarende is oor struktuur, nie inhoud. Verklarende ontwikkeling het 'n beduidende impak op die manier waarop ons abstrakte en refactor ons kode, en hoe ons modularize dit in subprogramme, maar nie soseer op die domein model.

Dikwels kan ons skakel by noodsaaklik om verklarende deur die toevoeging van konteks. Bv vanaf "Draai links. (... wag vir dit ...) Draai regs." na "Bob sal draai links by die kruising van Foo en Bar by 11:01. Bob sal regs draai by die kruising van Bar en Baz by 11:06." Let daarop dat in laasgenoemde geval die sinne is idempotente en kommutatiewe, terwyl dit in die eerste geval herrangskik of herhaling van die sinne sou die betekenis van die program erg verander.

Met betrekking tot monotoniese , verklarings kan voeg beperkings wat aftrek moontlikhede . Maar beperkings inligting voeg nog (meer presies, beperkings is inligting). As ons-time wisselende verklarings nodig, dit is 'n tipiese om hierdie model met eksplisiete tydelike semantiek - bv vanaf "die bal is plat" na "die bal is plat op tydstip t". As ons twee teenstrydige verklarings, ons het 'n teenstrydig verklarende stelsel, al is dit dalk opgelos word deur die instelling van sagte beperkings (prioriteite, waarskynlikhede, ens) of gebruik te maak van 'n paraconsistent logika.

Verklarende ontwikkeling is "die daad van programmering in tale wat in ooreenstemming is met die geestelike model van die ontwikkelaar, eerder as die operasionele model van die masjien".

Die verskil tussen verklarende en noodsaaklik ontwikkeling is goed geïllustreer deur die probleem van die ontleding van gestruktureerde data.

'n noodsaaklik program sal wedersyds rekursiewe funksies te gebruik om te verteer insette en genereer data. 'N verklarende program sal 'n grammatika wat definieer druk die struktuur van die data sodat dit dan kan ontleed word.

Die verskil tussen hierdie twee benaderings is dat die verklarende program skep 'n nuwe taal wat nader is gekarteer om die geestelike model van die probleem as wat sy gasheer taal.

Dit klink dalk vreemd, maar ek wil Excel (of enige spreadsheet regtig) na die lys van verklarende stelsels te voeg. 'N Goeie voorbeeld hiervan is gegee hier .

Ek sal dit verduidelik as DP is 'n manier om uit te druk

  • 'n doel uitdrukking , die voorwaardes vir - wat ons is op soek na. Is daar een, miskien of baie?
  • Sommige bekende feite
  • Reëls wat die know feite uit te brei

... en waar daar 'n Trek enjin gewoonlik saam met 'n eenwording algoritme om die doelwitte te vind.

Sover ek kan sê, dit begin gebruik programmering stelsels soos Prolog te beskryf, want Prolog is (vermoedelik) oor te verklaar dinge in 'n abstrakte manier.

Dit beteken toenemend bitter min, want dit het die definisie deur die gebruikers hierbo. Dit moet duidelik wees dat daar 'n kloof tussen die verklarende programmeertaal van Haskell, as teen die verklarende programmeertaal van HTML.

'n Paar ander voorbeelde van verklarende programmering:

  • ASP.Net-opmerk vir databinding.Dit sê byvoorbeeld net "vul hierdie rooster met hierdie bron", en laat dit aan die stelsel oor hoe dit gebeur.
  • Linq uitdrukkings

Verklarende programmering is lekker, want dit kan help vereenvoudig jou geestelike model* van kode, en omdat dit uiteindelik meer skaalbaar kan wees.

Byvoorbeeld, kom ons sê jy het 'n funksie wat iets aan elke element in 'n skikking of lys doen.Tradisionele kode sal soos volg lyk:

foreach (object item in MyList)
{
   DoSomething(item);
}

Geen groot probleem daar nie.Maar wat as jy die meer verklarende sintaksis gebruik en eerder DoSomething() as 'n aksie definieer?Dan kan jy dit so sê:

MyList.ForEach(DoSometing);

Dit is natuurlik meer bondig.Maar ek is seker jy het meer bekommernisse as om net twee reëls kode hier en daar te stoor.Prestasie, byvoorbeeld.Die ou manier, verwerking moes in volgorde gedoen word.Wat as die .ForEach()-metode 'n manier het om aan te dui dat dit outomaties die verwerking parallel kan hanteer?Nou het jy skielik jou kode op 'n baie veilige manier multi-threaded gemaak en net een reël kode verander.En in werklikheid is daar 'n an uitbreiding vir .Net waarmee jy net dit kan doen.

  • As jy daardie skakel volg, neem dit jou na 'n blogplasing deur 'n vriend van my.Die hele pos is 'n bietjie lank, maar jy kan afrol na die opskrif met die titel "Die probleem" _en tel dit daar op, geen probleem nie.*

Dit hang af van hoe jy die antwoord aan die teks. Algehele jy kan kyk na die program op 'n sekere siening maar dit hang af watter hoek jy kyk na die probleem. Ek sal jou by die program: Dowwe Bus, Car, Tyd, Hoogte As Integr

Dit hang weer af van wat die probleem is 'n algehele. Jy kan hê om dit te verkort as gevolg van die program. Hoop dit help en moet die terugvoer indien dit nie gebeur nie. Dankie.

Gelisensieer onder: CC-BY-SA met toeskrywing
Nie verbonde aan StackOverflow
scroll top