Вышел Pharo 7.0

и что? я в 1990-м трассировку делала на ассемблере. уже тогда всё это было. там тригонометрия и простейшая графика. в чём особая новизна конкретно этой реализации? ну, прикрутили к трассировке менюшечки и кнопочки для юзера.

https://en.wikipedia.org/wiki/Alan_Kay https://en.wikipedia.org/wiki/Iron_Bug

Если серьезно, то это был прототип нового типа пользовательского интерфейса от «пап» ГИП, а не «3д-рисовалка».

ну, получилась 3д рисовалка. а уж как это называть - это дело вкуса.

и при чём тут вики? там нет инфы на большинство людей. и это к лучшему.

з.ы. да, мне абсолютно насрать на «великих». я вообще никому не поклоняюсь.

Вопрос звучал «чем отличается от других». Вот именно этим. Не всем «насрать на великих», некоторые у них учатся.

Мне кажется, ты с языком не знаком.

Тебе кажется неправильно.

с java.reflect я не знаком, действительно. Я до этого только java.lang.reflect использовал.

А, то есть у тебя есть опыт. То есть ты не по невежству глупости говоришь, а сознательно вбрасываешь.

То-то у VW с месяц назад новая версия вышла.

MR, не больше.

Выйти-то вышла, но вот роадмап на будущее на последней конфе они показать затруднились.

но «интересным» я бы это не назвал

У каждого свой скоуп интересов: кому-то резиторы/микросхемы попаять, а кому-то плазмиды поковырять.

Но в чем преимущества Smalltalk сейчас?

Я 10 лет пристально смотрю на смолток, и за 10 лет подтвердил для себя следующую мысль.

Если смотреть на смолток как на язык, что многие делают просто проецируя свой предыдущий опыт с каноничных _яп_, то нет там преимуществ - все _языковые_ возможности в том или ином виде расползлись по другим мейнстримным языкам.

Ценность смолтока именно в его объектном окружении - где объекты живут своей жизнью и их можно буквально потрогать. И среда (читай development environment) - способ коммуникации программиста с этой средой (опа! читай object environment).

Это довольно сложно расчувствовать просто «сидя на диване» и пытаясь понять, чем же он так прелестен. Нужен именно опыт ливкодинга и ливдебаггенга (или, комбо, ливкодинга в дебаггере) чтобы этим проникнуться.

На сегодня главная ценность смолтока в его накопленных и эволюционировавших тулах (или, вернее, тулах для тулов). Тру смолтокеры пишут свои тулы (из тулов) для решения уже конкретных задач, как-то Moose пример для анализа данных или проектов. Другой пример - платформа для eDSL, да не простая, а золотая. Можно (проторенным путем) натянуть смолтоковскую среду - инспекторы, дебаггеры, браузеры объектов, и прочее - на кастомный язык и использовать имеющиеся прелести уже в нем. SCG Helvetia был, наверное, самой документированной попыткой это сделать, но на недавней конфе я видел что-то подобное уже из других рук.

Вот ещё немного мыслей об оправданном применении (опять же, с последнего ESUG): https://www.slideshare.net/esug/guerilla-it-with-pharo

Тут: Вышел Pharo 7.0 (комментарий)

У каждого свой скоуп интересов

Согласен. Это я с точки зрения программиста (и более широко, инженера) не представляю, какой может быть интерес разбираться с этим дремучим легаси. А с точки зрения непредвзятого исследователя, конечно, может быть и интересно. Главное не пытаться в этом искать инженерные решения.

Ничего не понял. По ссылке какой-то поток сознания, вероятно, понятный только для своих.

Остается впечатление, что SmallTalk был актуальным в начале 1980-х, когда у желающих поиграться с ООП инструментов практически-то и не было. Но уже с конца 1980-х ситуация начала меняться не в пользу SmallTalk-а. И сейчас SmallTalk интересен разве что тем немногим, кому SmallTalk отлично зашел по каким-то эстетическим причинам.

Про инструменты, которые создаются для предметной области, так это практически про все языки можно сказать. Наверное, любой мейнстримный язык ценен фреймворками и библиотеками.

Колупание внутри SmallTalk-овской среды... Ну хз. Вряд ли это полезно, если программа манипулирует большими объемами данных или обрабатывать приличный поток событий.

Про инструменты, которые создаются для предметной области, так это практически про все языки можно сказать. Наверное, любой мейнстримный язык ценен фреймворками и библиотеками.

Ладно, попытаюсь привести ещё одну аналогию. Eclipse (кстати, ноги которой растут из IBM VA ST). Вроде как среда чтобы код писать, а вроде как и нет, целая платформа - и вот натягивают её то для одного применения, то для другого.

Фреймворки и библиотеки других ЯП всё же не совсем верная тут аналогия, речь идет не о просто переиспользуемых компонентах, а о синтезе новых поверх старых под конкретный кейс.

Вот ещё, пожалуй, наглядный пример

Ну и, на десерт.

Процессор почти каждого отписавшегося здесь ненужниста или скептика выпечен на оборудовании под управлением смолток-системы (поэтому и LAM Research много где в спонсорах).

На сегодня главная ценность смолтока в его накопленных и эволюционировавших тулах (или, вернее, тулах для тулов).

А ценность других языков — в том, что они легко совместимы с накопленными и эволюционировавшими УНИВЕРСАЛЬНЫМИ тулами. И поэтому там, где программист на нормальном языке просто грепает исходники, смолтокеры

пишут свои тулы

Угу, а ЛОР написан на джаве. При этом говном является и то, и другое.

Процессор ... выпечен на оборудовании под управлением смолток-системы

Угу, а ЛОР написан на джаве. При этом говном является и то, и другое.

И ЛОР, и процессоры? И ЛОР, и джава? И джава, и смоллток? И небо, и Аллах?

А что не говно? Что создал уважаемый дон, так легко называющий говном тяжелый труд множества людей? Ну, кроме пяти звезд на форуме.

То есть ты не по невежству глупости говоришь, а сознательно вбрасываешь.

Я не пойму что ты хочешь. Если ты сам знаком, то вполне понимаешь, что рефлекшн в яве предоставляет самую что ни на есть динамику.

А ценность других языков — в том, что они легко совместимы с накопленными и эволюционировавшими УНИВЕРСАЛЬНЫМИ тулами

После этой фразы я ожидал какой-нибудь убедительный пример...

И поэтому там, где программист на нормальном языке просто грепает исходники

Вах, это он и есть? :) Ценность нормальных языков в том, что программы на них - текстовые файлы и потому их можно грепать грепом? А, ну да, а ещё катать катом, и наверное даже удалять рмом. Бесценно!

Ну раз уж повернули дискуссию в эту сторону, давайте продолжим.

Грепая исходники, программист на нормальном ценном языке работает не с кодом, а с текстом. Объектно-ориентированные языки программирования оперируют классами, методами, слотами (переменными-членами), отношениями типа наследования или включения, и прочими сущностями. Но для грепа их не существует, для него есть только бездушные строчки и он сматчит всё, что сматчится.

Да, программист на смолтоке не грепает - ибо у него есть для этого куда более мощный арсенал. Код в привычном понимании в смолтоке есть только у методов, все остальное - это уже живые объекты, с которыми программист общается через класс-браузер. А путем некоторых простых манипуляций этот класс-браузер становится браузером по, например, объектам бизнес-модели. И поиск тот же берет и ищет по бизнес-объектам, в текущем образе у конкретного заказчика.

Грепни-ка по бизнес-объектам в памяти программы, написанной на нормальном языке (ещё и небось скомпилированной до неузнаваемости)

рефлекшн в яве предоставляет самую что ни на есть динамику.

Ты можешь подсунуть в вызов метода через рефлексию вместо ожидаемого класса свой независимый (не производный) класс, совместимый по сигнатурам всех методов? Насколько я помню, нет. А в динамически типизированном языке это должно быть возможно. Ява ни с какой стороны не динамически типизированный язык.

не с кодом, а с текстом

А код — это текст.

Основная ошибка смолтокеров именно в этом — они считают, что код — это какая-то сложная древовидная структура с перекрёстными ссылками. Реально же таковым является только законченный код, и то не вполне; в процессе написания код — это чистый текст.

ибо у него есть для этого куда более мощный арсенал

Нет, извини, не поверю. Хотя бы потому, что этот «мощный арсенал» — это только и исключительно то, что написали другие два с половиной смолтокера, причём даже для смолтокеров распространение своего труда — нетривиальная задача (в нормальном языке достаточно Cmd+C, Cmd+V в емэйл или в форму ввода на форуме — и да, это ТОЖЕ универсальные инструменты).

Грепни-ка по бизнес-объектам в памяти программы

Ага, живо себе представляю, как Билл Гейтс лично браузит объекты в памяти каждой копии винды. Как бывший эрлангист могу точно сказать: лезть в работающую систему и изнутри её подкручивать — это признак полной безнадёги (хотя в Эрланге это вполне возможно).

Грепая исходники, программист на нормальном ценном языке работает не с кодом, а с текстом.

Это, зачастую, костыль, и если хотим какой-то мало-мальски сложной работы с исходниками, получаем тот ещё велосипед из шланговского парсера, промежуточных файлов и vim|emacs — но это юниксвейный UnixWay. Другое дело, что большая часть народа предпочитает народа даже под онтопиком предпочитает неюниксвейные навороченные IDE. От «реактивных мозгов», к примеру.

Объектно-ориентированные языки программирования оперируют классами, методами, слотами (переменными-членами), отношениями типа наследования или включения, и прочими сущностями

А тут простота и мощность, но цена даже не то, что это единая среда (не так много чистых unixwayщиков-то) для привычных unix-инструментов (grep'ов там) места просто не осталось.

ps. А можно вам, как местному Smalltalk-гуру задать чайниковский вопрос в этой связи. Есть opensource-проект (заброшенный) в виде image-файла под 32-разрядный squeak 3.1. Как бы мне это дело вытянуть? Только скомпилировать аналогичную VM? Или можно современную OpenSmalltalk VM, но только 32-разрядную? Или как?

Другое дело, что большая часть народа предпочитает народа даже под онтопиком предпочитает неюниксвейные навороченные IDE.

Ну дык. Предпочитают — и пользуют. Потому как она тоже универсальный инструмент (более-менее). А теперь попробуй использовать ту же навороченную IDE (от «реактивных мозгов», к примеру) со смолтоком.

Есть opensource-проект (заброшенный) в виде image-файла под 32-разрядный squeak 3.1. Как бы мне это дело вытянуть?

К вопросу о лёгкости распространения результатов своего труда.

Реально же таковым является только законченный код, и то не вполне; в процессе написания код — это чистый текст.

Ну это мнение оспариваемо в любой продвинутой REPL-среде (forth, lisp, factor), но объектная-ориентированность смолтока даёт к этому большие основания.

Нет, извини, не поверю. Хотя бы потому, что этот «мощный арсенал» — это только и исключительно то, что написали другие два с половиной смолтокера

Ссылку на «Лося» я давал чуть выше http://www.moosetechnology.org/. Подробно не смотрел, и вообще, я в ST полный чайник, но заявленые инструменты вроде языка запросов к кодовой базе проекта, или примеры вроде простого поиска использования depricated в java-коде с последующим полуавтоматическим исправлением достаточно впечатляют. Grep — отдыхает.

в нормальном языке достаточно Cmd+C, Cmd+V в емэйл или в форму ввода на форуме — и да, это ТОЖЕ универсальные инструменты

А вот тут, как у человека только-только начинающего вникать в SmallTalk вопросы есть. Если yoghurt по этому поводу всех нас просветит — спасибо скажу.

Есть opensource-проект (заброшенный) в виде image-файла под 32-разрядный squeak 3.1. Как бы мне это дело вытянуть? Только скомпилировать аналогичную VM? Или можно современную OpenSmalltalk VM, но только 32-разрядную? Или как?

Можно попробовать запуститься вот на этом: https://squeak.js.org

На https://squeak.org/downloads/ есть все версии, начиная с первой. Конкретно 3.1 вм там нет, но можно попробовать на 3.2

Ты можешь подсунуть в вызов метода через рефлексию вместо ожидаемого класса свой независимый (не производный) класс, совместимый по сигнатурам всех методов?

Находишь нужный класс по имени, затем находишь нужный метод по сигнатуре. Затем вызываешь. Вообще проблем нет.

Ява ни с какой стороны не динамически типизированный язык.

Удивительно, язык, который создавался статически типизированным, вдруг не динамически типизированный? Случайно у них так получилось. :) А если серьёзно, то речь как раз о том, что приходится использовать reflection, что в динамически типизированных языках искаропки.

ПС: но я сам за статическую типизацию, ибо для динамической типизации программировать надо уметь, но где же таких людей нынче найдёшь?

Глянул. The Moose Book начинается с Analyzing Java code — что отлично (молодцы, не завязываются на один смолток), но не вызывает особого энтуазизма в отношении именно смолтока. А первая задача, которую они приводят:

Essentially, this boils down to finding the classes annotated with @Deprecated and then selecting those that are not used anywhere (we ignore reflection for this exercise). This is an analysis.

Господи, да просто удалите/переименуйте эти классы и запустите компиляцию. Компилятор вам скажет, что ещё используется, а что — нет, причём сделает это с гарантией (потому что статическая типизация). Я подобные вещи каждый день делаю, и текстовое представление для этого подходит идеально.

Это я не к тому, что Moose бесполезен, нет. Но мне кажется, что эти ребята не вполне представляют себе, как работает современная индустрия программирования.

Если уметь программировать, то рефлексия как раз не понадобится. Разве что в отдельных тёмных углах.

Как бывший эрлангист могу точно сказать: лезть в работающую систему и изнутри её подкручивать — это признак полной безнадёги (хотя в Эрланге это вполне возможно).

О, интересно. Позволь отвлечь тебя от Смолтока и задать несколько вопросов как бывшему эрлангисту.

И как часто, по твоей оценке, в работающих системах на Эрланге случается полная безнадёга? Не потому ли в Эрланге сделали вполне возможным подкрутить работающую систему изнутри, что смирились с возникающими время от времени ситуациями полной безнадёги? Есть ли способы избегать этих ситуаций, а не мириться с ними? Да и, собственно, а помогает ли это подкручивание справиться с безнадёгой?

Находишь нужный класс по имени, затем находишь нужный метод по сигнатуре. Затем вызываешь. Вообще проблем нет.

Еще раз, медленно - ты можешь создать свой класс и передать его в существующий метод? Нет. А значит, это не динамическая типизация.

А если серьёзно, то речь как раз о том, что

...что якобы «всё самое интересное и нужное через рефлекшн сделано на самой что ни на есть динамике». А там нет никакой динамики. Рефлексия есть, а динаимикки нет.

Если уметь программировать, то рефлексия как раз не понадобится.

Рефлексия совершенно необходима для инструментов вроде отладчиков (и не только их).

Можно попробовать запуститься вот на этом: https://squeak.js.org

Можно и на этом (загружаться вроде начало), хотя слегка перанально. А в общем по совместимости образов и VM что-то почитать можно, или не интересовались этим вопросом?

Как потом нужные куски исходника в текст вытягивать — это как раз понятно примерно, потому не спрашиваю.

На https://squeak.org/downloads/ есть все версии, начиная с первой. Конкретно 3.1 вм там нет, но можно попробовать на 3.2

ну или так.

Вы кажется просто понимаете под «динамикой» разные вещи. Динамической типизации в Java нет. Runtime, несколько похожий на часть реализации этой самой д.т. — в наличии.

А код — это текст.

А текст - байты. А байты - биты. Так давайте-те программировать точечными воздействиями электрических зарядов прямо в плату!

Реально же таковым является только законченный код, и то не вполне;

В нормальных языках - да

в процессе написания код — это чистый текст.

Да, и даже в смолтоке. Но гранулярность написания ограничена телом одного метода. Стоит метод сохранить, если он синтаксически валиден - он сразу становится частью _рабочей_ системы и доступен для вызова.

причём даже для смолтокеров распространение своего труда — нетривиальная задача

Ну как сказать. Первые образы были настолько переносимы, что копировались с платформы на платформу чуть ли не «как есть» и тут же работали (при совместимости байткодов) - и это в мохнатых 80x.

(в нормальном языке достаточно Cmd+C, Cmd+V в емэйл или в форму ввода на форуме — и да, это ТОЖЕ универсальные инструменты).

Так и смолтоков код нормально копипастится, разве нет? Ну да, если хочется скопировать что-то больше метода, надо сделать файлаут - всего то

Рантайм, несколько похожий на часть - может быть.

Рефлексия совершенно необходима для инструментов вроде отладчиков (и не только их).

Я постоянно забываю про отладчики. Не запускал уже лет пять, наверное.

Так давайте-те программировать точечными воздействиями электрических зарядов прямо в плату!

Зачем? Текст умеют понимать все, даже смолток.

Первые образы были настолько переносимы, что копировались с платформы на платформу чуть ли не «как есть» и тут же работали (при совместимости байткодов) - и это в мохнатых 80x.

Ну, вот где-то в мохнатых 80х смолток и остался.

Ну да, если хочется скопировать что-то больше метода, надо сделать файлаут - всего то

Во, любители вприсядку подтянулись.

Я лично знаком с автором и у него свой (очень авторский) взгляд на это дело. И подход он синтезирует тоже свой, за счёт тех же тулов.

Мус по задумке автора - не конечный мышеклик-инструмент, а адаптируемая под каждую задачу платформа (очень грубо говоря, скриптуемая).

По подходу ключевые слова - humane assessment, по инструментам - https://gtoolkit.com

Ну если программировать умеешь, то и статическая типизация не понадобится. Речь то ведь не об этом.

Еще раз, медленно - ты можешь создать свой класс и передать его в существующий метод? Нет. А значит, это не динамическая типизация.

Вообще, статика от динамики отличается тем, что проверка типов будет выполнена на этапе компиляции, а не в рантайме. С рефлешином можно всё это увести на стадию рантайма. Или ты путаешь динамическую типизацию с чем-то другим?

Ну если программировать умеешь, то и статическая типизация не понадобится.

Статика — это не только ценный мех способ ловить некоторые ошибки программиста, но и способ добится эффективности выполнения. Сейчас конечно не 60-70-е, APL (J, Wolfram Mathematica) не реализуют в микропрограммном коде, и лисп- и смолток-машины тоже никто уже не делает, но у статических нативных языков, близких к железу, как то C/C++ и начинающий их теснить Rust немаленькая ниша в любом случае останется.

С рефлешином можно всё это увести на стадию рантайма.

И это будет закат солнца вручную.

Динамической типизации в Java нет.

В языке нет, да. Ну или почти нет. Но то, что позволяет динамика, достигается тем же java.lang.reflect

Вообще, статика от динамики отличается тем, что проверка типов будет выполнена на этапе компиляции, а не в рантайме.

Не совсем. В динамике тип проверяется при каждом использовании объекта.

С рефлешином можно всё это увести на стадию рантайма.

Нет. С рефлекшеном на стадии рантайма можно провести проверки, которые проводит компилятор. См. Вышел Pharo 7.0 (комментарий)

Или ты путаешь динамическую типизацию с чем-то другим?

Нет.

И это будет закат солнца вручную.

Ну люди уводят. Все браться живы. Ну, или почти все. :)

Рефлексия совершенно необходима для инструментов вроде отладчиков (и не только их).

Я постоянно забываю про отладчики.

Ну не только отладчики. Кодогенераторы, инструментация - всё это можно делать на уровне исходного кода, но на уровне объектного (с рефлексией) - гораздо удобнее.

В динамике тип проверяется при каждом использовании объекта.

Ааа, ну понятно. Динамическая типизация не есть слабая типизация.

С рефлекшеном на стадии рантайма можно провести проверки, которые проводит компилятор.

А, ну да, точно, понятно.

Нет.

Таки да.

Ааа, ну понятно. Динамическая типизация не есть слабая типизация.

Очевидно, что не понятно.

А, ну да, точно, понятно.

Точно не понятно.

Ну если программировать умеешь, то и статическая типизация не понадобится.

Когда пишешь код — да, тут я согласен.

А когда рефакторишь — она очень и очень нужна.