Najlepsza odpowiedź
Długa historia.
TL; Wersja DR jest z mojego punktu widzenia następująca:
- Można czytać oryginalne książki Smalltalk i czerpać z nich korzyści podczas korzystania z Pharo, więc z pewnością istnieje solidne dziedzictwo Smalltalk.
- Na froncie narzędzi istnieje jest kilka postępów w Pharo, które sprawiają, że jest całkiem wyjątkowy i różni się od Smalltalk 80. Na przykład:
- GToolkit z super potężnymi inspektorami
- Spotter, umożliwiający naprawdę interesujący sposób dostępu do elementów system itp.
- Spec and Bloc dla innych sposobów wykonywania interfejsu użytkownika niż MVC i Morphic
- Porządki i dodatki do standardowych pakietów Squeak
- Zinc, NeoJson, STON,… wszystkie pochodzą ze społeczności Pharo
- Roassal2, do wizualizacji, również pochodzących ze społeczności Pharo.
- Maszyna wirtualna, która jest teraz powszechną OpenSmalltalk / opensmalltalk-vm starania z określonymi obszarami Pharo są szybsze, w i z lepszym JIT i innym zestawem kodów bajtowych. Zarządzanie pamięcią z przekazywaniem wskaźnika sprawia, że staje się: znacznie szybsze. Sprawdź Tuning the Pharo garbage collector , sprawdź 7-punktowe podsumowanie menedżera pamięci Spur , cóż, sprawdź wszystko na tym blogu, to po prostu rządzi.
- Mamy cechy. Mamy XStreams. Mamy Calypso. Mamy Iceberg. Mamy sprawę krytyków. Mamy kompilator Opal. Mamy Rubrika do edycji tekstu. Mamy model Ring jako kod. Możemy sprawdzić AST pod kątem metod. Mamy Beacon dla struktury rejestrowania obiektów. Mamy działające WeakReferences. Mamy UnifiedFFI. Mamy 64 bity. Mamy paliwo. Mamy Seaside3. Mamy fajne CommandLineHandlers. Mamy Scale do pracy z CLI. Mamy Epiceę do zmian w kodzie. Mamy przeprojektowany interfejs API FileSystem. Mamy HelpSystem. Mamy działającą infrastrukturę z CI i Gitem oraz śledzeniem problemów itp., Które dobrze ze sobą współpracują. Mamy filar do produkcji książek. Mamy TaskIT do łatwej pracy z futures. Mamy przyzwoity system KeyMapping. Mamy uporządkowany Morphic (jeszcze więcej do zrobienia). Mamy OSWindow. Mamy Refaktoryzacje i CodeRewriter. Mamy MetaLinks z Reflectivity. Mamy Ateny do grafiki. Mamy wsparcie dla IoT.
Tak, jest to inspirowane Smalltalk. Ale na pewno nie Smalltalk-80. To jest Pharo. Używamy latarni morskiej jako naszego logo. Ponieważ lubimy, gdy jest jasne światło torujące drogę do rozkoszy programisty.
Smalltalk jest świetny.
Pharo jest lepszy, jeśli chodzi o uzyskiwanie wyników biznesowych przy użyciu technologii XXI wieku . Ponieważ połączenie narzędzi Pharo ze sobą prowadzi do potężnych rezultatów.
I tak, jestem uparty.
Odpowiedź
Pharo to dialekt Smalltalk. Pod względem składni, semantyki i implementacji Pharo jest wersją Smalltalk-80 i bardzo bliskim krewnym dialektów Squeak i aware. Wszystkie trzy pochodzą bezpośrednio z Smalltalk-80 v1, który Apple dostał od Xerox w ramach procesu pisania „Smalltalk-80: język i jego implementacja”, czyli „niebieskiej księgi”. Alan Kay kierował zespołem w Apple w latach 90-tych, który opracował dialekt Squeak i jego implementację, począwszy od Smalltalk-80 v1. Później okrzyk i Pharo rozwidlili się ze Squeaka. Ale wszyscy trzej przeszli na moją maszynę wirtualną Spur, ewolucję maszyny wirtualnej JIT, którą w roku 2008/9/10 zaczerpnąłem z oryginalnej maszyny wirtualnej interpretera Back to the-future dla Squeak.
Te trzy dialekty Najbliższym krewnym od siebie jest VisualWorks Smalltalk, który wywodzi się bezpośrednio z Smalltalk-80 v2, ostatecznej wersji opracowanej w Xerox PARC. Wszystkie cztery można odróżnić od innych Smalltalków dzięki obsłudze kontekstów (rekordów aktywacji pierwszej klasy Smalltalk) za pośrednictwem pseudozmiennej thisContext. Kontekst to zapis aktywacji; jest to obiekt, który utrzymuje stan uruchomionej metody lub zamknięcia bloku. Różnica powierzchniowa polega na tym, że rodzina Squeak obsługuje krotki (wygodna konstrukcja Array) i instrukcję case, podczas gdy VisualWorks ma system przestrzeni nazw i formę literału BindingReference do uzyskiwania dostępu do obiektów poza granicami przestrzeni nazw.
Jedna wyjątkowa rzecz dotycząca Smalltalk i jego bliscy krewni Ja i Nowomowa są takie, że systemy same się definiują; klasy, metody i konteksty, wszystkie są obiektami pierwszej klasy zdefiniowanymi w kategoriach klas i metod. Obejmuje to ich kompilator i debugger, system wyjątków itp., Co pozwala Smalltalk ewoluować na poziomie języka. Krotki, instrukcja przypadku i przestrzenie nazw zostały zaimplementowane w odpowiednich systemach bez konieczności modyfikowania jakiejkolwiek podstawowej maszyny wirtualnej. Ta zdolność do ewolucji sprawia, że zdefiniowanie dokładnie tego, co Smalltalk jest nieco problematyczne. Zdrowy Smalltalk to ewoluujący Smalltalk; ruchomy cel.
Niektórzy, być może wielu, w społeczności Pharo myśli, że Smalltalk zyskał złą sławę w latach 90., a niektórzy są niezadowoleni z braku wsparcia dla programistów i skupienia się na Etoys, które miał zespół badawczy Alana Kaya, co zrozumiałe tak jak w rzeczywistości Etoys był celem zespołu. W związku z tym Pharo kładzie inny nacisk i chce przejść od starzejącej się obsługi multimediów Squeaka w kierunku lepszej integracji z obecnym ekosystemem obliczeniowym, takim jak github, oraz w kierunku ponownego wynalezienia programowania jako znacznie bardziej dynamicznego procesu eksploracyjnego; zobacz na przykład zwinną wizualizację powyżej Rossala i zestawu narzędzi GT. Dlatego niektórzy w społeczności Pharo chcą zaprzeczyć, że Pharo jest dialektem Smalltalk. Jest to stanowisko, które rozumiem, ale uważam zarówno za fałszywe w rzeczywistości (niezaprzeczalnie, w jego składni, semantyce i implementacji Pharo / is / a wersja Smalltalk-80), jak i nieco lekceważące i niewdzięczne (Pharo to świetne środowisko programistyczne, zarówno dlatego, że ma wspaniali ludzie wykonują w tym świetną robotę i potrafią to robić, ponieważ jest to Smalltalk). Ale nieważne. Pharo opiera się na swoich zaletach, potężnym, szybko rozwijającym się dialekcie Smalltalk, oferującym programistom radykalne korzyści w zakresie produktywności. Mam nadzieję, że przyjrzysz się temu więcej niż pobieżnie. To się dzieje.