Fwd: Оповещение Google - rsug

2013/7/25 Dennis Schetinin <[hidden email]>

Статические типы (опциональные) не так сложно (не сказать, просто) ввести в Smalltalk. Ведь тип — это всего лишь "сопроводительная" информация к объекту, добавить такие метаданные — совсем не проблема. 

Сами типы сделать просто, сложнее сделать вывод типов и грамотную систему типов в принципе.

 

Автоматический вывод типов — существует уже в нескольких воплощениях: начало я видел в статьях еще 80-х годов, лет пять–десять назад запомнился RoelTyper, в прошлом и в этом году в GSoC-е участвуют соответствующие проекты. Поиск по "Smalltalk type inference" дает массу интересных ссылок, включая совсем свежую статью [http://pleiad.dcc.uchile.cl/papers/2013/allendeAl-scp2013.pdf]. В общем, там наверняка куча проблем, но не все так безнадежно.

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

 

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

Мы сейчас про St или вообще? Если вообще, то я накидывал ссылок на инструменты основанные на системе типов.

 

Про организацию проверки правильности программ я вообще не припомню чтобы слышал — нужно это вообще в Smalltalk-е?

Собственно основная задача статической типизации — проверка корректности. Как так не слышал? :)

 

А попытаться увеличить скорость выполнения программ — вот это действительно интересная задача… и очень сложная, как я понимаю, при современном устройстве того же Pharo. Но, возможно, в этом направлении тоже идет работа? 

Ну на мой взгляд это как раз десятая проблема для St, на данный момент его производительность вполне приемлема.

Оверквотинг порезан.

Хочу добавить свои 5 копеек.

Вся проблема с статической типизацией, что она требует более полного описания
системы правил на каждом этапе разработки.
В идеале, любая программа должна иметь наиболее полную и естесвенно
непротиворечивую
систему правил по которой она работает.
Но написание самого кода собственно и есть процесс формирования этой
системы правил.
Что происходит, когда компилятор требует от вас то, о чем вы еще не
подумали и что еще вам самим непонятно? Вам приходиться
перестраиваться под него, чтобы его удовлетворить.
И вот получается, что при написании программы вам вместо формирования
своих правил, приходиться отвлекаться на занудство компилятора.
И этот диктат очень сильно влияет на конечный результат.
Простой пример: попробуйте унаследовать интерфейс в Жабе..
и допустим что на данный момент ваш код вызывает только один (1) метод
этого интерфейса,
тогда как интерфейс описует 10. Однако компилятор в жизни не отпустит
вас пока вы не накопи-пастите все 10 методов.

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

Более того, очень важное отличие: в смаллтолке ошибка это норма.  На
самом деле такое понятие как "ошибка" даже не определена на уровне
языка. Конечно за исключением ошибок синтаксиса, но с учетом насколько
прост синтаксис это никогда не вызывает головной боли.
Ошибки в смаллтолке определены как отдельная библиотека, которой можно
пользоваться, а можно и полностью игнорировать.
Что такое ошибка, а что нет полностью отдано на суд разработчика.
То-есть не система определяет что есть ошибка в коде/программе, а
человек.
А это значит, что мне для описания своего свода правил ничего не
мешает. (окромя семантики языка которая зашита намертво в ВМ :) )

--
Best regards,
Igor Stasenko.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

Оверквотинг порезан.

Хочу добавить свои 5 копеек.

Вся проблема с статической типизацией, что она требует более полного описания
системы правил на каждом этапе разработки.
В идеале, любая программа должна иметь наиболее полную и естесвенно
непротиворечивую
систему правил по которой она работает.
Но написание самого кода собственно и есть процесс формирования этой
системы правил.
Что происходит, когда компилятор требует от вас то, о чем вы еще не
подумали и что еще вам самим непонятно? Вам приходиться
перестраиваться под него, чтобы его удовлетворить.
И вот получается, что при написании программы вам вместо формирования
своих правил, приходиться отвлекаться на занудство компилятора.
И этот диктат очень сильно влияет на конечный результат.
Простой пример: попробуйте унаследовать интерфейс в Жабе..
и допустим что на данный момент ваш код вызывает только один (1) метод
этого интерфейса,
тогда как интерфейс описует 10. Однако компилятор в жизни не отпустит
вас пока вы не накопи-пастите все 10 методов.

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

Более того, очень важное отличие: в смаллтолке ошибка это норма.  На
самом деле такое понятие как "ошибка" даже не определена на уровне
языка. Конечно за исключением ошибок синтаксиса, но с учетом насколько
прост синтаксис это никогда не вызывает головной боли.
Ошибки в смаллтолке определены как отдельная библиотека, которой можно
пользоваться, а можно и полностью игнорировать.
Что такое ошибка, а что нет полностью отдано на суд разработчика.
То-есть не система определяет что есть ошибка в коде/программе, а
человек.
А это значит, что мне для описания своего свода правил ничего не
мешает. (окромя семантики языка которая зашита намертво в ВМ :) )

--
Best regards,
Igor Stasenko.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

У меня несколько иной взгляд на Smalltalk. Наверное, это от немного другой системы ценностей. Было очень верно замечено, что Smalltalk "раздеребанили на "фичи"", да и продолжают "раздеребанивать". Но для меня ценность Smalltalk-а не в этих отдельных фичах, а в их синтезе, в том, что все они "нанизаны" на одну идею под названием "простота". По сути, Smalltalk — это просто неразрывная связка понятий "объект–сообщение" — максимально простая и, что важно, естественная для человек вещь (общение людей построено именно на этом принципе). Все остальное вырастает оттуда без необходимости расширять язык. Как и с обычным человеческим языком: любое понятие на нем можно выразить, оставаясь в рамках все той же "языковой основы". (Тут есть проблемы с терминологией, но суть, надеюсь, ясна?) 

Интерес к тому же Haskell-у у меня пропал ровно в тот момент, когда я прочитал, что для добавление новых "фишек" расширяется язык. (Поправьте, пожалуйста, если это не так — информация может быть не достоверной.) И Newspeak мне не понравился по этой же причине — это просто еще один feature-oriented programming language.

Да, в Smalltalk-е это дело не провели на 100% (хотя некоторые это оспаривают), но подошли близко. Но "правильное" будущее, на мой взгляд лежит именно на этом пути: от простого к сложному в рамках одной основополагающей идеи. С максимальным сохранением простоты на каждом шаге ("настолько сложно, насколько необходимо, но не сложнее").

Например, что касается типов. (Судя по всему, разговор о строгой типизации в соседней ветке близок к финалу. Хотя прямого ответа на поставленный вопрос "так, стоит оно того или нет?" я в явном виде и не получил, но понимаю, что он близок к утвердительному). Я вполне согласен, что дополнительная мета-информация об объектах (в том числе из типизация) — это весьма полезный инструмент. Я вот только не согласен, что она нужна всегда и везде, что система должна отказываться работать без этих данных; что она должна быть в основе языка, усложняя его. Поэтому я бы хотел видеть это как дополнительный подключаемый модуль, реализующий типы в виде "подсказок" (hint-ов) программисту (для контроля правильности программы, для проведения рефакторинга, помощи при написании кода и т.п.) и системе (для повышения производительности, но, опять же, с "позволения" программиста). Жизнь не позволяет не только самому плотно заняться реализацией этих идей, но даже и отслеживанием положения дел (идеи, конечно, не новые, был уже ряд попыток что-то подобное сделать даже в Smalltalk-е) — не хотят за это платить (или я не в состоянии найти такие источники) :)   … Но именно этот подход мне кажется наиболее перспективным.

В этом отношении очень радует, как развивается Pharo. Возможно, будущее не за Smalltalk-ом в том виде, в каком он есть сейчас, но это вопрос отдаленного будущего. Но на ближайшее будущее именно Pharo дает возможность Smalltalk-у показать возможные пути развития технологий программирования. Респект Дюкасу, его команде и всем разработчикам, которые находят возможность развивать Smalltalk! Игорю — в частности :)

--

Best regards,

Dennis Schetinin

23 июля 2013 г., 11:11 пользователь Semyon Novikov <[hidden email]> написал:

Вообще что-то нас от темы разговора опять унесло. Если кому-то интересно мое мнение, то я не вижу ничего плохого в том, что Смолток живет в некотором гетто состоящем из кучки живых смолтокеров и Алана Кея :)

Я прекрасно помню свои первые впечатления от Squeak: ужас и отторжение, хотя у меня на тот момент уже был опыт работы с инфиксным синтаксисом (Objective-C). Смолток выглядел слишком странным даже для человека с опытом. Так что расчитывать на то, что люди и правда ломанутся писать на St, даже при условии появления удобной и "бесшовной" среды я бы не стал. Мне понадобилось довольно много времени чтобы оценить удобство разработки в класс-браузере и отсутствие файлов для исходников. Это действительно требует некоторого излома в мозгу, а если у вас нет ни желания ни времени ломать себе мозг, проще взять что-то менее экзотичное. И это нормально.

На данный момент, если честно оглядеться вокруг, есть вагон и маленькая тележка языков превосходящих как по гибкости, так и по надежности любую из существующих реализаций Smalltalk. Единственное место, где он еще силен это среда быстрой разработки, хотя и тут, я боюсь, толковая IDE для Java с поддержкой дебаггера уделает его довольно легко.

В добавок ко всему, кажется мир наигрался в динамическую типизацию. Я сам пишу на Objective-C большую часть дня. Несмотря на то, что формально там статическая типизация (причем самого низкого пошиба, с аннотациями типов), мне ее мало. Я постоянно натыкаюсь на рантаймовые ошибки в своем коде. Поэтому когда время от времени у меня появляется возможность написать что-нибудь на языке с хорошей статической типизацией (Haskell, ML, Go, Typescript) я радуюсь как ребенок. Smalltalk в этом отношении не сделал никаких толковых шагов с последнего релиза Strongtalk в 2006 году. (Опережая обвинение в пассивности: я глупый, у меня головы не хватит подхватить разработку Strongtalk)

Ну есть еще Василий Быков с Гиладом Брахой, которые тихонечко пилят Newspeak и что-то робко говорят о Pluggable Typesystems. В общем-то там прорывов тоже не ожидается, хотя работа очень интересная.

В итоге я думаю, что Smalltalk нашел свою нишу именно в гетто и это хорошо, потому что мог бы не найти вообще никакой. Smalltalk великий язык, который недооценен. Приятно так думать, да, но недооцененным он был году эдак в 90. Теперь его раздеребанили на "фичи" и называть Smalltalk недооцененным сегодня у меня язык не поворачивается. Все, что умеет St (минус среда разработки) может делать тот же самый мерзкий Ruby (там даже посылка сообщений, а не вызов по указателю).

Периодически на меня нападает какая-то тоска и я пишу на Smalltalk всякую хренотень. Но писать на нем что-то всерьез и в продакшн теперь уже я бы не рискнул.

Тем не менее я считаю важным поддерживать эту группу хоть в каком-то виде. Люди уже начали забывать откуда у них появились итераторы с блоками и посылка сообщений. Суть группы я вижу не в агрессивной проповеди смолтока, а в спокойном поддержании "статус-кво" смолтока. Возможно он еще нас удивит.

 

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.
 
Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.