LINUX.ORG.RU

Вышел Pharo 7.0

 , , , ,


1

6

Сегодня вышла новая версия одной из самых популярных и развивающихся реализаций языка Smalltalk — Pharo.

Над релизом работали более 75 человек, были закрыты 2142 задачи, самые главные из которых:

  • Теперь Pharo поддерживает x64 для Linux и Mac. Версия для Windows также доступна, но находится в доработке.
  • Обновлен PharoLauncher — утилита для управления образами, сборками для Jenkins и различными версиями.
  • Изменен процесс сборки, теперь он поддерживает полный бутстрап из исходого кода. Это дает возможность создавать специализированные (микро)образы.
  • Iceberg (git-клиент) получил значительные улучшения и стал дефолтной системой по управлению кодом.
  • Calypso (краеугольный камень в PharoThings) стал новым системным браузером, заменив Nautilus. Он обладает множеством улучшений, в том числе в работе удаленно.
  • IoT теперь важная часть Pharo. PharoThings предоставляет внушительное количество утилит для разработки приложений под маленькие устройства.
  • UnifiedFFI значительно улучшен для работы с 64-битной Windows.

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

P.S. Поздравляю всех причастных и интересующихся!

Скачать

Подробный список изменений

>>> Официальный анонс

★★★★★

Проверено: Shaman007 ()

Ответ на: комментарий от anonymous

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

Iron_Bug ★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

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

Iron_Bug ★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

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

anonymous ()
Ответ на: комментарий от turtle_bazon

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от Darkman

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

MR, не больше.

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

yoghurt ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

Linfan ★★★★★ ()
Ответ на: комментарий от eao197

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

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

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

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

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

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

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

yoghurt ★★★★★ ()
Ответ на: комментарий от Linfan

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

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

anonymous ()
Ответ на: комментарий от yoghurt

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

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

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

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

eao197 ★★★★★ ()
Ответ на: комментарий от eao197

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

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

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

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

yoghurt ★★★★★ ()
Ответ на: комментарий от yoghurt

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

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

yoghurt ★★★★★ ()
Ответ на: комментарий от yoghurt

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

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

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

Miguel ★★★★★ ()
Ответ на: комментарий от yoghurt

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

Miguel ★★★★★ ()
Ответ на: комментарий от Miguel

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от tailgunner

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

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

turtle_bazon ★★★ ()
Ответ на: комментарий от Miguel

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

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

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

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

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

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

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

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

yoghurt ★★★★★ ()
Последнее исправление: yoghurt (всего исправлений: 1)
Ответ на: комментарий от turtle_bazon

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от yoghurt

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

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

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

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

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

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

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

Miguel ★★★★★ ()
Последнее исправление: Miguel (всего исправлений: 1)
Ответ на: комментарий от yoghurt

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

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

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

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

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

be_nt_all ()
Ответ на: комментарий от be_nt_all

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

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

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

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

Miguel ★★★★★ ()
Ответ на: комментарий от Miguel

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

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

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

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

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

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

be_nt_all ()
Ответ на: комментарий от be_nt_all

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

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

yoghurt ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

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

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

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

turtle_bazon ★★★ ()
Ответ на: комментарий от be_nt_all

Глянул. 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 бесполезен, нет. Но мне кажется, что эти ребята не вполне представляют себе, как работает современная индустрия программирования.

Miguel ★★★★★ ()
Ответ на: комментарий от turtle_bazon

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

Miguel ★★★★★ ()
Ответ на: комментарий от Miguel

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

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

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

anonymous ()
Ответ на: комментарий от turtle_bazon

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от Miguel

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от yoghurt

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

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

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

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

ну или так.

be_nt_all ()
Ответ на: комментарий от tailgunner

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

be_nt_all ()
Ответ на: комментарий от Miguel

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

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

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

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

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

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

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

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

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

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

yoghurt ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

Miguel ★★★★★ ()
Ответ на: комментарий от yoghurt

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

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

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

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

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

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

Miguel ★★★★★ ()
Ответ на: комментарий от Miguel

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

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

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

yoghurt ★★★★★ ()
Последнее исправление: yoghurt (всего исправлений: 1)
Ответ на: комментарий от Miguel

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

turtle_bazon ★★★ ()
Ответ на: комментарий от tailgunner

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

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

turtle_bazon ★★★ ()
Ответ на: комментарий от turtle_bazon

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

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

be_nt_all ()
Ответ на: комментарий от turtle_bazon

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

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

be_nt_all ()
Ответ на: комментарий от be_nt_all

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

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

turtle_bazon ★★★ ()
Ответ на: комментарий от turtle_bazon

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

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

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

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

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

Нет.

tailgunner ★★★★★ ()
Ответ на: комментарий от be_nt_all

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

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

turtle_bazon ★★★ ()
Ответ на: комментарий от Miguel

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

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

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

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

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

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

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

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

Нет.

Таки да.

turtle_bazon ★★★ ()
Ответ на: комментарий от turtle_bazon

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от turtle_bazon

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

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

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

Miguel ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.