Здравствуйте, Буравчик, Вы писали:

Б>Насколько увесистый? Размер сейчас не проблема, да

Размеры можно прикинуть по архивам, что распространяют.

Установщик запускающей программы 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

Похожее в лиспе за некоторым исключением. В лиспе иногда проще перезагрузить код полностью с нуля, чем вживую его поменять, хотя таких случаев очень и очень мало. А в целом, идея образа и инкрементальной восходящей разработки очень и очень близка для лиспа — это его второе имя.