Hva er bedre, Smalltalk eller Pharo?

Beste svaret

Lang historie.

TL; DR-versjonen er følgende fra mitt synspunkt:

  • Man kan lese de originale Smalltalk-bøkene og få verdi ut av dem når man bruker Pharo, så det er definitivt en solid Smalltalk-arv.
  • På verktøyfronten, der er flere fremskritt innen Pharo som gjør det ganske unikt og forskjellig fra Smalltalk 80. For eksempel:
  • GToolkit, med superkraftige inspektører
  • Spotter, som gir en veldig interessant måte å få tilgang til gjenstander av systemet etc
  • Spec og Bloc for andre måter å gjøre brukergrensesnitt på enn MVC og morfisk
  • Opprydding og tillegg til standardpakker med Squeak
  • Zink, NeoJson, STON,… alle stammer fra Pharo-samfunnet
  • Roassal2, for visualiseringer, også fra Pharo-fellesskapet
  • VM, som nå er en vanlig OpenSmalltalk / opensmalltalk-vm arbeidet med spesifikke Pharo-områder er raskere, w med en bedre JIT, og et annet bytekodesett. Minnehåndtering med pekeren videresending gjør: mye raskere. Sjekk Tuning av Pharo søppeloppsamleren , sjekk 7-punkts sammendrag av Spur Memory Manager , vel, sjekk alt på den bloggen, den klipper bare.
  • Vi har trekk. Vi har XStreams. Vi har Calypso. Vi har isberg. Vi har kritikertingen. Vi har Opal-kompilatoren. Vi har Rubrik for tekstredigering. Vi har Ring som kodemodell. Vi kan inspisere AST for metoder. Vi har Beacon for et objektloggingsrammeverk. Vi har fungerende svake referanser. Vi har UnifiedFFI. Vi har 64 biter. Vi har drivstoff. Vi har Seaside3. Vi har kule CommandLineHandlers. Vi har skala for CLI-arbeid. Vi har Epicea for kodeendringer. Vi har et redesignet FileSystem API. Vi har HelpSystem. Vi har en fungerende infrastruktur med CI og Git, og hvilken problemsporing osv. Som fungerer fint sammen. Vi har Pillar for å produsere bøker. Vi har TaskIT for litt enkelt arbeid med futures. Vi har et anstendig KeyMapping-system. Vi har ryddet opp morfisk (enda mer å gjøre). Vi har OSWindow. Vi har Refactorings og CodeRewriter. Vi har Metalinks med reflektivitet. Vi har Athen for grafikk. Vi har IoT-støtte.

Så, ja, den er inspirert av Smalltalk. Men definitivt ikke Smalltalk-80. Det er Pharo. Vi bruker et fyr som logo. Fordi vi liker det når det er noe sterkt lys som baner vei for utviklerens lykke.

Smalltalk er flott.

Pharo er bedre når det gjelder å få forretningsresultater når du bruker teknologi fra det 21. århundre . Fordi det å kombinere Pharo-verktøy med hverandre fører til kraftige resultater.

Og ja, jeg er meningsfull.

Svar

Pharo er en dialekt av Smalltalk. I sin syntaks, semantikk og implementering er Pharo en versjon av Smalltalk-80, og en veldig nær slektning av dialektene Squeak og Cuis. Alle tre stammer direkte fra Smalltalk-80 v1 som Apple fikk av Xerox som en del av prosessen med å skrive «Smalltalk-80: språket og implementeringen», også kalt «den blå boken». Alan Kay ledet et team hos Apple på 90-tallet som utviklet Squeak-dialekten og implementeringen, og startet med Smalltalk-80 v1. Senere Cuis og Pharo gaffel fra Squeak. Men alle tre har gått over til min Spur VM, en utvikling av JIT VM som jeg i 2008/9/10 hentet fra den opprinnelige Back-to-the-future tolk VM for Squeak.

Disse tre dialektene nærmeste slektning bortsett fra hverandre er VisualWorks Smalltalk, som kommer direkte ned fra Smalltalk-80 v2, den endelige versjonen utviklet på Xerox PARC. Alle fire skiller seg fra andre Smalltalks ved å støtte sammenhenger (Smalltalks førsteklasses aktiveringsposter) via denne pseudovariabelen for denne konteksten. En kontekst er en aktiveringspost; det er objektet som holder tilstanden til en løpemetode eller blokkering. En overflateforskjell er at Squeak-familien støtter tupler (en praktisk Array-konstruksjon) og en saksuttalelse, mens VisualWorks har et navneromssystem og en BindingReference-bokstavelig form for tilgang til objekter på tvers av navnegrenser.

En unik ting om Smalltalk og dets nære slektninger Self and Newspeak er at systemene definerer seg selv; klasser, metoder og sammenhenger som alle er førsteklasses objekter definert i form av klasser og metoder. Dette strekker seg til kompilatoren og feilsøkingsprogrammet, unntakssystemet osv. Dette gjør at Smalltalk kan utvikle seg på språknivå. Tuples, case statement og namespaces ble alle implementert i sine respektive systemer uten å måtte endre noen underliggende virtuell maskin. Denne evnen til å utvikle gjør å definere nøyaktig hva Smalltalk er noe problematisk. En sunn Smalltalk er en Smalltalk i utvikling; et bevegelig mål.

Noen, kanskje mange, i Pharo-samfunnet mener Smalltalk fikk et dårlig navn på 90-tallet, og noen er misfornøyde med mangelen på støtte til utviklere og fokuserer på Etoys som Alan Kays forskerteam hadde, forståelig nok. som faktisk Etoys var lagets fokus. Derfor har Pharo en veldig annen vekt og ønsker å gå videre fra Squeaks nå aldrende multimedia-støtte mot bedre integrering med det nåværende databehandlingsøkosystemet, for eksempel github, og mot å gjenoppfinne programmering som en mye mer dynamisk utforskende prosess; se for eksempel det smidige visualiseringsarbeidet ovenfor Rossal og GT-verktøykassen. Derfor vil noen i Pharo-samfunnet benekte at Pharo er en dialekt av Smalltalk. Dette er en stilling jeg forstår, men finner både falsk i virkeligheten (unektelig i sin syntaks, semantikk og implementering Pharo / er / en versjon av Smalltalk-80) og noe respektløs og utakknemlig (Pharo er et flott programmeringsmiljø, både fordi det har flotte mennesker gjør stort arbeid i det og er i stand til det fordi det er en Smalltalk). Men samme det. Pharo står på sine fordeler, en kraftig, raskt utviklende dialekt av Smalltalk som gir radikale produktivitetsfordeler for programmerere. Jeg håper du tar mer enn et kort blikk på det. Det går steder.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *