Статическая типизация -- это круто?

Никакая типизация не может защитить от электрика и ошибки ввода-вывода. Поэтому нет, конечно не начисто, но довольно близко. То есть если ваша программа на Haskell (или еще чем-нибудь еще более суровом типа Idris или Agda) скомпилировалась, то скорее всего она будет работать корректно в рамках той модели, которую вы там напрограммировали. Статика позволяет удостовериться, что вы в рамках собственного воображаемого мирка из данных и преобразований над ними делаете все как минимум непротиворечиво. Это дорогого стоит, кстати. Потому что вы можете на этапе компиляции найти архитектурную ошибку. Эдакий лихой способ больше думать о предметной области и меньше о коде, мне нравится.

Разработка "от типов" не исключает мелкие итерации и TDD, просто вы начинаете с описания типов. Они могут меняться, удаляться или появляться со временем, точно так же как в любой другой системе. Причем если вы поменяете тип и у вас все развалится, то оно развалится на этапе проверки типов, а не в рантайме. Еще приятным момент, что развалится везде, где может развалиться в принципе. Не надо рыскать по приложению и искать ошибки типизации в рантайме.

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

А "стандартная" наивная статическая типизация действительно часто мешает больше, чем помогает. Но я говорю о чуть более сложных вещах, о выводе типов, как минимум. Кому нравится писать эти жуткие аннотации? Компилятор их выведет сам (в большей или меньшей степени). А если это не примитивный вывод типов а-ля Go или Typescript, то оно еще и завершаемость проверит и валидность доказуемых высказываний, и еще много чего.

На Хаскеле писать очень приятно, я сам в продакшн ничего не писал, но знаю, что люди пишут с большим успехом (http://bazqux.com, например, написан на нем). Из статически типизированных языков я использую Go и Typescript. Они ближе к "традиционной статике", но умеют выводить типы выражений, что сильно облегчает работу.

Того хаскелиста я помню, но я не ставлю целью никого троллить, я люблю St, но у меня к нему сложное отношение.

Про Новояз послушал бы с удовольствием, не томи :))

---

From: [hidden email]
Date: Tue, 23 Jul 2013 12:01:44 +0400
Subject: [RSUG] Статическая типизация -- это круто?
To: [hidden email]

Много раз слышал/читал про "правильную" типизацию, но не нахожу времени, а самое главное — желания (ну, вот не убедили меня пока, что нужно выискивать время и тратить его на изучение этого подхода). Поэтому несколько глупых вопросов?

 

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

Реально, правильная статическая типизация исключает рантаймовые ошибки начисто? 

Ну, или иначе задам вопрос. "Стандартная" (C/++, Java, C#, Pascal и т.д.) статика мне только мешает. Усилия на раннее "приколачивание" типов и дальнейшее поддержание компилятора в удовлетворенном состоянии не оправдывает себя. По крайней мере, с моим стилем разработки, который, наверное, можно охарактеризовать как "agile", или более конкретно назвать TDD. 

Правильная типизация (Haskell & Co.) — оправдывает себя в реальной жизни? Нужно ли менять для этого "мой" стиль (постепенное выяснение требований к системе в процессе ее разработки и даже эксплуатации — все как Бек прописал когда-то, короче)? 

Когда несколько лет назад нас здесь троллил поклонник Haskell-а, он только пел про то, что все замечательно, но как это замечательно получается — я лично так и не понял. Не найдется ли у вас или других (я знаю, такие есть) обладателей глубоких знаний в области правильных (=функциональных? ну, или любых других, которые "превосходят Smalltalk по гибкости") ЯП желания и времени немного порекламировать (обосновано) эти более продвинутые технологии?

 

Smalltalk в этом отношении не сделал никаких толковых шагов с последнего релиза Strongtalk в 2006 году. (Опережая обвинение в пассивности: я глупый, у меня головы не хватит подхватить разработку Strongtalk)
Ну есть еще Василий Быков с Гиладом Брахой, которые тихонечко пилят Newspeak и что-то робко говорят о Pluggable Typesystems. В общем-то там прорывов тоже не ожидается, хотя работа очень интересная.

По этому поводу есть некоторые мысли, но я их пока не буду оглашать — зарезервирую это место на будущее :)
--
Best regards,


Dennis Schetinin

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

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

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

Насчет типизации в Dolphin предложили интересное решение - реализация необходимого протокола.

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

Никакая типизация не может защитить от электрика и ошибки ввода-вывода. Поэтому нет, конечно не начисто, но довольно близко. То есть если ваша программа на Haskell (или еще чем-нибудь еще более суровом типа Idris или Agda) скомпилировалась, то скорее всего она будет работать корректно в рамках той модели, которую вы там напрограммировали. Статика позволяет удостовериться, что вы в рамках собственного воображаемого мирка из данных и преобразований над ними делаете все как минимум непротиворечиво. Это дорогого стоит, кстати. Потому что вы можете на этапе компиляции найти архитектурную ошибку. Эдакий лихой способ больше думать о предметной области и меньше о коде, мне нравится.

Разработка "от типов" не исключает мелкие итерации и TDD, просто вы начинаете с описания типов. Они могут меняться, удаляться или появляться со временем, точно так же как в любой другой системе. Причем если вы поменяете тип и у вас все развалится, то оно развалится на этапе проверки типов, а не в рантайме. Еще приятным момент, что развалится везде, где может развалиться в принципе. Не надо рыскать по приложению и искать ошибки типизации в рантайме.

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

А "стандартная" наивная статическая типизация действительно часто мешает больше, чем помогает. Но я говорю о чуть более сложных вещах, о выводе типов, как минимум. Кому нравится писать эти жуткие аннотации? Компилятор их выведет сам (в большей или меньшей степени). А если это не примитивный вывод типов а-ля Go или Typescript, то оно еще и завершаемость проверит и валидность доказуемых высказываний, и еще много чего.

На Хаскеле писать очень приятно, я сам в продакшн ничего не писал, но знаю, что люди пишут с большим успехом (http://bazqux.com, например, написан на нем). Из статически типизированных языков я использую Go и Typescript. Они ближе к "традиционной статике", но умеют выводить типы выражений, что сильно облегчает работу.

Того хаскелиста я помню, но я не ставлю целью никого троллить, я люблю St, но у меня к нему сложное отношение.

Про Новояз послушал бы с удовольствием, не томи :))

---

From: [hidden email]
Date: Tue, 23 Jul 2013 12:01:44 +0400
Subject: [RSUG] Статическая типизация -- это круто?
To: [hidden email]

Много раз слышал/читал про "правильную" типизацию, но не нахожу времени, а самое главное — желания (ну, вот не убедили меня пока, что нужно выискивать время и тратить его на изучение этого подхода). Поэтому несколько глупых вопросов?

 

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

Реально, правильная статическая типизация исключает рантаймовые ошибки начисто? 

Ну, или иначе задам вопрос. "Стандартная" (C/++, Java, C#, Pascal и т.д.) статика мне только мешает. Усилия на раннее "приколачивание" типов и дальнейшее поддержание компилятора в удовлетворенном состоянии не оправдывает себя. По крайней мере, с моим стилем разработки, который, наверное, можно охарактеризовать как "agile", или более конкретно назвать TDD. 

Правильная типизация (Haskell & Co.) — оправдывает себя в реальной жизни? Нужно ли менять для этого "мой" стиль (постепенное выяснение требований к системе в процессе ее разработки и даже эксплуатации — все как Бек прописал когда-то, короче)? 

Когда несколько лет назад нас здесь троллил поклонник Haskell-а, он только пел про то, что все замечательно, но как это замечательно получается — я лично так и не понял. Не найдется ли у вас или других (я знаю, такие есть) обладателей глубоких знаний в области правильных (=функциональных? ну, или любых других, которые "превосходят Smalltalk по гибкости") ЯП желания и времени немного порекламировать (обосновано) эти более продвинутые технологии?

 

Smalltalk в этом отношении не сделал никаких толковых шагов с последнего релиза Strongtalk в 2006 году. (Опережая обвинение в пассивности: я глупый, у меня головы не хватит подхватить разработку Strongtalk)
Ну есть еще Василий Быков с Гиладом Брахой, которые тихонечко пилят Newspeak и что-то робко говорят о Pluggable Typesystems. В общем-то там прорывов тоже не ожидается, хотя работа очень интересная.

По этому поводу есть некоторые мысли, но я их пока не буду оглашать — зарезервирую это место на будущее :)
--
Best regards,


Dennis Schetinin

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

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

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

>Ну, или иначе задам вопрос. "Стандартная" (C/++, Java, C#, Pascal и т.д.) статика мне только мешает. Усилия на раннее "приколачивание" типов и дальнейшее поддержание компилятора в удовлетворенном состоянии не оправдывает себя. По крайней мере, с моим стилем разработки, который, наверное, можно охарактеризовать как "agile", или более конкретно назвать TDD.

Да, как правило. Как небольшое исключение, в  С++ (за остальные не скажу) можно тоже выделывать интересные вещи с типами, шаблонами, двухэтажными шаблонами, трёхэтажными шаблонами, и т.д. Но это удел особых акробатов, навроде Александреску и последователей. Тут очень верно подмечена "стандартность" таких систем типов. Как правило, сводится всё к указанию типов используемых переменных (в С++11 появилось auto, ура), и типов объектов, с которыми нам предстоит взаимодействовать.

> Правильная типизация (Haskell & Co.) — оправдывает себя в реальной жизни? Нужно ли менять для этого "мой" стиль (постепенное выяснение требований к системе в процессе ее разработки и даже эксплуатации — все как Бек прописал когда-то, короче)? 

В Haskell типизация выходит (точнее вышла, для меня-темноты) на абсолютно новый уровень. Сейчас попытаюсь объяснить, в чём соль.

В Haskell типы охватывают почти все аспекты внутренней структуры программы. Каждая функция имеет свой тип. Вы скажете, "ну и что, у нас вот в C++/Java/Whatever тоже каждая функция/метод имеют свой тип". Но благодаря чистоте Haskell, грубо говоря, всё, что мы можем сделать в функции, отражено в её типе.

Приведу наболевший пример из своей небольшой, но всё же, практики. По работе мне приходилось поддерживать довольно большие проекты (~ 3 млн строк) на С++. Кто только не прикладывал руку к этим тоннам кода за 10+ лет! О качестве того, что там творилось, лучше не говорить. Порой, когда что-то в очередной раз отвалится (или выяснится, что что-то всегда отваливалось, но мы только заметили), на анализ происходящего в портянках на несколько экранов уходили долгие дни, а то и недели. Что только не делалось в одном отдельно взятом методе, куда только оттуда не обращались, чего оттуда только не модифицировали, перетасовывали, преобразовывали, открывали, закрывали, и так далее. Можно долго размышлять о том, почему разработчик(и) сделали именно так, но в конечном итоге это потому что они просто могут!. Они могут писать такой код, и пишут. И он даже работает, до поры-до времени. Компилятор C++ безропотно переводит этот креатив в машинный код и не предоставляет почти никаких средств для контроля и ограничения за происходящим. Глядя на сигнатуру метода или функции, мы не можем ничего о нём сказать. Обратится ли он к объекту А? Модифицирует ли он объект Б? Полезет ли он в Интернет в процессе работы?

Haskell, изящно комбинируя множество идей, за счёт сочетания свой продвинутой системы типов, монад, и чистоты отвечает на эти вопросы. А компилятор не даёт смешивать теплое с мягким.

Если функция, в прототипе которой обозначено, что она в процессе работы обращается (читает) окружение A (Reader A), мы не сможем из неё вызвать функцию, которая в процессе работы что-то сообщает (пишет) в B (Writer B). И обе они гарантированно не будут обращаться к диску или лезть в Интернет.

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

Хотя, с другой стороны, бывает, что с компилятором Haskell приходится повоевать, когда его представления о типах не совпадают с нашими. Не самый приятный процесс :)

Выдыхаю,

Дмитрий

23 июля 2013 г., 12:01 пользователь Dennis Schetinin <[hidden email]> написал:

Много раз слышал/читал про "правильную" типизацию, но не нахожу времени, а самое главное — желания (ну, вот не убедили меня пока, что нужно выискивать время и тратить его на изучение этого подхода). Поэтому несколько глупых вопросов?

 

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

Реально, правильная статическая типизация исключает рантаймовые ошибки начисто? 

Ну, или иначе задам вопрос. "Стандартная" (C/++, Java, C#, Pascal и т.д.) статика мне только мешает. Усилия на раннее "приколачивание" типов и дальнейшее поддержание компилятора в удовлетворенном состоянии не оправдывает себя. По крайней мере, с моим стилем разработки, который, наверное, можно охарактеризовать как "agile", или более конкретно назвать TDD. 

Правильная типизация (Haskell & Co.) — оправдывает себя в реальной жизни? Нужно ли менять для этого "мой" стиль (постепенное выяснение требований к системе в процессе ее разработки и даже эксплуатации — все как Бек прописал когда-то, короче)? 

Когда несколько лет назад нас здесь троллил поклонник Haskell-а, он только пел про то, что все замечательно, но как это замечательно получается — я лично так и не понял. Не найдется ли у вас или других (я знаю, такие есть) обладателей глубоких знаний в области правильных (=функциональных? ну, или любых других, которые "превосходят Smalltalk по гибкости") ЯП желания и времени немного порекламировать (обосновано) эти более продвинутые технологии?

 

Smalltalk в этом отношении не сделал никаких толковых шагов с последнего релиза Strongtalk в 2006 году. (Опережая обвинение в пассивности: я глупый, у меня головы не хватит подхватить разработку Strongtalk)
Ну есть еще Василий Быков с Гиладом Брахой, которые тихонечко пилят Newspeak и что-то робко говорят о Pluggable Typesystems. В общем-то там прорывов тоже не ожидается, хотя работа очень интересная.

По этому поводу есть некоторые мысли, но я их пока не буду оглашать — зарезервирую это место на будущее :)

--

Best regards,

Dennis Schetinin

--

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

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

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

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

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

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

1. Интерфейс задокументирован
2. Соответствие кода интерфейсам проверяется компилятором

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

При этом вообще никто не мешает использовать максимально "общие интерфейсы" там, где нужно передавать данные между частями программы, который компилятор проверить не в силах, например общение с другим ПО по http.

Это все прекрасно покрывается TDD (в ее полном воплощении, то есть когда "классику" предваряет построение "сверху-вниз" с помощью моков. Причем на выходе получается не отдельно код и отдельно система типов, а только один сплошной код ("реализация" и "тесты"). Другое дело, что весь потенциал этого подхода до сих пор не раскрыт… Но это отдельный разговор… Как и то, что здесь как раз виднеется "смыкание" обоих подходов: код ведь тоже поддается анализу, и аннотации к коду (разновидностью которых являются типы) тоже могут быть записаны в виде кода…

Но возвращаясь к теме, замечу, что преимущество динамики проявляется в возможности состряпать "наполовину пропеченную" систему. Если я хочу проверить какую-то идею (пара минут на написание кода и встраивание его в одно нужное место и еще пара на просмотр того, как она себя ведет в этом одном месте), то мне обычно как-то не хочется тратить еще 15 минут на то, чтобы умилостивить систему типизации, так как нужный кусок кода (потом) будет встраиваться еще в 100500 мест. Поскольку при моем подходе такие исследования занимают много времени (не сказать, что построение системы из них и состоит: берется требование, придумывается простенькое решение, проверяется как оно ложится на существующую систему и т.д.…), накладные расходы на уговаривание компилятора здесь весьма существенны. Как с этим обстоит дело в правильных языках?

 

Ну и вы так пишете о арифметике в St, будто она не поломала мозг тысячам ни в чем неповинных программистов :) Она там как раз неестественна, тот случай, когда предметную область изуродовали в угоду особенностям синтаксиса. Не могу этого одобрить.

А о чем конкретно речь? Если исключительно о синтаксисе, то я бы сказал, что вся проблема в том, что человечество говорит на двух языках: человеческом и математическом. И именно неестественность математического языка здесь проявляет себя, поэтому приходится выбирать, что лучше: оставить систему простой и человеческой или же "умилостивить" математиков. Я лично очень рад, что создатели Smalltalk-а выбрали первый путь.

Если же разговор о реализации и о том, "как все устроено", то было бы интересно узнать, о каких именно уродствах речь?

 

А все прочие чудесные вещи прекрасно реализуются и в статически-типизированных языках, я о бесконечной точности и. т.п[1]

1. http://www.haskell.org/haskellwiki/Libraries_and_tools/Mathematics

2013/7/23 Nikolay Kleptsov <[hidden email]>

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

Насчет типизации в Dolphin предложили интересное решение - реализация необходимого протокола.

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

Никакая типизация не может защитить от электрика и ошибки ввода-вывода. Поэтому нет, конечно не начисто, но довольно близко. То есть если ваша программа на Haskell (или еще чем-нибудь еще более суровом типа Idris или Agda) скомпилировалась, то скорее всего она будет работать корректно в рамках той модели, которую вы там напрограммировали. Статика позволяет удостовериться, что вы в рамках собственного воображаемого мирка из данных и преобразований над ними делаете все как минимум непротиворечиво. Это дорогого стоит, кстати. Потому что вы можете на этапе компиляции найти архитектурную ошибку. Эдакий лихой способ больше думать о предметной области и меньше о коде, мне нравится.

Разработка "от типов" не исключает мелкие итерации и TDD, просто вы начинаете с описания типов. Они могут меняться, удаляться или появляться со временем, точно так же как в любой другой системе. Причем если вы поменяете тип и у вас все развалится, то оно развалится на этапе проверки типов, а не в рантайме. Еще приятным момент, что развалится везде, где может развалиться в принципе. Не надо рыскать по приложению и искать ошибки типизации в рантайме.

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

А "стандартная" наивная статическая типизация действительно часто мешает больше, чем помогает. Но я говорю о чуть более сложных вещах, о выводе типов, как минимум. Кому нравится писать эти жуткие аннотации? Компилятор их выведет сам (в большей или меньшей степени). А если это не примитивный вывод типов а-ля Go или Typescript, то оно еще и завершаемость проверит и валидность доказуемых высказываний, и еще много чего.

На Хаскеле писать очень приятно, я сам в продакшн ничего не писал, но знаю, что люди пишут с большим успехом (http://bazqux.com, например, написан на нем). Из статически типизированных языков я использую Go и Typescript. Они ближе к "традиционной статике", но умеют выводить типы выражений, что сильно облегчает работу.

Того хаскелиста я помню, но я не ставлю целью никого троллить, я люблю St, но у меня к нему сложное отношение.

Про Новояз послушал бы с удовольствием, не томи :))

---

From: [hidden email]
Date: Tue, 23 Jul 2013 12:01:44 +0400
Subject: [RSUG] Статическая типизация -- это круто?
To: [hidden email]

Много раз слышал/читал про "правильную" типизацию, но не нахожу времени, а самое главное — желания (ну, вот не убедили меня пока, что нужно выискивать время и тратить его на изучение этого подхода). Поэтому несколько глупых вопросов?

 

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

Реально, правильная статическая типизация исключает рантаймовые ошибки начисто? 

Ну, или иначе задам вопрос. "Стандартная" (C/++, Java, C#, Pascal и т.д.) статика мне только мешает. Усилия на раннее "приколачивание" типов и дальнейшее поддержание компилятора в удовлетворенном состоянии не оправдывает себя. По крайней мере, с моим стилем разработки, который, наверное, можно охарактеризовать как "agile", или более конкретно назвать TDD. 

Правильная типизация (Haskell & Co.) — оправдывает себя в реальной жизни? Нужно ли менять для этого "мой" стиль (постепенное выяснение требований к системе в процессе ее разработки и даже эксплуатации — все как Бек прописал когда-то, короче)? 

Когда несколько лет назад нас здесь троллил поклонник Haskell-а, он только пел про то, что все замечательно, но как это замечательно получается — я лично так и не понял. Не найдется ли у вас или других (я знаю, такие есть) обладателей глубоких знаний в области правильных (=функциональных? ну, или любых других, которые "превосходят Smalltalk по гибкости") ЯП желания и времени немного порекламировать (обосновано) эти более продвинутые технологии?

 

Smalltalk в этом отношении не сделал никаких толковых шагов с последнего релиза Strongtalk в 2006 году. (Опережая обвинение в пассивности: я глупый, у меня головы не хватит подхватить разработку Strongtalk)
Ну есть еще Василий Быков с Гиладом Брахой, которые тихонечко пилят Newspeak и что-то робко говорят о Pluggable Typesystems. В общем-то там прорывов тоже не ожидается, хотя работа очень интересная.

По этому поводу есть некоторые мысли, но я их пока не буду оглашать — зарезервирую это место на будущее :)
--
Best regards,


Dennis Schetinin

--

Best regards,

Dennis Schetinin

 

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

TDD это круто, конечно, но не работает. Только истинные титаны духа могут действительно писать 100% кода по принципу test first. Я пробовал раз шесть, наверное, в итоге скатился к "а вот этот класс можно и потестировать, остальное как-нибудь так". Потому что тесты писать трудно. Если у вас правда получается 100% test coverage, я снимаю шляпу и восхищаюсь.

Типы писать не трудно, они не отдельная сущность, а код, который ты само собой тоже пишешь (или его выводит компилятор, что случается чаще). Нормальная система типов позволяет расслабиться и писать тесты только там, где тайпчекер почему-то не может доказать правильность. Именно поэтому именно в языке с невероятно статической типизацией стал возможен QuickCheck[1], откуда он уже и расползся на все прочие языки.

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

Впрочем прототипы как раз можно писать хоть на джаваскрипте.

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

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

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

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

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

1. Интерфейс задокументирован
2. Соответствие кода интерфейсам проверяется компилятором

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

При этом вообще никто не мешает использовать максимально "общие интерфейсы" там, где нужно передавать данные между частями программы, который компилятор проверить не в силах, например общение с другим ПО по http.

Это все прекрасно покрывается TDD (в ее полном воплощении, то есть когда "классику" предваряет построение "сверху-вниз" с помощью моков. Причем на выходе получается не отдельно код и отдельно система типов, а только один сплошной код ("реализация" и "тесты"). Другое дело, что весь потенциал этого подхода до сих пор не раскрыт… Но это отдельный разговор… Как и то, что здесь как раз виднеется "смыкание" обоих подходов: код ведь тоже поддается анализу, и аннотации к коду (разновидностью которых являются типы) тоже могут быть записаны в виде кода…

Но возвращаясь к теме, замечу, что преимущество динамики проявляется в возможности состряпать "наполовину пропеченную" систему. Если я хочу проверить какую-то идею (пара минут на написание кода и встраивание его в одно нужное место и еще пара на просмотр того, как она себя ведет в этом одном месте), то мне обычно как-то не хочется тратить еще 15 минут на то, чтобы умилостивить систему типизации, так как нужный кусок кода (потом) будет встраиваться еще в 100500 мест. Поскольку при моем подходе такие исследования занимают много времени (не сказать, что построение системы из них и состоит: берется требование, придумывается простенькое решение, проверяется как оно ложится на существующую систему и т.д.…), накладные расходы на уговаривание компилятора здесь весьма существенны. Как с этим обстоит дело в правильных языках?

 

Ну и вы так пишете о арифметике в St, будто она не поломала мозг тысячам ни в чем неповинных программистов :) Она там как раз неестественна, тот случай, когда предметную область изуродовали в угоду особенностям синтаксиса. Не могу этого одобрить.

А о чем конкретно речь? Если исключительно о синтаксисе, то я бы сказал, что вся проблема в том, что человечество говорит на двух языках: человеческом и математическом. И именно неестественность математического языка здесь проявляет себя, поэтому приходится выбирать, что лучше: оставить систему простой и человеческой или же "умилостивить" математиков. Я лично очень рад, что создатели Smalltalk-а выбрали первый путь.

Если же разговор о реализации и о том, "как все устроено", то было бы интересно узнать, о каких именно уродствах речь?

 

А все прочие чудесные вещи прекрасно реализуются и в статически-типизированных языках, я о бесконечной точности и. т.п[1]

1. http://www.haskell.org/haskellwiki/Libraries_and_tools/Mathematics

2013/7/23 Nikolay Kleptsov <[hidden email]>

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

Насчет типизации в Dolphin предложили интересное решение - реализация необходимого протокола.

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

Никакая типизация не может защитить от электрика и ошибки ввода-вывода. Поэтому нет, конечно не начисто, но довольно близко. То есть если ваша программа на Haskell (или еще чем-нибудь еще более суровом типа Idris или Agda) скомпилировалась, то скорее всего она будет работать корректно в рамках той модели, которую вы там напрограммировали. Статика позволяет удостовериться, что вы в рамках собственного воображаемого мирка из данных и преобразований над ними делаете все как минимум непротиворечиво. Это дорогого стоит, кстати. Потому что вы можете на этапе компиляции найти архитектурную ошибку. Эдакий лихой способ больше думать о предметной области и меньше о коде, мне нравится.

Разработка "от типов" не исключает мелкие итерации и TDD, просто вы начинаете с описания типов. Они могут меняться, удаляться или появляться со временем, точно так же как в любой другой системе. Причем если вы поменяете тип и у вас все развалится, то оно развалится на этапе проверки типов, а не в рантайме. Еще приятным момент, что развалится везде, где может развалиться в принципе. Не надо рыскать по приложению и искать ошибки типизации в рантайме.

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

А "стандартная" наивная статическая типизация действительно часто мешает больше, чем помогает. Но я говорю о чуть более сложных вещах, о выводе типов, как минимум. Кому нравится писать эти жуткие аннотации? Компилятор их выведет сам (в большей или меньшей степени). А если это не примитивный вывод типов а-ля Go или Typescript, то оно еще и завершаемость проверит и валидность доказуемых высказываний, и еще много чего.

На Хаскеле писать очень приятно, я сам в продакшн ничего не писал, но знаю, что люди пишут с большим успехом (http://bazqux.com, например, написан на нем). Из статически типизированных языков я использую Go и Typescript. Они ближе к "традиционной статике", но умеют выводить типы выражений, что сильно облегчает работу.

Того хаскелиста я помню, но я не ставлю целью никого троллить, я люблю St, но у меня к нему сложное отношение.

Про Новояз послушал бы с удовольствием, не томи :))

---

From: [hidden email]
Date: Tue, 23 Jul 2013 12:01:44 +0400
Subject: [RSUG] Статическая типизация -- это круто?
To: [hidden email]

Много раз слышал/читал про "правильную" типизацию, но не нахожу времени, а самое главное — желания (ну, вот не убедили меня пока, что нужно выискивать время и тратить его на изучение этого подхода). Поэтому несколько глупых вопросов?

 

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

Реально, правильная статическая типизация исключает рантаймовые ошибки начисто? 

Ну, или иначе задам вопрос. "Стандартная" (C/++, Java, C#, Pascal и т.д.) статика мне только мешает. Усилия на раннее "приколачивание" типов и дальнейшее поддержание компилятора в удовлетворенном состоянии не оправдывает себя. По крайней мере, с моим стилем разработки, который, наверное, можно охарактеризовать как "agile", или более конкретно назвать TDD. 

Правильная типизация (Haskell & Co.) — оправдывает себя в реальной жизни? Нужно ли менять для этого "мой" стиль (постепенное выяснение требований к системе в процессе ее разработки и даже эксплуатации — все как Бек прописал когда-то, короче)? 

Когда несколько лет назад нас здесь троллил поклонник Haskell-а, он только пел про то, что все замечательно, но как это замечательно получается — я лично так и не понял. Не найдется ли у вас или других (я знаю, такие есть) обладателей глубоких знаний в области правильных (=функциональных? ну, или любых других, которые "превосходят Smalltalk по гибкости") ЯП желания и времени немного порекламировать (обосновано) эти более продвинутые технологии?

 

Smalltalk в этом отношении не сделал никаких толковых шагов с последнего релиза Strongtalk в 2006 году. (Опережая обвинение в пассивности: я глупый, у меня головы не хватит подхватить разработку Strongtalk)
Ну есть еще Василий Быков с Гиладом Брахой, которые тихонечко пилят Newspeak и что-то робко говорят о Pluggable Typesystems. В общем-то там прорывов тоже не ожидается, хотя работа очень интересная.

По этому поводу есть некоторые мысли, но я их пока не буду оглашать — зарезервирую это место на будущее :)
--
Best regards,


Dennis Schetinin

--

Best regards,

Dennis Schetinin

 

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

Я именно про этот "новый уровень" типизации и спрашиваю: он реально стоит того, чтобы "воевать с компилятором"? 

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

Да, я понимаю, что зато тип — вещь глобальная, в отличие от теста. Один маленький тест (вроде бы) не может ничего гарантировать кроме того, что в нем написано. Но стоит ли "железобетонная" уверенность тех усилий, которые нужны для ее сооружения? Или эти усилия сегодня не так уж и велики?

--

Best regards,

Dennis Schetinin

23 июля 2013 г., 15:33 пользователь Dmitry Matveev <[hidden email]> написал:

>Ну, или иначе задам вопрос. "Стандартная" (C/++, Java, C#, Pascal и т.д.) статика мне только мешает. Усилия на раннее "приколачивание" типов и дальнейшее поддержание компилятора в удовлетворенном состоянии не оправдывает себя. По крайней мере, с моим стилем разработки, который, наверное, можно охарактеризовать как "agile", или более конкретно назвать TDD.

Да, как правило. Как небольшое исключение, в  С++ (за остальные не скажу) можно тоже выделывать интересные вещи с типами, шаблонами, двухэтажными шаблонами, трёхэтажными шаблонами, и т.д. Но это удел особых акробатов, навроде Александреску и последователей. Тут очень верно подмечена "стандартность" таких систем типов. Как правило, сводится всё к указанию типов используемых переменных (в С++11 появилось auto, ура), и типов объектов, с которыми нам предстоит взаимодействовать.

> Правильная типизация (Haskell & Co.) — оправдывает себя в реальной жизни? Нужно ли менять для этого "мой" стиль (постепенное выяснение требований к системе в процессе ее разработки и даже эксплуатации — все как Бек прописал когда-то, короче)? 

В Haskell типизация выходит (точнее вышла, для меня-темноты) на абсолютно новый уровень. Сейчас попытаюсь объяснить, в чём соль.

В Haskell типы охватывают почти все аспекты внутренней структуры программы. Каждая функция имеет свой тип. Вы скажете, "ну и что, у нас вот в C++/Java/Whatever тоже каждая функция/метод имеют свой тип". Но благодаря чистоте Haskell, грубо говоря, всё, что мы можем сделать в функции, отражено в её типе.

Приведу наболевший пример из своей небольшой, но всё же, практики. По работе мне приходилось поддерживать довольно большие проекты (~ 3 млн строк) на С++. Кто только не прикладывал руку к этим тоннам кода за 10+ лет! О качестве того, что там творилось, лучше не говорить. Порой, когда что-то в очередной раз отвалится (или выяснится, что что-то всегда отваливалось, но мы только заметили), на анализ происходящего в портянках на несколько экранов уходили долгие дни, а то и недели. Что только не делалось в одном отдельно взятом методе, куда только оттуда не обращались, чего оттуда только не модифицировали, перетасовывали, преобразовывали, открывали, закрывали, и так далее. Можно долго размышлять о том, почему разработчик(и) сделали именно так, но в конечном итоге это потому что они просто могут!. Они могут писать такой код, и пишут. И он даже работает, до поры-до времени. Компилятор C++ безропотно переводит этот креатив в машинный код и не предоставляет почти никаких средств для контроля и ограничения за происходящим. Глядя на сигнатуру метода или функции, мы не можем ничего о нём сказать. Обратится ли он к объекту А? Модифицирует ли он объект Б? Полезет ли он в Интернет в процессе работы?

Haskell, изящно комбинируя множество идей, за счёт сочетания свой продвинутой системы типов, монад, и чистоты отвечает на эти вопросы. А компилятор не даёт смешивать теплое с мягким.

Если функция, в прототипе которой обозначено, что она в процессе работы обращается (читает) окружение A (Reader A), мы не сможем из неё вызвать функцию, которая в процессе работы что-то сообщает (пишет) в B (Writer B). И обе они гарантированно не будут обращаться к диску или лезть в Интернет.

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

Хотя, с другой стороны, бывает, что с компилятором Haskell приходится повоевать, когда его представления о типах не совпадают с нашими. Не самый приятный процесс :)

Выдыхаю,

Дмитрий

23 июля 2013 г., 12:01 пользователь Dennis Schetinin <[hidden email]> написал:

Много раз слышал/читал про "правильную" типизацию, но не нахожу времени, а самое главное — желания (ну, вот не убедили меня пока, что нужно выискивать время и тратить его на изучение этого подхода). Поэтому несколько глупых вопросов?

 

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

Реально, правильная статическая типизация исключает рантаймовые ошибки начисто? 

Ну, или иначе задам вопрос. "Стандартная" (C/++, Java, C#, Pascal и т.д.) статика мне только мешает. Усилия на раннее "приколачивание" типов и дальнейшее поддержание компилятора в удовлетворенном состоянии не оправдывает себя. По крайней мере, с моим стилем разработки, который, наверное, можно охарактеризовать как "agile", или более конкретно назвать TDD. 

Правильная типизация (Haskell & Co.) — оправдывает себя в реальной жизни? Нужно ли менять для этого "мой" стиль (постепенное выяснение требований к системе в процессе ее разработки и даже эксплуатации — все как Бек прописал когда-то, короче)? 

Когда несколько лет назад нас здесь троллил поклонник Haskell-а, он только пел про то, что все замечательно, но как это замечательно получается — я лично так и не понял. Не найдется ли у вас или других (я знаю, такие есть) обладателей глубоких знаний в области правильных (=функциональных? ну, или любых других, которые "превосходят Smalltalk по гибкости") ЯП желания и времени немного порекламировать (обосновано) эти более продвинутые технологии?

 

Smalltalk в этом отношении не сделал никаких толковых шагов с последнего релиза Strongtalk в 2006 году. (Опережая обвинение в пассивности: я глупый, у меня головы не хватит подхватить разработку Strongtalk)
Ну есть еще Василий Быков с Гиладом Брахой, которые тихонечко пилят Newspeak и что-то робко говорят о Pluggable Typesystems. В общем-то там прорывов тоже не ожидается, хотя работа очень интересная.

По этому поводу есть некоторые мысли, но я их пока не буду оглашать — зарезервирую это место на будущее :)

--

Best regards,

Dennis Schetinin

--

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

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

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

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

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

А вы как дети малые.. :)

Vladimir Musulainen


Вторник, 23 июля 2013, 18:04 +06:00 от Semyon Novikov <[hidden email]>:

Да не приходится на нем писать. В 99% случаев декларацию типа фунции можно спокойно опустить, компилятор ее выведет сам. Но хорошим тоном считается таким образом документировать функции.

Prelude> let f x y = x + y
Prelude> :t f
f :: Num a => a -> a -> a
Prelude> f 1 2
3
Prelude> f 1.2 3.2
4.4

2013/7/23 Dennis Schetinin <chaetal@...>

Ведь, по сути, человеку приходится писать на двух разных языках: на языке "типов"

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

--
Владимир Мусулайнен

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

TDD это круто, конечно, но не работает. Только истинные титаны духа могут действительно писать 100% кода по принципу test first. Я пробовал раз шесть, наверное, в итоге скатился к "а вот этот класс можно и потестировать, остальное как-нибудь так". Потому что тесты писать трудно. Если у вас правда получается 100% test coverage, я снимаю шляпу и восхищаюсь.

Типы писать не трудно, они не отдельная сущность, а код, который ты само собой тоже пишешь (или его выводит компилятор, что случается чаще). Нормальная система типов позволяет расслабиться и писать тесты только там, где тайпчекер почему-то не может доказать правильность. Именно поэтому именно в языке с невероятно статической типизацией стал возможен QuickCheck[1], откуда он уже и расползся на все прочие языки.

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

Впрочем прототипы как раз можно писать хоть на джаваскрипте.

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

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

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

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

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

1. Интерфейс задокументирован
2. Соответствие кода интерфейсам проверяется компилятором

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

При этом вообще никто не мешает использовать максимально "общие интерфейсы" там, где нужно передавать данные между частями программы, который компилятор проверить не в силах, например общение с другим ПО по http.

Это все прекрасно покрывается TDD (в ее полном воплощении, то есть когда "классику" предваряет построение "сверху-вниз" с помощью моков. Причем на выходе получается не отдельно код и отдельно система типов, а только один сплошной код ("реализация" и "тесты"). Другое дело, что весь потенциал этого подхода до сих пор не раскрыт… Но это отдельный разговор… Как и то, что здесь как раз виднеется "смыкание" обоих подходов: код ведь тоже поддается анализу, и аннотации к коду (разновидностью которых являются типы) тоже могут быть записаны в виде кода…

Но возвращаясь к теме, замечу, что преимущество динамики проявляется в возможности состряпать "наполовину пропеченную" систему. Если я хочу проверить какую-то идею (пара минут на написание кода и встраивание его в одно нужное место и еще пара на просмотр того, как она себя ведет в этом одном месте), то мне обычно как-то не хочется тратить еще 15 минут на то, чтобы умилостивить систему типизации, так как нужный кусок кода (потом) будет встраиваться еще в 100500 мест. Поскольку при моем подходе такие исследования занимают много времени (не сказать, что построение системы из них и состоит: берется требование, придумывается простенькое решение, проверяется как оно ложится на существующую систему и т.д.…), накладные расходы на уговаривание компилятора здесь весьма существенны. Как с этим обстоит дело в правильных языках?

 

Ну и вы так пишете о арифметике в St, будто она не поломала мозг тысячам ни в чем неповинных программистов :) Она там как раз неестественна, тот случай, когда предметную область изуродовали в угоду особенностям синтаксиса. Не могу этого одобрить.

А о чем конкретно речь? Если исключительно о синтаксисе, то я бы сказал, что вся проблема в том, что человечество говорит на двух языках: человеческом и математическом. И именно неестественность математического языка здесь проявляет себя, поэтому приходится выбирать, что лучше: оставить систему простой и человеческой или же "умилостивить" математиков. Я лично очень рад, что создатели Smalltalk-а выбрали первый путь.

Если же разговор о реализации и о том, "как все устроено", то было бы интересно узнать, о каких именно уродствах речь?

 

А все прочие чудесные вещи прекрасно реализуются и в статически-типизированных языках, я о бесконечной точности и. т.п[1]

1. http://www.haskell.org/haskellwiki/Libraries_and_tools/Mathematics

2013/7/23 Nikolay Kleptsov <[hidden email]>

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

Насчет типизации в Dolphin предложили интересное решение - реализация необходимого протокола.

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

Никакая типизация не может защитить от электрика и ошибки ввода-вывода. Поэтому нет, конечно не начисто, но довольно близко. То есть если ваша программа на Haskell (или еще чем-нибудь еще более суровом типа Idris или Agda) скомпилировалась, то скорее всего она будет работать корректно в рамках той модели, которую вы там напрограммировали. Статика позволяет удостовериться, что вы в рамках собственного воображаемого мирка из данных и преобразований над ними делаете все как минимум непротиворечиво. Это дорогого стоит, кстати. Потому что вы можете на этапе компиляции найти архитектурную ошибку. Эдакий лихой способ больше думать о предметной области и меньше о коде, мне нравится.

Разработка "от типов" не исключает мелкие итерации и TDD, просто вы начинаете с описания типов. Они могут меняться, удаляться или появляться со временем, точно так же как в любой другой системе. Причем если вы поменяете тип и у вас все развалится, то оно развалится на этапе проверки типов, а не в рантайме. Еще приятным момент, что развалится везде, где может развалиться в принципе. Не надо рыскать по приложению и искать ошибки типизации в рантайме.

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

А "стандартная" наивная статическая типизация действительно часто мешает больше, чем помогает. Но я говорю о чуть более сложных вещах, о выводе типов, как минимум. Кому нравится писать эти жуткие аннотации? Компилятор их выведет сам (в большей или меньшей степени). А если это не примитивный вывод типов а-ля Go или Typescript, то оно еще и завершаемость проверит и валидность доказуемых высказываний, и еще много чего.

На Хаскеле писать очень приятно, я сам в продакшн ничего не писал, но знаю, что люди пишут с большим успехом (http://bazqux.com, например, написан на нем). Из статически типизированных языков я использую Go и Typescript. Они ближе к "традиционной статике", но умеют выводить типы выражений, что сильно облегчает работу.

Того хаскелиста я помню, но я не ставлю целью никого троллить, я люблю St, но у меня к нему сложное отношение.

Про Новояз послушал бы с удовольствием, не томи :))

---

From: [hidden email]
Date: Tue, 23 Jul 2013 12:01:44 +0400
Subject: [RSUG] Статическая типизация -- это круто?
To: [hidden email]

Много раз слышал/читал про "правильную" типизацию, но не нахожу времени, а самое главное — желания (ну, вот не убедили меня пока, что нужно выискивать время и тратить его на изучение этого подхода). Поэтому несколько глупых вопросов?

 

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

Реально, правильная статическая типизация исключает рантаймовые ошибки начисто? 

Ну, или иначе задам вопрос. "Стандартная" (C/++, Java, C#, Pascal и т.д.) статика мне только мешает. Усилия на раннее "приколачивание" типов и дальнейшее поддержание компилятора в удовлетворенном состоянии не оправдывает себя. По крайней мере, с моим стилем разработки, который, наверное, можно охарактеризовать как "agile", или более конкретно назвать TDD. 

Правильная типизация (Haskell & Co.) — оправдывает себя в реальной жизни? Нужно ли менять для этого "мой" стиль (постепенное выяснение требований к системе в процессе ее разработки и даже эксплуатации — все как Бек прописал когда-то, короче)? 

Когда несколько лет назад нас здесь троллил поклонник Haskell-а, он только пел про то, что все замечательно, но как это замечательно получается — я лично так и не понял. Не найдется ли у вас или других (я знаю, такие есть) обладателей глубоких знаний в области правильных (=функциональных? ну, или любых других, которые "превосходят Smalltalk по гибкости") ЯП желания и времени немного порекламировать (обосновано) эти более продвинутые технологии?

 

Smalltalk в этом отношении не сделал никаких толковых шагов с последнего релиза Strongtalk в 2006 году. (Опережая обвинение в пассивности: я глупый, у меня головы не хватит подхватить разработку Strongtalk)
Ну есть еще Василий Быков с Гиладом Брахой, которые тихонечко пилят Newspeak и что-то робко говорят о Pluggable Typesystems. В общем-то там прорывов тоже не ожидается, хотя работа очень интересная.

По этому поводу есть некоторые мысли, но я их пока не буду оглашать — зарезервирую это место на будущее :)
--
Best regards,


Dennis Schetinin

--

Best regards,

Dennis Schetinin

 

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

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

2013/7/23 Dennis Schetinin <[hidden email]>:

> Судя по написанным фразам, вы просто "не уловили" суть TDD. Ни о какой 100%
> test coverage речь не идет. Не надо тестировать все. Не надо тестировать
> некоторые классы. Вообще ничего тестировать не надо. Надо просто писать код,
> который показывает как данная программная подсистема должна работать. А это
> не так сложно. :)
>
> А на самом деле, система вывода сможет мне вывести что-то наподобие этого?
>
> OrderTests >> testRemovesProductFromWarehouseWhenFilled
>     [:warehouse |
>         order := Order on: #amount of: #product.
>         [order fillFrom: warehouse ] should satisfy: [warehouse remove:
> #amount of: #product]
>     ] runScenario
>
> Здесь записано следующее требование: при выполнении заказа (fillFrom:)
> соответствующее количество товара списывается со склада (remove:of:). Пример
> кривоватый, лучше сейчас придумать не успеваю, но, думаю, смысл понятен?
> Такое требование в типах красиво и легко записывается?
>
>

я не эксперт в типах..
но помоему решать это придется введением 2-х типов:
- полный склад
- склад со списанным товаром

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


--
Best regards,
Igor Stasenko.

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

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