?

Log in

принцип наименьшего сюрприза - язык, на котором не говорят [entries|archive|friends|userinfo]
beroal

[ website | personal website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]
[ tags | journal tags ]

принцип наименьшего сюрприза [Jan. 23rd, 2017|08:11 am]
beroal
[Tags|, , ]

Этот принцип имеет своё место в программировании. Это место скромное. Его следует использовать при проектировании интерфейсов пользователя (ип) для новичков и эпизодических пользователей. Его не стоит использовать при проектировании ипов для опытных пользователей. Подразумевается, что опытный пользователь учил ип, то есть все «сюрпризы» он уже знает. Этот принцип ни в коем случае нельзя использовать при проектировании япов. Он просто не даёт япам развиваться. Любая глубокая концепция идёт вразрез с стереотипами среднего программиста.
LinkReply

Comments:
[User Picture]From: juan_gandhi
2017-01-23 06:39 am (UTC)
Справедливо. Хорошо изложено. Спасибо.
(Reply) (Thread)
[User Picture]From: nivanych
2017-01-23 07:58 am (UTC)
> Этот принцип ни в коем случае
> нельзя использовать при проектировании япов.

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

> Он просто не даёт япам развиваться

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

База того же хаскеля совершенно без сюрпризов. Ну или можно взять что-то ещё попроще, скажем, ML.

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

Про окамл знаю меньше, но насколько вижу, там что-то подобное тоже присутствует. Знаю ещё, что они там в бОльшей степени стараются быть простыми и предсказуемыми. И не надо говорить, что именно из-за этого омамл меньше распостранён и мало развивается.
(Reply) (Thread)
[User Picture]From: beroal
2017-01-23 08:13 am (UTC)
«База того же хаскеля совершенно без сюрпризов.»
Это для тебя она без сюрпризов. 😉
(Reply) (Parent) (Thread)
[User Picture]From: nivanych
2017-01-23 08:17 am (UTC)
Я же специально сделал оговорку с самого начала насчёт хорошей теории...
(Reply) (Parent) (Thread)
[User Picture]From: beroal
2017-01-23 02:12 pm (UTC)
Средний программист боится теории как огня.
(Reply) (Parent) (Thread)
[User Picture]From: nivanych
2017-01-23 02:53 pm (UTC)
Иными словами, сказанное следует воспринимать с позиции условного "среднего программиста"? сферического в вакууме

Edited at 2017-01-23 02:54 pm (UTC)
(Reply) (Parent) (Thread)
[User Picture]From: beroal
2017-01-23 03:08 pm (UTC)
Сказанное следует понимать так, что «сюрприз» — это сюрприз с точки зрения среднего программиста. По-моему, в основном они продвигают этот принцип. Хочешь сказать, что ты тоже его продвигаешь?
(Reply) (Parent) (Thread)
[User Picture]From: nivanych
2017-01-23 03:21 pm (UTC)
Скажем так, я с ним полностью согласен.
Просто я не считал, что противоречит развитию языка.
Это теоретически.
Но _практически_ очень часто всегда получается так, что развитие языка происходит сколько-то "хаотически", очень не всегда получая простоту и предсказуемость.
Я считаю, что этого можно избежать при развитии, хоть и очень сложно.

Собственно, тут можно провести прямую аналогию с готовой архитектурой приложения и очень красиво выстроенной программой.
И ситуацией, когда ВНЕЗАПНО начинают меняться/добавляться требования.
Не всегда их удаётся красиво и прямо вписать в текущую архитектуру (она и не предназначалась), а расширить архитектуру так, чтоб она и красивой оставалась, требования новые учитывала и всё нахер переписывать не пришлось, это часто сложная задача.

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

Edited at 2017-01-23 03:22 pm (UTC)
(Reply) (Parent) (Thread)
[User Picture]From: nivanych
2017-01-23 08:19 am (UTC)
Ну хорошо, можно попробовать в этой связи окамл порассматривать, он тут более лучший™ пример, просто я с ним мало знаком.
(Reply) (Parent) (Thread)