Вышел Pharo 7.0

Зачем прятать то, без чего все равно не обойтись?

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

Реально же да, код постоянно меняется, но откатить изменения не просто, а очень просто (особенно при использовании VCS). А вот откатить стейт виртуальной машины... Ну, можно что-то придумать, наверное, но ресурсы оно будет жрать как не в себя.

Правку работающего кода? Конечно, применяют.

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

Груви же смог.

Я не работал с Груви, но подозреваю, что у него на входах всех методов - производные классы от какого-нибудь GroovyObject, и объект другого класса (не производного) ты туда подсунуть не сможешь.

Процесс разработки и есть постоянная мутация исходного кода.

И ты хочешь добавить к этому еще и мутацию образа. Которая даже не отслеживается инструментами, помогающими справляться с мутациями кода (VCS).

Ну в Sqeak/Pharo встроена какой-никакой Source Control — Monticello. Для этого добра есть репозиторий http://www.squeaksource.com/ Для интеграции с git вроде есть — Squot, но с pharo, кажется, не работает. Впрочем для Pharo нашлась аналогичная штука под названием iceberg. Ну и более низкоуровневые средства…

Ну в Sqeak/Pharo встроена какой-никакой Source Control — Monticello

Я не вижу там версионирования, диффа и мержа образов.

Диффы есть.

Где это написано и где можно увидеть пример диффа между образами?

Где это написано

http://wiki.squeak.org/squeak/43

Changes: opens a Patch Browser showing the changes that would occur to the image if this version of the package were loaded.

А вообще забавно, что именно мне приходится на такие вопросы отвечать, я то сварщик смолтокер ненастоящий, squeak (а заодно и pharo напосмотреть) себе за пару дней до выхода этой новости поставил, под конкретный hobbytime проект.

Upd. или имелся в виду diff между двумя произвольными версиями? «Из коробки», похоже, нет.

Где это написано

http://wiki.squeak.org/squeak/43

Насколько я понял, это отслеживание «пакетов» (насколько я понимаю, это только часть образа).

то <s>сварщик</s> смолтокер ненастоящий

Что поделать, если настоящих сварщиков то ли нет, то ли они хранят Смоллтокную Тайну.

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

Охренеть. То есть, ты реально не работал с системами контроля версий?

Работаю. Только редко когда запускаю что-то кроме коммита. Ну если сам кодю проджект.

Мдя. Тебе ещё расти и расти. Узнаешь, как работать с VCS, чем хороша иммутабельность, и ещё много интересного и полезного.

А вообще, в Постдамском университете целую 100-страничную книгу выпустили, один из авторов — автор Squot, где рассматривают различные решения на эту тему и общую идеологию совмещения идеи — «программа, как набор объектов» с идеей контроля версий.

Iceberg (git клиент) получил значительные улучшения и стал дефолтной системой по управлению кодом

В, собственно, самой новости. Так что если говорить о Pharo, а не о ванильном Squeak, ответ на вопрос «а как оно в Monticello» немного не актуален.

Ну, молодцы, чо. 2019 год.

Ну тому-же Monticello лет немало (больше двенадцати точно). В коммерческом VisualWorks и бывшем коммерческом (а теперь открытом) под оффтопик Dolphin Smalltalk тоже какие-то встроенные VCS есть. Велосипедостроение, конечно, но что-ж поделать если smalltalk-way он не только не похож на unix-way, но и вообще — особый (причём, кажется, родился чуть раньше).

По времени — ну тут тоже нужен фотофиниш. Unix отсчитывает системное время с начала 1970, но 1972 — это некая Unix 2, которая ещё не на Си была, а на Би. Первая версия смолтока Smalltalk-71, вторая — Smalltalk-72.

Велосипедостроение, конечно, но что-ж поделать

Во. Девиз смолтока. А всё почему? Потому что с универсальными инструментами мы работать не умеем, либо умеем, но мимо простаты.

А всё почему? Потому что с универсальными инструментами мы работать не умеем

А «универсальные» — это которые? Те самые, которые unix-way & worse-is-better?

Ну мой девиз - специализированное лучше абстрактного и знание реализации даёт большие возможности, чем использование АПИ. Я както выдвигал идею использовать функции в конкретном ЯП вместо комманд консоли и снабдить файловую систему типами, чтоб файл отличался от экземпляра класса только местом хранения. Система контроля версий должна хранить не текстовый дифф, а историю комманд в ИДЕ, таких как ренейм класс итп (тоесть объединится со стеком UNDO). Чтобы больше соответствовать своему мировозрению я поклялся перейти на эмакс, только что-то лень за это браться...

Инфраструктура емакса тебя доведёт до нервного срыва. Это далеко не самый красивый и архитектурно стройный огород несвежих костылей.

Вышла самая популярная среди самых непопулярных

я поклялся перейти на эмакс, только что-то лень за это браться...

Ну и кто ты после этого? Клятвопреступник, не иначе.

Всё проклятый научный атеизм виноват. Раньше-то люди, опасаясь гнева богов, к своим клятвам куда серьёзнее относились.

тикет

Ну мой девиз - специализированное лучше абстрактного и знание реализации даёт большие возможности, чем использование АПИ.

С таким девизом на любом реальном проекте утонешь в экспоненциально растущей сложности через месяц.

Хорошо, когда сам себе Бог. Любой грех себе простить изи.

Вот только если бога нет, кто это ухохатывается, когда мы рассказываем о наших планах? Неужели две слепые старухи — случайность и энтропия? Это не их ли древние греки звали Парками? «…наша смерть нас гонит вперёд…»

TIL, что C++ — интерпретируемый язычок.

~~@~~

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

