Hvad er bedre, Smalltalk eller Pharo?

Bedste svar

Lang historie.

TL; DR-version er følgende fra mit synspunkt:

  • Man kan læse de originale Smalltalk-bøger og få værdi ud af dem, når man bruger Pharo, så der er bestemt en solid Smalltalk-arv.
  • På værktøjsfronten er der er flere fremskridt inden for Pharo, der gør det temmelig unikt og forskelligt fra Smalltalk 80. For eksempel:
  • GToolkit, med superkraftige inspektører
  • Spotter, der giver en virkelig interessant måde at få adgang til systemet osv.
  • Spec og Bloc for andre måder at gøre UI end MVC og Morphic
  • Oprydninger og tilføjelser til standardpakkerne af Squeak
  • Zink, NeoJson, STON, … alle stammer fra Pharo-samfundet
  • Roassal2, til visualiseringer, der også stammer fra Pharo-samfundet
  • VM, som nu er en fælles OpenSmalltalk / opensmalltalk-vm bestræbelser med specifikke Pharo-områder er hurtigere, w med en bedre JIT og et andet bytecode-sæt. Hukommelsesstyring med videresendelse af markører bliver: meget hurtigere. Kontroller Tuning af Pharo-affaldssamleren , tjek 7-punkts resumé af Spur-hukommelsesadministrator , godt, tjek alt på den blog, det klipper bare.
  • Vi har træk. Vi har XStreams. Vi har Calypso. Vi har isbjerget. Vi har kritikeren. Vi har Opal-kompilatoren. Vi har Rubrik til tekstredigering. Vi har Ring som kodemodel. Vi kan inspicere AST for metoder. Vi har Beacon til en ramme om objektlogning. Vi har fungerende svage referencer. Vi har UnifiedFFI. Vi har 64 bits. Vi har brændstof. Vi har Seaside3. Vi har seje CommandLineHandlers. Vi har skala for CLI-arbejde. Vi har Epicea til kodeændringer. Vi har et redesignet FileSystem API. Vi har HelpSystem. Vi har en fungerende infrastruktur med CI og Git, og hvilken problemsporing osv., Der fungerer godt sammen. Vi har søjle til produktion af bøger. Vi har TaskIT til let arbejde med futures. Vi har et anstændigt KeyMapping-system. Vi har ryddet op Morphic (endnu mere at gøre). Vi har OSWindow. Vi har refactorings og CodeRewriter. Vi har MetaLinks med refleksion. Vi har Athen til grafik. Vi har IoT-support.

Så ja, det er inspireret af Smalltalk. Men bestemt ikke Smalltalk-80. Det er Pharo. Vi bruger et fyrtårn som vores logo. Fordi vi kan lide det, når der er noget stærkt lys, der baner vejen for udviklerens lykke.

Smalltalk er fantastisk.

Pharo er bedre, når det kommer til at få forretningsresultater, når du bruger teknologi fra det 21. århundrede . Fordi kombinationen af ​​Pharo-værktøjer med hinanden fører til stærke resultater.

Og ja, jeg er meningsfuld.

Svar

Pharo er en dialekt af Smalltalk. I sin syntaks, semantik og implementering er Pharo en version af Smalltalk-80 og en meget nær slægtning til dialekterne Squeak og Cuis. Alle tre stammer direkte fra Smalltalk-80 v1, som Apple fik af Xerox som en del af processen med at skrive “Smalltalk-80: sproget og dets implementering”, aka “den blå bog”. Alan Kay ledede et team hos Apple i 90erne, der udviklede Squeak dialekt og implementering startende med Smalltalk-80 v1. Senere Cuis og Pharo forked fra Squeak. Men alle tre er overgået til min Spur VM, en udvikling af JIT VM, som jeg i 2008/9/10 stammer fra den oprindelige Back-to-the-future-tolk VM til Squeak.

Disse tre dialekter nærmeste slægtning bortset fra hinanden er VisualWorks Smalltalk, der nedstammer direkte fra Smalltalk-80 v2, den endelige version udviklet på Xerox PARC. Alle fire skelnes fra andre Smalltalks ved at understøtte sammenhænge (Smalltalks første klasses aktiveringsregistreringer) via denne pseudovariabel med denneContext. En kontekst er en aktiveringspost; det er objektet, der holder tilstanden af ​​en kørselsmetode eller blokering. En overfladeforskel er, at Squeak-familien understøtter tupler (en praktisk Array-konstruktion) og en sagserklæring, hvorimod VisualWorks har et namespace-system og en BindingReference-bogstavelig form til adgang til objekter på tværs af namespace-grænser. Smalltalk og dens nære slægtninge Self og Newspeak er, at systemerne er selvdefinerende; klasser, metoder og sammenhænge, ​​der alle er førsteklasses objekter defineret i form af klasser og metoder. Dette strækker sig til deres kompilator og debugger, undtagelsessystemet osv. Dette gør det muligt for Smalltalk at udvikle sig på sprogniveau. Tuples, sagserklæringen og navneområdet blev alle implementeret i deres respektive systemer uden at skulle ændre nogen underliggende virtuel maskine. Denne evne til at udvikle gør det nøjagtigt at definere, hvad Smalltalk er noget problematisk. En sund Smalltalk er en Smalltalk i udvikling; et bevægeligt mål.

Nogle, måske mange, i Pharo-samfundet mener, at Smalltalk fik et dårligt navn i 90erne, og nogle er utilfredse med den manglende støtte til udviklere og fokuserer på Etoys, som Alan Kays forskerteam havde, forståeligt nok. som faktisk Etoys var holdets fokus. Derfor har Pharo en meget anden vægt og ønsker at komme væk fra Squeaks nu aldrende multimediestøtte til bedre integration med det nuværende computerøkosystem, såsom github, og i retning af at genopfinde programmering som en meget mere dynamisk udforskende proces; se for eksempel det agile visualiseringsarbejde over Rossal og GT-værktøjssættet. Derfor vil nogle i Pharo-samfundet benægte, at Pharo er en dialekt af Smalltalk. Dette er en position, som jeg forstår, men finder både falsk i virkeligheden (utvivlsomt i sin syntaks, semantik og implementering Pharo / er / en version af Smalltalk-80) og noget respektløs og utaknemmelig (Pharo er et godt programmeringsmiljø, både fordi det har store mennesker gør stort arbejde i det og er i stand til, fordi det er en Smalltalk). Men tag dig ikke af det. Pharo står på sine fordele, en kraftfuld, hurtigt udviklende dialekt af Smalltalk, der giver programmører radikale produktivitetsfordele. Jeg håber, du tager mere end et kort blik på det. Det går steder.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *