Функции против процедур

[Сергей Прохоренко]

А зачем там вообще какие-то переменные?

Затем, что hello world что-то таки печатает куда-то, сам этот процесс таки изменяет состояние чего-то, вот это самое что-то это и есть глобальная переменная.

Вот буквально сегодня смотрел исходники функции printf для микроконтроллера который у нас используется -- там без глобальной переменной не обошлось. Причем по фиксированному адресу. :-)

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

[valexey]

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

[valexey]

Пример где наличие оной глобальной переменной в реализации printf'a (или writeln, или чем там печатается Hello World) явно вылезает: делаем двупоточный Hello World, где каждый поток в цикле печатает оный Hello World – в результате на выходе получим замечательную кащу из символов.

[Илья Ермаков]

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

Правильные слова в целом. Но, как всегда, до того момента, когда цена от реализации начинает перевешивать выгоду от ранних проверок.
Практика показывает, что особый риск, цену поиска и шансы остаться незамеченными имеют как раз простые "низкоуровневые" ошибки, вроде базовых типов и т.п.
Чем высокоуровневее части, тем меньше проблем с динамикой. Вы не ошибётесь с тем, какого типа сообщение Вы посылаете объекту, или какого типа объекты соединяете в единое целое, потому что это - основная семантика, вы о ней думаете.

Я с большим интересом следил за экспериментами Microsoft в области этих верификаций протоколов и т.п., что пробовалось в Sing# и OS Singularity. И при встрече с Владиславом Шершульским дотошно его "потрепал" вопросами, что из этих идей вышло: http://forum.oberoncore.ru/viewtopic.php?f=26&t=2685. Показателен его ответ - "Те средства, которые были введены в языке Sing#, оказались переусложнёнными относительно реальных потребностей".

[valexey]

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

Потому как в промышленности тот же SPARK например востребован. И в отличае от Sig# он уже в боингах.

[Илья Ермаков]

В тему immutable-data, вспомнил про публикацию Вольфганга Века (второй архитектор ББ):
http://narod.ru/disk/6679411001/Weck-Freezable-Lists.pdf.html
An Abstract Data Type for Freezable List and DAGs

[valexey]

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

Ах, да. Язык – С++ (в основном).

[Илья Ермаков]

Кстати, ошибок на уровне базовых типов, построения циклов и так далее, я за последние годы не помню вообще.

Касательно циклов - за последние, как результат опыта.

А касательно типов - они прут обычно при переделках кода.

[valexey]

Использование классов (особенно шаблонных) дает строгую типазацию и качественные проверки типов на этапе компиляции.
Использование typedef'ов дает гибкость при рефакторинге.

[Илья Ермаков]

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

А ощутимость эффекта от статических проверок тем меньше, чем выше уровень семантики мы пытаемся проверить - и тем сложнее это статически проверить.

[Geniepro]

А ощутимость эффекта от статических проверок тем меньше, чем выше уровень семантики мы пытаемся проверить - и тем сложнее это статически проверить.

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

[vlad]

А ощутимость эффекта от статических проверок тем меньше, чем выше уровень семантики мы пытаемся проверить - и тем сложнее это статически проверить.

Согласен. Поэтому динамические языки существуют и конкурируют со статическими: все равно тесты писать

[vlad]

А чем сущность "классического" ООП отличается от Обероновых - в моем представлении это набор концепций, а в вашем?

Классический ООП основан на классах и интерфейсах, содержащих методы (ну и поля). Наиболее яркие примеры: Дельфи, Си++, Ява. Обероновский ООП (кроме Оберона-2 и КП) - на процедурных типах, при том, что процедуры не привязаны к структурным типам данных (записям, объектам, классам, интерфейсам и т.п.). Обероновский ООП имеет не только достоинства, но и недостатки. Но имеет смысл подумать об устранении недостатков, а не о заимствовании классического ООП.

Гхм. ООП в true oberon'e - с нефиговым таким недостатком. По степени возможных граблей может поспорить с жабаскриптом Да, и оно точно так же "не работает" с идеей pure функций.

[Илья Ермаков]

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

Я читал публикации в журнале ФП и кое-где ещё, понимаю, о чём речь.
Впечатление такое: чтобы задействовать весь этот семантический контроль, слишком многое нужно продумывать сразу и до деталей. Это провоцирует достаточно объёмное (семантически) решение - т.е. полное.
Мне не нравится этот подход, потому что я придерживаюсь другого - итерационное уточнение прототипов, от простейших, минимума, с заглушками и т.п.
И если инструмент заставляет сразу думать о деталях ("угадывать будущее"), то в рамках такого итерационного подхода это - минус. Т.е. компактный инвариант, который нужно выделять на первых порах, окажется недостаточно полным, чтобы задействовать типизацию (т.е. начнёшь её задействовать - потребуется доуточнять сразу то, что доуточнять не следует первое время).

[valexey]

Я читал публикации в журнале ФП и кое-где ещё, понимаю, о чём речь.
Впечатление такое: чтобы задействовать весь этот семантический контроль, слишком многое нужно продумывать сразу и до деталей. Это провоцирует достаточно объёмное (семантически) решение - т.е. полное.

Прелесть хаскеля как раз в том, что это не требуется.

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

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