Прям вижуал бейсик)

Сделали бы по типу common lisp среды со swank сервером, было бы куда универсальней. А так, мило, да, но не юзабельно

Вот только если бога нет, кто это ухохатывается, когда мы рассказываем о наших планах?

Другие люди, кто же ещё. Человеки (впрочем, как и другие приматы) завсегда поржать горазды, особенно над неудачами других человеков.

Пора напомнить о том, что тред о языке программирования. Итак у нас есть 2 подхода к программированию. 1 - сразу проверять куски кода на практике (удобнее всего в системах типа смолтолк) 2 - научный подход, который основывается на описании типов. С одной стороны проверки не гарантируют, да и вообще геморой + образы требуют привыкать к новым тулзам, которые еще и писать самому приходится. С другой стороны типы снова ничего не гарантируют и тестить всеравно надо. Вот только воспроизводить условия теста сложнее, в результате тестировать вообще лень и код так и остается с багами. + еще системы типизации на данный момент не развиты достаточно: либо они тупые как пробка, либо замороченные как в хаскеле. Dependent type задумка неплохая, но все существующие реализации заточены на дикий матан, да и в принципе плохо пихать всё в такую простую теорию, тот же сабтайпинг на практике очень полезен. Идеально было бы разрабатывать систему «помошник программиста», которая находится сбоку от кода и помогает с написанием, но разработки ориентированные чисто на такой подход вроде как вообще не ведутся. Или в смолтолке есть чтолибо подобное? Ну хотябы что-то вроде pvs-studio.

http://babelsberg.github.io/babelsberg-s/ — cсылка с офсайта Squeak. Подробности не смотрел, но вроде не самый дикий матан (обычные инварианты, их кажется Вирт в каком-то своём учебнике описывал, правда предлагал держать в голове, а не скармливать компилятору).

А PVS-Studio — статический анализатор, как-то сомневаюсь что к столь динамическому языку, как Smalltalk, такое прикручивается в принципе.

Я привел пример направления, в котором, по моему мнению, должна развиватся индустрия. Всмысле должен быть некий процесс, который бьёт тебя по рукам, когда видит, что ты пишешь глупость. А ну еще подсказывает, что ты наверно хотел бы тут написать. И всё. Тогда типы не нужны. Динамической типизации с выводом типов и оптимизацией внутри будет вполне достаточно.

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

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

Это лишь твое мнение основанное на небольшом опыте. В Смолтолке впринципе модель разработки такая что ты пишешь глупость, запускаешь и в дебагере дописываешь то чего не хватает/не работает.

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

Ну типа даже название для этого придумали, AST говорит о чем-то?

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

Ты говоришь законченный как будто продакшен. Законченный это когда я . поставил, с этого момента это уже AST который может анализироваться и обрабатывать тулами. То есть это 2-3 строки текста. В процесса написания 3х строк, ок, это текст.

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

Он где-то говорит про подкручивание? Он же про интроспекцию..

Сделали бы по типу common lisp среды со swank сервером, было бы куда универсальней.

Сделали: Emacs + Smalltalk

Это уныло если честно, по-моему смолтолку не нужна никакая «универсальность» в плане интеграции с внешними редакторами и тулами, потому что они могут 10% от того что умеет интерфейс смолтолка, в итоге все криво, неудобно а потом те кто решит попробовать еще и плеваться будут.

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

Это уныло если честно, по-моему смолтолку не нужна никакая «универсальность» в плане интеграции с внешними редакторами и тулами

Жиза

потому что они могут 10% от того что умеет интерфейс смолтолка, в итоге все криво, неудобно а потом те кто решит попробовать еще и плеваться будут.

На самом деле большого особо не надо. Достаточно отправки сообщений объектам, а дальше всё приложится. Естественно, какие-нибудь gtools на это не отмапить. В данном случае у шампы главная проблема в том, что я ей, увы, не пользуюсь (как и серьезного особо на смолтоке не пишу). Негде пока на это делать ставку, вот оно и не обрастает мясом с годами.

Но гит он текстовый

Гит - он бинарный (последняя условно текстовая VCS - это CVS).

поэтому тут не на уровне образа, а на уровне пакетов.

Скорее потому, что diff и merge для образа написать крайне трудно.

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

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

А где бы такой текст увидеть? Мне чисто из любопытства.

А можешь рассказать как в Смолтоке с конкурентностью? Отправка сообщения в Смолтоке всегда синхронная (также как и в Ruby), и от вызова метода отличается только наличием динамической диспетчеризации, верно? Есть какие-то асинхронные сообщения?

http://wiki.squeak.org/squeak/1105

Не копал в эту сторону. А чего ты хотел бы получить от этих асинхронных сообщений?

Если объект, кому работу работать, всё равно живет в рамках того же образа - профит от этого невелик.

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

Если речь об общении с удаленными объектами, то тут де-факто GemStone и надо смотреть, что для этого сделали они.

В общем и целом, т.к. сам момент обработки сообщения программируем, можно написать прокси-объект, который будет проксировать выполнение сообщений к проксируемому в отдельном смолтоковом зеленом процессе, а вызывающему возвращать некий Future - обертку над возвращенным значением с точкой синхронизации. Вопрос только, зачем, и что это за оборачиваемый объект такой (возвращаемся на пункты выше).

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

Вообще уже давно изобретено программирование по контракту, Ada + Spark, Eiffel плюс все что реализована на уровне библиотек в других языках, причем Ada + Spark вполне промышленное решение.

Ну или typed/racket. Но это всё уже не встраиваемое

Ракетка встраивается.

Я не совсем понял, что вычитывали предыдущие редакторы новости.

Сабж, наверное, кому-то нужен.