На мой взгляд смолток — это один из самых интересных языков программирования. По скорости исполнения — ну, не самый быстрый, зато вполне успешно во второй половине 90-х тянул старенькие пеньки, где было всего мегабайт 16 или в лучшем случае 32 мегабайта памяти. В то же время, концептуально язык очень прост, а при этом остается настолько выразительным, что позоволило ему сохранить стандартную библиотеку коллекций почти в неизменном виде с 70-х или 80-х годов. И что поразительно, библиотека коллекций смолтока вполне остается на уровне такого языка как скала, если рассматривать мутабельную часть последней. А потоки смолтока — это предвестники современных итераторов, плюс работа с файлами в одном флаконе.
Ближе к делу. Рассмотрим современную опенсорсную реализацию Pharo. Недавно вышла версия Pharo 12.
На виндузе Pharo 11 у меня вполне нормально запустился без каких-либо шероховатостей. Пожалуй, виндовая версия Pharo визуально самая безупречная.
На старом макбуке Pharo 11 тоже встало достаточно уверенно. Единственное, что заметил небольшое мерцание экрана, но вполне терпимо. Еле заметно.
На линуксе могут вас ожидать сюрпризы. Опишу свой опыт установки на АльтЛинукс.
Во-первых, на альте библиотека libc расположена в каталоге /lib64. Соответственно, и в PharoLauncher, и в башевских скриптах виртуальных машин Pharo нужно явно прописать, где находится libc. Эти скрипты находятся в файлах pharo-vm/pharo и pharo-vm/bin/pharo. Такие виртуальные машины находятся там, где вы распакуете pharolauncher, а также в каталоге ~/Pharo/vms.
Тут есть такое странное обстоятельство, что если хотя бы одна из переменных окружения содержит русский текст или, как говорят, вообще содержит юникод, то Pharo толком не запустится.
Поэтому через команду export в консоли смотрим, где есть русские буквы.
У меня это следующая строчка:
$ export
...
declare -x GPG_TTY="не телетайп"
...
Соответственно, иду в запускающий скрипт pharolauncher/pharo-launcher и переопределяю проблемную переменную окружения:
# Otherwise, it would not work (remove all Unicode environment variables)
export GPG_TTY="not teletype"
После этих простых манипуляций у вас на АльтЛинуксе должен запустится Pharo — одна из самых продвинутых опенсорсных реализаций смолтока.
Ну, и на последок. Предлагаю обсудить, где может применяться смолток, или где он уже применяется? Мне кажется, что это один из редких языков типа хаскеля и лиспа, который нас всех переживет и надолго. Такие языки всегда будут оставаться актуальными, чтобы там ни случалось в этом нашем войти-в-айти
Здравствуйте, dsorokin, Вы писали:
D>Ну, и на последок. Предлагаю обсудить, где может применяться смолток, или где он уже применяется? Мне кажется, что это один из редких языков типа хаскеля и лиспа, который нас всех переживет и надолго. Такие языки всегда будут оставаться актуальными, чтобы там ни случалось в этом нашем войти-в-айти
Тут как с объектно ориентированными базами данных. Они есть, кто-то даже ими пользуется, но ни кто не видел тех кто ими пользуется.
Здравствуйте, dsorokin, Вы писали:
D>Ну, и на последок. Предлагаю обсудить, где может применяться смолток, или где он уже применяется? Мне кажется, что это один из редких языков типа хаскеля и лиспа, который нас всех переживет и надолго. Такие языки всегда будут оставаться актуальными, чтобы там ни случалось в этом нашем войти-в-айти
Да, смоллтолк крутейший язык. На мой взгляд, это такой упрощенный, объектно-ориентированный лисп. Он позволяет быстро создавать DSL и писать на нем.
Но этот язык "был", сейчас его время ушло. Для промышленной разработки у него есть неустранимые недостатки:
1. Библиотеки. В языке отсутствует модульность и неймспейсы, все классы живут в одной среде. Как интегрироваться с имеющимися библиотеками на си? Как создавать и распространять библиотеки и фреймворки?
2. Инструменты разработки. С языком идет среда разработки, но она сильно интегрированная с самим языком. Да, это сильно меняет способ разработки, упрощает и делает ее более интерактивной. Но как расширять эту среду, как делать линтеры, анализаторы, профилировщики и т.п.?
Кому нужно крутить DSL, использует лисп, который более развитый. Кто помешан на типах (в хорошем смысле), используют хаскелл.
В мейнстриме же многие преимущества смоллтолка (гибкость и интерактивность) покрыты современными динамическими языками — питоном и js.
Здравствуйте, Qulac, Вы писали:
Q>Тут как с объектно ориентированными базами данных. Они есть, кто-то даже ими пользуется, но ни кто не видел тех кто ими пользуется.
А как ты узнаешь?) На лбу не написано
Кстати, в моем начальном сообщении первый пункт можно сократить до следующего:
сделать символическую ссылку /usr/bin/fgrep на /bin/fgrep
Только тут придется лезть в саму систему, а там я предлагал менять скрипты виртуальной машины смолтока.
А вот переопределить переменную окружения с юникодом, скорее всего, придется. На это же жаловался один немец, так что, проблема не касается только русского языка
Здравствуйте, Буравчик, Вы писали:
Б>Да, смоллтолк крутейший язык. На мой взгляд, это такой упрощенный, объектно-ориентированный лисп. Он позволяет быстро создавать DSL и писать на нем.
Б>Но этот язык "был", сейчас его время ушло. Для промышленной разработки у него есть неустранимые недостатки: Б>1. Библиотеки. В языке отсутствует модульность и неймспейсы, все классы живут в одной среде. Как интегрироваться с имеющимися библиотеками на си? Как создавать и распространять библиотеки и фреймворки? Б>2. Инструменты разработки. С языком идет среда разработки, но она сильно интегрированная с самим языком. Да, это сильно меняет способ разработки, упрощает и делает ее более интерактивной. Но как расширять эту среду, как делать линтеры, анализаторы, профилировщики и т.п.?
Немного поигрался с Pharo. Там есть интеграция с Git. Можно распространять код через гитовые репозитории. Есть в интернете свой репозиторий, заточенный под смолток. Распространение библиотек — по-моему решаемая вещь.
Неймспейсы есть в VisualWorks, к которому нас не пущают (не открывают сайт). Когда-то лет 13-15 назад я с ним игрался. Мне VisualWorks понравился, правда тогда неймспейсов, возможно, что не было, или я не обратил внимания.
Судя по книжке по установке Seaside, нейсмспейсы в VisualWorks могут быть похожи на пакеты Common Lisp с той же идеологией импорта-экспорта символов, но я видел только издалека по короткому упоминанию.
И еще я заметил, что неймспейсы сейчас активно добавляют в Dolphin Smalltalk, который сделали бесплатным опенсорсом. Он только под винду, но GUI там шикарный, и есть возможность создания исполняемых двоичных файлов (как в тех же LispWorks и Allegro CL).
В принципе, даже если бы сделали неймспейсы по подобию пакетов из лиспа, то этого было бы вполне достаточно.
Для интеграции с языком C, я видел в Pharo вещи из FFI. Не вникал, но внешне похоже на привычный FFI.
На счет инструментов разработки не совсем понял, почему это настолько важный недостаток, да и недостаток ли.
В Pharo меня больше всего смутил способ деплоя десктопных приложений. Похоже, что нужно таскать с собой виртуальную машину, а еще нужно самому в полуручном режиме убирать из образа все лишнее. В итоге получится довольно увесистый архив, хотя жаберы/скалисты тоже кладут почти всегда в свои инсталяторы виртуальную машину джавы. Да и размером архива сейчас в 2024-м никого не удивишь, но все же!
Что касается VisualWorks, то он вроде как заточен под деплой десктопных приложений. А еще создавать приложения умеет Dolphin Smalltalk, о чем я написал выше.
Б>Сейчас у смоллтолка нет киллер-фичи. Да, жаль
Я сейчас офигеваю от концептуальной простоты смолтока, помноженной на его выразительность. Может быть, меня зацепит, как когда-то зацепили лисп и хаскель
Здравствуйте, dsorokin, Вы писали:
D>Немного поигрался с Pharo. Там есть интеграция с Git. Можно распространять код через гитовые репозитории. Есть в интернете свой репозиторий, заточенный под смолток. Распространение библиотек — по-моему решаемая вещь. D>Для интеграции с языком C, я видел в Pharo вещи из FFI. Не вникал, но внешне похоже на привычный FFI.
Я со смолтолком игрался очень давно. Сейчас, смотрю, есть и либы на гитхабе, и неймспейсы в VW. Круто.
Т.е. язык перестал быть вещью в себе, ограниченной только образом из коробки.
D>На счет инструментов разработки не совсем понял, почему это настолько важный недостаток, да и недостаток ли.
Потому что инструменты должны развивать не только разработчики языка.
Должна создаваться экосистема, позволяющая развивать среду разработки другими.
В продуктовой/командной разработке инструменты очень важны.
D>В Pharo меня больше всего смутил способ деплоя десктопных приложений. Похоже, что нужно таскать с собой виртуальную машину, а еще нужно самому в полуручном режиме убирать из образа все лишнее. В итоге получится довольно увесистый архив, хотя жаберы/скалисты тоже кладут почти всегда в свои инсталяторы виртуальную машину джавы. Да и размером архива сейчас в 2024-м никого не удивишь, но все же!
Насколько увесистый? Размер сейчас не проблема, да
D>Я сейчас офигеваю от концептуальной простоты смолтока, помноженной на его выразительность. Может быть, меня зацепит, как когда-то зацепили лисп и хаскель
Согласен. Я после смолтолка разобрался с лямбдами и коллекциями. Сейчас это все уже проросло в мейнстрим-языки.
Удивился, что конструкции языка описываются методами (ifTrue ifFalse whileTrue и т.п.), а значит их можно добавлять. Такого еще в мейнстриме нет
И интерактивность разработки, когда ты находишься как бы "внутри" программы, и строишь ее кирпичик за кирпичиком. Из похожего — питонячьи Jupyter notebooks
Здравствуйте, Буравчик, Вы писали:
Б>Насколько увесистый? Размер сейчас не проблема, да
Размеры можно прикинуть по архивам, что распространяют.
Установщик запускающей программы pharo-launcher для винды занимает 55 мегабайт. Он содержит виртуальную машину смолтока. Для линукса такой же архив zip весит больше, потому что там они допустили дубли библиотек. Если бы был tar.gz, то вероятно, дублей бы не было.
Что касается самого образа Pharo12, то он в архиве весит 22 мегабайта.
Итого для Pharo получается: 55+22 ~ 77 мегабайт.
Для сравнения squeak весит много меньше: образ вместе с виртуальной машиной упаковали в 28 мегабайт. Только squeak еще надо научить юникоду. Недоработка. Однако размер squeak примерно показывает, на какой объем можно расчитывать.
А если брать Dolphin Smalltalk, то он может создавать очень маленькие (по современным меркам) двоичные файлы. Скажем, исполняемый файл для Bouncing Balls после сборки весит всего 1 мегабайт и 300 килобайт.
Б>Удивился, что конструкции языка описываются методами (ifTrue ifFalse whileTrue и т.п.), а значит их можно добавлять. Такого еще в мейнстриме нет
В мейнстрим просочились extension methods. А вот красивой и эффективной связки блоков (делегатов/лямбд) с методами тоже не вижу. Что-то в котлине отдаленно напоминающее сделали с лямбдами, которые инлайнятся, но местами котлин очень непрост.
Кстати, нелокальный выход в котлине из инлайнящейся лямбды, возможно, сделали, опираясь на опыт смолтока. После скалы это изрядно выносит мозг в котлине, хотя в том же смолтоке выглядит вполне нормально и естественно, не вызывает изумления в отличие от котлина.
Из необычных вещей в смолтоке меня только удивила последовательность обработки финализаторов (метод ensure). Когда есть обработчик ошибок, то последовательность действий не та, к которой привык в мейнстриме. Отдаленно напоминает лисп, где стек может и не раскручиваться сразу.
Б>И интерактивность разработки, когда ты находишься как бы "внутри" программы, и строишь ее кирпичик за кирпичиком. Из похожего — питонячьи Jupyter notebooks
Похожее в лиспе за некоторым исключением. В лиспе иногда проще перезагрузить код полностью с нуля, чем вживую его поменять, хотя таких случаев очень и очень мало. А в целом, идея образа и инкрементальной восходящей разработки очень и очень близка для лиспа — это его второе имя.
Здравствуйте, Буравчик, Вы писали: Б>Удивился, что конструкции языка описываются методами (ifTrue ifFalse whileTrue и т.п.), а значит их можно добавлять. Такого еще в мейнстриме нет
В Kotlin есть.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Буравчик, Вы писали:
Б>Удивился, что конструкции языка описываются методами (ifTrue ifFalse whileTrue и т.п.), а значит их можно добавлять. Такого еще в мейнстриме нет
Здравствуйте, Sinclair, Вы писали:
Б>>Удивился, что конструкции языка описываются методами (ifTrue ifFalse whileTrue и т.п.), а значит их можно добавлять. Такого еще в мейнстриме нет S>В Kotlin есть.
В который это попало из Groovy
Который в свою очередь вдохновлялся Smalltalk
Хочу добавить, что на линуксе Pharo хорошо выглядит с вейландом, а вот на иксах у меня выглядит плохо. Поэтому для смолтока лучше открывать графическую сессию через вейланд
Если заглянуть под капот (и даже на сам капот), то прикольность резко сходит на нет.
В смолтоке имя метода с несколькими аргументами разбивается на токены.
object say: "hello" to: "world"
эту же идею Бред Кокс позаимствовал, сделав смолток-поверх-си, и назвав его Objective C.
Естественно, методы say:to: и to:say: — это разные методы! Так же, как в си — say_to(greeting, address) и to_say(address, greeting).
Это такие именованные аргументы для бедных, — на самом деле, позиционные, но с улучшенной читаемостью.
Так вот, булевы выражения — это тоже методы
x and: y
x and: y and: z
x and: y and: z and: t
представьте себе, там реально три метода конъюнкции и три метода дизъюнкции, а если вам нужно пять и более операндов, тогда раскладывайте на скобки
((x and: y and: z and: t) and: u and: v and: w)
(не уверен, что такое сделано в squeak, но вот в pharo — было так).
Та же история с ветвлениями
x ifTrue: block1
x ifFalse: block2
x ifTrue: block1 ifFalse: block2
x ifFalse: block2 ifTrue: block1
Ради вот такой читаемости пришлось городить множество методов. Потому что сам язык не умеет в именованные аргументы, да и не очень-то хотелось.
Кстати, ещё одно откровение из-под капота.
Поскольку True и False — это синглетоны, унаследованные от базового класса Boolean, то они перегружают всё это разнообразие!
Там нет паттерна "шаблонный метод", есть копипаста.
True >> and: y
^ y.
True >> and: y and: z
^ y and: z.
True >> and: y and: z and: t
^ y and: z and: t.
False >> and: y
^ self.
False >> and: y and: z
^ self.
False >> and: y and: z and: t
^ self.
True >> ifTrue: then
^ then value.
True >> ifFalse: else
^ nil.
True >> ifTrue: then ifFalse: else
^ then value.
True >> ifFalse: else ifTrue: then
^ then value.
# аналогично - False
Смысл этого — в том, чтобы ускорить диспетчеризацию. Не надо проваливаться внутрь предка — Boolean, где могла быть (но не была) реализована вся логика.
Но вот что характерно, obj ifNil: / ifNotNil: более предпочтительно, чем (obj isNil) ifTrue: / ifFalse:
ровно потому, что у синглетона nil переопределены ветвления, и мы сэкономим время работы — вместо двух методов дёрнем один.
А для всех остальных типов — числа там, строки, коллекции... — сделаны только предикаты isSomething (ну и операторы сравнения), но не ветвления.
Иначе бы рантайм вообще яростно распух, наверное.
Перекуём баги на фичи!
