Bästa svaret
Lång historia.
TL; DR-versionen är följande ur min synvinkel:
- Man kan läsa de ursprungliga Smalltalk-böckerna och få värde av dem när man använder Pharo, så det finns definitivt ett gediget Smalltalk-arv.
- På verktygsfronten finns det finns flera framsteg inom Pharo som gör det ganska unikt och skiljer sig från Smalltalk 80. Till exempel:
- GToolkit, med superkraftiga inspektörer
- Spotter, vilket möjliggör ett riktigt intressant sätt att komma åt föremål av systemet etc
- Spec och Bloc för andra sätt att göra UI än MVC och Morphic
- Rensningar och tillägg till standardpaketen för Squeak
- Zink, NeoJson, STON, … alla härstammar från Pharosamhället
- Roassal2, för visualiseringar, även härrörande från Pharosamhället
- Den virtuella datorn, som nu är en vanlig OpenSmalltalk / opensmalltalk-vm strävan med specifika Pharo-områden är snabbare, w med en bättre JIT och en annan bytecode-uppsättning. Minneshantering med vidarebefordran av pekare blir: mycket snabbare. Kontrollera Ställa in Pharo-sopuppsamlaren , kolla 7-punkts sammanfattning av Spur-minneshanteraren , Tja, kolla allt på den bloggen, det stenar bara.
- Vi har egenskaper. Vi har XStreams. Vi har Calypso. Vi har isberg. Vi har Critics-saken. Vi har Opal-kompilatorn. Vi har Rubrik för textredigering. Vi har Ring som kodmodell. Vi kan inspektera AST för metoder. Vi har Beacon för ett ramverk för objektloggning. Vi har fungerande svaga referenser. Vi har UnifiedFFI. Vi har 64 bitar. Vi har bränsle. Vi har Seaside3. Vi har coola CommandLineHandlers. Vi har skala för CLI-arbete. Vi har Epicea för kodändringar. Vi har ett omdesignat FileSystem API. Vi har HelpSystem. Vi har en fungerande infrastruktur med CI och Git och vilken problemspårning etc som fungerar bra tillsammans. Vi har pelare för att producera böcker. Vi har TaskIT för enkelt arbete med futures. Vi har ett anständigt KeyMapping-system. Vi har rensat upp Morphic (ännu mer att göra). Vi har OSWindow. Vi har Refactorings och CodeRewriter. Vi har MetaLinks med Reflectivity. Vi har Aten för grafik. Vi har IoT-stöd.
Så ja, det är Smalltalk-inspirerat. Men definitivt inte Smalltalk-80. Det är Pharo. Vi använder en fyr som vår logotyp. Eftersom vi gillar det när det finns starkt ljus som banar väg för utvecklarens salighet.
Smalltalk är jättebra.
Pharo är bättre när det gäller att få affärsresultat när man använder teknik från 2000-talet . För att kombinera Pharo-verktyg med varandra leder till kraftfulla resultat.
Och ja, jag är uppfattad.
Svar
Pharo är en dialekt av Smalltalk. I sin syntax, semantik och implementering är Pharo en version av Smalltalk-80, och en mycket nära släkting till dialekterna Squeak och Cuis. Alla tre härstammar direkt från Smalltalk-80 v1 som Apple fick av Xerox som en del av processen att skriva ”Smalltalk-80: språket och dess implementering”, aka “den blå boken”. Alan Kay ledde ett team på Apple på 90-talet som utvecklade Squeak-dialekten och implementeringen från och med Smalltalk-80 v1. Senare gick Cuis och Pharo från Squeak. Men alla tre har övergått till min Spur VM, en utveckling av JIT VM som jag 2008/9/10 härleder från den ursprungliga Back-to-the-future-tolk VM för Squeak.
Dessa tre dialekter Närmaste släkting bortsett från varandra är VisualWorks Smalltalk, som kommer direkt från Smalltalk-80 v2, den slutliga versionen som utvecklats på Xerox PARC. Alla fyra kan särskiljas från andra Smalltalks genom att stödja sammanhang (Smalltalks första klass aktiveringsposter) via denna pseudovariabel för dennaContext. Ett sammanhang är en aktiveringspost; det är objektet som håller tillståndet för en körmetod eller blockeringsstängning. En ytskillnad är att Squeak-familjen stöder tuplar (en praktisk Array-konstruktion) och ett falluttalande, medan VisualWorks har ett namnrymmesystem och en BindingReference-bokstavlig form för åtkomst till objekt över gränserna för namnområdet.
En unik sak Smalltalk och dess nära släktingar Själv och Newspeak är att systemen är självdefinierande; klasser, metoder och sammanhang som alla är förstklassiga objekt definierade i termer av klasser och metoder. Detta sträcker sig till deras kompilator och felsökare, undantagssystemet etc. detta gör det möjligt för Smalltalk att utvecklas på språknivå. Tuples, case statement och namespaces implementerades alla i sina respektive system utan att behöva modifiera någon underliggande virtuell maskin. Denna förmåga att utvecklas gör att man definierar exakt vad Smalltalk är något problematiskt. En hälsosam Smalltalk är en Smalltalk som utvecklas; ett rörligt mål.
Vissa, kanske många, i Pharo-samhället tycker att Smalltalk fick ett dåligt namn på 90-talet, och vissa är missnöjda med bristen på stöd för utvecklare och fokuserar på Etoys som Alan Kays forskargrupp hade, förståeligt. eftersom Etoys verkligen var lagets fokus. Följaktligen har Pharo en helt annan betoning och vill gå bort från Squeaks nu åldrande multimediastöd mot bättre integration med det nuvarande datorekosystemet, såsom github, och mot att återuppfinna programmering som en mycket mer dynamiskt utforskande process se till exempel det agila visualiseringsarbetet ovanför Rossal och GT-verktygssatsen. Därför vill vissa i Pharosamhället förneka att Pharo är en dialekt av Smalltalk. Detta är en position som jag förstår men finner både falskt i verkligheten (utan tvekan i sin syntax, semantik och implementering Pharo / är / en version av Smalltalk-80) och något respektlöst och otacksam (Pharo är en fantastisk programmeringsmiljö, både för att den har stora människor som gör bra arbete i det och kan eftersom det är en Smalltalk). Men bry dig inte. Pharo står på sina meriter, en kraftfull, snabbt utvecklad dialekt av Smalltalk som erbjuder radikala produktivitetsfördelar för programmerare. Jag hoppas att du tar mer än en kort titt på det. Det går platser.