sciencetalk

Alleen lisp vind ik totaal niet functioneren.

Dan heb je het niet begrepen. Er is namelijk 'niks' mis met Lisp. Niet geschikt voor elk programmeerprobleem, maar dat is geen enkele taal.

@Cycloon: Lisp is geen scripttaal.

Het "probleem" van lisp is voornamelijk dat het meer kan dan andere talen. Het is een dynamische, functionele taal op de basis (elke expressie heeft een waarde, er zijn geen statements), maar je kun met weinig moeite er een logische taal (prolog style) aan toevoegen als je wilt. Dit lukt je niet in C zonder C te gebruiken om een prolog interpreter te schrijven (waarin je dan echter weer geen C kunt gebruiken).

Lisp komt uit 1959, alleen fortran is ouder. Toch was het vrij eenvoudig om het uit te breiden met bijvoorbeeld objecten of aspecten, of welk andere idee dat er ook nog mag komen: "Lisp is a extensible language."

De reden hiervoor is dat de notatie van de taal min of meer een AST is. Lisp code is een intern data-type, op deze manier kun je programmas schijven die nieuwe syntax introduceren en naar lisp compileren (de macro evalueert naar lisp code die dan geëvalueerd moet worden). Men noemt deze programmas macros (heeft niets te maken met C macros) maar als je niet beter weet zijn ze niet te onderscheiden van "normale" functies.

Dit betekend dat je in Lisp uitbreid in richting van het probleemdomein ("Het zou wel handig zijn als mijn programmeer taal dit en dat kon...") en schrijft vervolgens het programma in deze zeer geschikte taal.

Dit is een vorm van meta-programmeren en er zijn nog niet veel programmeurs die zo abstract kunnen denken.

Een programmeertaal waarbij je eigen commandos gaat toevoegen is een horror.

Wat wel kan is een taal met vaste commandos, die eens per jaar universeel GRATIS wordt uitgebreid en waarbij de commandos niet andere dingen gaat doen zoals bij windows.

A doet A en B doet B en niet een beetje anders A en een beetje anders B.

Iedereen moet met dezelfde versie werken en kunnen updaten.

Dit is het behoud van de taal.

In de taal moet je eigen funkties op kunnen roepen en zien dat deze verschillen van de commandos van de taal.

Daarvoor heb je een teken of syntax nodig.

de horror:

Het is ene horror omdat een taal onderling wordt uitgewisseld door de gebruikers.

Je bekomt dan gebruikersgroepen die met de veranderingen gaan werken en er ontstaan dan zo meerdere talen die dan met elkaar gaan paren met alle fouten van dien.

Een programmeertaal is geen taal zoals de taal nederlands.

Het omvat orders die precies zo uitgevoerd moeten worden zoals de taal beschrijft in de handleiding.

Pi geeft pi af en niet iets anders.

Vroeger in 1988 heb ik bij Philips in Den Haag nog eens een gesprek gehad over een taal met een fundament die 100% was en die bij een missend commando of file de telefoonlijn kon pakken om dat commando of file op te halen om zo de zaak weer compleet te maken.

De compiler moet dan tijdens het compileerproces wel goed werken en hiermee om kunnen gaan op een goede manier want anders zit je weer dagen te wachten tot het gecompileerd is.

Helaas zagen ze er niets in.

Dat systeem moest ook werken als men een programma naar je computer processor vertaalde om zo deze te kunnen runnen.

Geen missende DLL etc etc.

En een taal met groeipotentieel.

Een programmeertaal waarbij je eigen commandos gaat toevoegen is een horror.

Elk methode/functie kan men als "een commando" zien dus ik mag hopen dat het mogelijk is om de taal in elk geval op die manier te kunnen gebruiken.

Voor de rest, is het erg handig als je de grammatica/syntax kunt veranderen. Maar uiteraard vereist dit een zekere verantwoordelijkheidsgevoel en expertise van de programmeur. Een auto kan handig zijn maar iemand die het verkeerd gebruikt kan grote schade aanrichten.

Er zijn mensen die vinden dat je programmeurs "tegen hunzelf moet beschermen", dan krijg je talen zoals Java (waar standaard classes final zijn... grrrr).

Er zijn ook mensen die vinden dat je programmeurs zo krachtig mogelijke talen moet geven en dan krijg je bijvoorbeeld Lisp.

Ik vond nog een interesante essay: Holding a Program in One's Head

Er zijn mensen die vinden dat je programmeurs "tegen hunzelf moet beschermen", dan krijg je talen zoals Java (waar standaard classes final zijn... grrrr).

Gezien een van de doelen van Java is final helemaal geen slecht idee (als het niet bedoeld is om een afgeleide te maken dan kan dat gewoon ook niet). Bovendien negeer je hier het feit dat alle mensen, dus ook programmeurs, debiel zijn en dus waarschijnlijk de bescherming nodig hebben (of ze dat nu willen onderkennen of niet).

Er zijn ook mensen die vinden dat je programmeurs zo krachtig mogelijke talen moet geven

En daar is ook iets voor te zeggen. Het antwoord is natuurlijk wel volledig afhankelijk van hoe je 'kracht' definieert. Alle vormen van kracht hebben echter altijd een prijs.

In pascal eindigt een hoop zaken op end;.

In lisp is dat dan een ) teken.

Leuk voor de compiler...

maar voor de programmeur die fouten maakt bij het intypen en zit te programmeren is het een ramp.

Daarom moet een compiler systeem op zulke fouten van de programmeur alert reageren.

Dat kan met meer commandos voor end.

Bij while hoort wend en bij for next.

Ik heb ook if endif, when endwhen react en endreact zodat men meerdere if structuren heb.

De compiler kan dan een missende endreact vermelden en de structuur bewaken tussen endif, endreact etc.

De compiler verwerkt minimaal 100000 commandos per seconde waardoor hij beter kan werken als elke programmeur.

Ook voor de beginnende gebruiker is dit systeem beter omdat deze gebruikers vergeten een NEXT te typen op een for.

In pascal kan men achter then maar 1 commando typen: komt zo weinig voor dat men altijd then begin nodig heeft.

Daarom is het onzinnig om een then enkelvoudig toe te passen.

Voor de logica is het leuk maar door then begin bekomt men moeie vingers door constant die begin te moeten typen.

Die 1 commando filosofie stamt nog uit de oertijd waarmen met systeemkaarten zat te werken.....

Wel leuk eigenlijk, je pakte de kaartenbak en pakte de data bijeen en maakte er een stapel van.

En hup de kaartlezer in die dan kaart voor kaart las.

Oh mijn god voor diegene die zo'n stapel uit zijn handen liet vallen.

Heel het programma lag dan ongesorteerd over de vloer.

Mijn eerste compiuter waarop ik wat deed was een Philips met 3 werkstations waarvan 1 met monitor en 2 met printer en toetsenbord.

Dus je moet werken zonder monitor....

Dat was in 1976.

Naderhand heb ik wat gedaan op een TANDY Model 4.

Maar liefst 80 tekenstjes op een regel en 24 regel vertikaal.

Je had 64000 byte geheugen waarvan maar liefst 1800 op werd gesoupeerd door dat videogeheugen.

Voor de basic had men 16k nodig..

Voor mijn tekstverwerker had ik hetzelfde ontwerp als nu de indeling van XP.

Een balk boven, een balk beneden waarbij deze in secties was opgedeelt.

Voor de tekst had je maar 14 regels ofzo want anders kon men niet snel genoeg scrollen.

Daarom moet een compiler systeem op zulke fouten van de programmeur alert reageren.

Alle compilers zullen dit soort fouten detecteren. IDE's zijn er voor om dit soort fouten in een vroeg stadium om zeep te helpen.

Dat kan met meer commandos voor end.

Dat kan, maar dat is een uiterst vermoeiende oplossing voor iets dat veel makkelijker opgelost kan worden.

Ook voor de beginnende gebruiker is dit systeem beter omdat deze gebruikers vergeten een NEXT te typen op een for.

Voor beginnende gebruikers is dit juist een ramp. Ze moeten bij elke 'opening' een andere 'sluiting' leren. Hopeloos vermoeiend. Veel lastiger dan de regel "alles wat je 'opent met (' moet je sluiten met ')'". Zeker als je een IDE gebruikt die aan highlighting doet...

Ik had vandaag er een te pakken:

8 foutmeldingen omdat ik een begin was vergeten te typen.

Hij gaf niet aan dat er 1 BEGIN commando missend was in de routine.

5 extra commandos erbij leren op rond de 200 kan echt geen hersenbreker zijn.

Bij een foutje geeft de compiler dan juist precies aan wat er missend is of juist te veel.

Basic was vroeger gemakkelijk te leren omdat die taal juist for next had en while wend en repeat until.

trouwens als alles op end eindigt dan hadden we ook repeat ....end moeten hebben.

En dan kon je met if voorwaarde then begin break;end; weer de lus kunnen verlaten...

Maar dat is onhandig en daarom hebben we until voorwarde; als einde markering.

Voor beginnende gebruikers is het toch eerst noodzakelijk om goed met if en then begin endl enzo te leren nesten.

En dan de else toepassen.

Ik gebruik nooit else maar alleen end else begin.

Een programmeertaal is er om problemen op te lossen, niet om mooi weer te spelen.

Ik heb vandaag mijn nieuwe compiler aan de timer aangesloten zodat elke file indien gewenst per seconde gecompileerd kan worden.

lekker traag maar als het te lang duurt heb ik een schakelaartje gemaakt dat de zaak dan weer vooruit helpt.

Ik heb hiervoor ndoig gehad:

een var in tprocedure type.

4 tal variabelen

een timer aansluiting

en wat if testen om de verschillende methoden te verwerken.

en een repat until lus omdat de zaak ook 10 files per keer zou kunnen afwerken.

je kunt met weinig commando veel bereiken....

Over beginselen van programmeren gesproken: CPS anyone? Probeer dat maar een in Java.

Probeer dat maar een in Java.

Waarom zou ik?

Ik snap niet eens wat van cps de bedoeling is?

snelheid, mooi ogende code?

We hebben het wel over voor en nadelen hier, maar het grappige is dat de meeste programmeurs features die niet voorkomen in hun fav. programmeertaal niet eens opmerken. Door dat men "denkt" in C of Java, komt het niet eens in hun op dat er programmeer technieken zijn voorbij aan C of Java...

Pas later, heel geleidelijk, sijpelen deze dingen door in andere talen.

C had bijvoorbeeld geen garbage collection, Lisp vanaf het begin wel. Pas in de jaren negentig sijpelde dit door in kreeg Java het. Objective C heeft het nog maar net ontvangen. Merk echter op dat dit radicaal de semantiek van je taal veranderd en de manier waarop je er mee omgaat.

Soms heeft het gewoon tijd nodig.

Als je de toekomst van programmeer talen wilt weten kun je het beste kijken naar lisp-achtige talen. Met de tijd komen al die features (meestal minder krachtig gemaakt om de programmeur "te beschermen") in C-achtige talen terecht.

Als je de toekomst van programmeer talen wilt weten kun je het beste kijken naar lisp-achtige talen.

Wat een onzin. Als je de toekomst van programmeertalen wilt weten dan moet je alle programmeertalen in het oog houden, alsmede de techniek waarvoor deze programmeertalen er zijn. Hetgeen als 'goed' wordt ervaren in de ene taal komt vanzelf terug in andere (nieuwere) talen. Natuurlijk zijn de meningen over wat 'goed' is verdeeld (vandaar dat er niet maar 1 programmeertaal is). Jij bent overduidelijk van mening dat Lisp het summum is. Dit verstoord echter je realiteitszin nogal.

Een voorbeeld hiervan is je standpunt wat betrefd garbage collection. Je vindt het aan de ene kant een enorm probleem als de programmeur 'beschermd' wordt, maar vervolgens ben je wel lyrisch over garbage collection (waarbij de programmeur 'beschermd' wordt tegen bepaalde zaken die mis kunnen gaan met geheugen allocatie). Niet echt consequent...

Je hebt overigens nog steeds niet uit de doeken gedaan waarom je CPS in java zou willen...

GC is geen bescherming, het automatiseren. Als je denkt dat ik dat bedoel met "beschermen" dan heb je mij niet begrepen. Wat ik bedoeld is misplaatst beschermen: de programmeur als kind behandelen, dingen die normaal mogelijk zijn met opzet onmogelijk te maken omdat men denkt dat de programmeur er niet mee kan omgaan. Helaas betekend dit dat de programmeurs die er wel mee weten om te gaan nodeloos worden beperkt terwijl de programmeurs die er daadwerkelijk niet mee om kunnen gaan nooit de kans krijgen om het te leren.

Een van de ontwerpers van Java merkte overigens eens het volgende op:

"And you're right: we were not out to win over the Lisp programmers;

we were after the C++ programmers. We managed to drag a lot of them

about halfway to Lisp." -- Guy Steele

(CPS was maar een voorbeeld. Als je wilt weten wanneer je CPS gebruikt is moet je Scheme leren. Het is onmogelijk om iets (op een forum) uit te leggen als mensen de concepten niet begrijpen, begrippen zoals continuations en call/cc bijvoorbeeld. Om het te begrijpen moet je er mee gewerkt hebben.)

wat is nu juist het voordeel van lisp? Ik vindt het namelijk nogal omslachtig om mee te werken. (ik ben dan ook na de basis van deze taal gestopt)