OberonCore
https://forum.oberoncore.ru/

Дейкстра: борьба со сложностью и Оберон
https://forum.oberoncore.ru/viewtopic.php?f=86&t=4646
Страница 1 из 3

Автор:  Иван Кузьмицкий [ Среда, 27 Ноябрь, 2013 13:17 ]
Заголовок сообщения:  Дейкстра: борьба со сложностью и Оберон

Нашёл у Дейкстры хорошую формулу для забарывания сложности, привожу перевод:
Цитата:
формулирование точных определений регистрирует зарождающуюся сложность на ранних этапах (precise definition as a design principle acts as an indispensable early-warning system for complexity inadvertently creeping in)
В связи с этим возникла мысль - а не является ли строгий и минималистичный дизайн формальной системы Оберона наилучшим средством для такой регистрации? Ведь чем проще и понятнее (не примитивнее!) формальный аппарат, тем легче его применять, не отвлекаясь от проблемной области.

Автор:  Jordan [ Среда, 27 Ноябрь, 2013 14:13 ]
Заголовок сообщения:  Re: Дейкстра: борьба со сложностью и Оберон

Проще для чего?

Проще формулируются задачи на обероне? Проще пишутся структуры данных и алгоритмы к ним? Проще применять уже написанный код?

Чем проще то? В поддержке кода? В написании компилятора и переноса на другие платформы?

Автор:  Иван Кузьмицкий [ Среда, 27 Ноябрь, 2013 14:16 ]
Заголовок сообщения:  Re: Дейкстра: борьба со сложностью и Оберон

Проще для регистрации сложности на ранних этапах. Написано же.

Автор:  Jordan [ Среда, 27 Ноябрь, 2013 14:33 ]
Заголовок сообщения:  Re: Дейкстра: борьба со сложностью и Оберон

Иван Кузьмицкий писал(а):
Проще для регистрации сложности на ранних этапах. Написано же.


Регистрации чего? Есть проект, продумана архитектура. Спускаемся ниже, продуманы модули взаимодействия, ещё ниже продуманы структуры данных и алгоритмы. После наступает реализация. именно при реализации на обероне, вдруг увидят, что проект то не прост? Вся прелюдия до, бессмысленна?

Автор:  Иван Кузьмицкий [ Среда, 27 Ноябрь, 2013 14:34 ]
Заголовок сообщения:  Re: Дейкстра: борьба со сложностью и Оберон

Вы можете продумать архитектуру от начала и до конца, не приступая к программированию? Ну поздравляю, вы окончательно победили сложность, можно выписывать Нобелевскую премию :)

P.S. А если при реализации увидят, что "проект не прост", это говорит только об одном - архитектура не продумана, как ложно утверждалось в начале.

Автор:  Jordan [ Среда, 27 Ноябрь, 2013 14:40 ]
Заголовок сообщения:  Re: Дейкстра: борьба со сложностью и Оберон

Нобелевскую мне, нобелевскую! :)

Я и не спорю, что программировать сложно.

Автор:  Jordan [ Среда, 27 Ноябрь, 2013 14:43 ]
Заголовок сообщения:  Re: Дейкстра: борьба со сложностью и Оберон

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

Автор:  Иван Кузьмицкий [ Среда, 27 Ноябрь, 2013 14:50 ]
Заголовок сообщения:  Re: Дейкстра: борьба со сложностью и Оберон

Ну вот, теперь встаёт вопрос - как бороться со сложностью? Мы не знаем, что такое сложность, но у нас зато есть формальные знаковые системы (языки программирования) и эффективное воплощение формальной системы (компьютер).

Если программист при решении задачи пытается выразить проблемы с помощью некоего формализма, то можно подумать, что чем больше всяких ништяков напихано в этот формализм, тем круче. Замыканий, итераторов и дженериков нет в Обероне, но значит ли это, что формализм Оберона не подходит для выражения проблем? Может так оказаться, что проблема в самом программисте, который привык итераторами мерять всё подряд.

P.S. Ну, Си был создан только для избавления от мучений на ассемблере. Так сложилось. А Оберон - тщательно спроектирован, в чём и отличие.

Автор:  Jordan [ Среда, 27 Ноябрь, 2013 15:03 ]
Заголовок сообщения:  Re: Дейкстра: борьба со сложностью и Оберон

Иван Кузьмицкий писал(а):
Замыканий, итераторов и дженериков нет в Обероне, но значит ли это, что формализм Оберона не подходит для выражения проблем? Может так оказаться, что проблема в самом программисте, который привык итераторами мерять всё подряд.


Может, всё может. Конечно, подходит. Проблема в нежелании дублировать код? Объясните, чем лучше написание той же сортировки, только из за того, что типы разные, задача не изменилась. Всё те же куличи и песок, формачка другая.

Автор:  Jordan [ Среда, 27 Ноябрь, 2013 15:06 ]
Заголовок сообщения:  Re: Дейкстра: борьба со сложностью и Оберон

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


Каждый ништяк служит какой то цели. Тот же for и while. Тема ништяков в языках обширна.

Автор:  Иван Кузьмицкий [ Среда, 27 Ноябрь, 2013 15:11 ]
Заголовок сообщения:  Re: Дейкстра: борьба со сложностью и Оберон

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

А если не до бесконечности, тогда надо знать предел. Кто его знает? Дейкстра не знает, он откровенно сказал. Значит, будем опираться на практический опыт, запихивая в какой-нить питон всё новые и новые отработки.

Автор:  Jordan [ Среда, 27 Ноябрь, 2013 15:20 ]
Заголовок сообщения:  Re: Дейкстра: борьба со сложностью и Оберон

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


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

Автор:  Иван Кузьмицкий [ Среда, 27 Ноябрь, 2013 17:56 ]
Заголовок сообщения:  Re: Дейкстра: борьба со сложностью и Оберон

Jordan писал(а):
Как пример разрешение экрана, оно может быть больше или меньше, но обычно в гуи библиотеках используют менеджер позиции, который сам их расставляет. Есть одна абстракция создать, что то. С отсутствием такого менеджера, каждый визуальный объект, на разных разрешениях будет смотреться меньше или больше. И для разных разрешения требуется ручная подгонка.
Ну да, забарывание таких моментов часто делается сугубо вручную, путём изготовления растров под каждое разрешение экрана.

Автор:  Jordan [ Среда, 27 Ноябрь, 2013 18:01 ]
Заголовок сообщения:  Re: Дейкстра: борьба со сложностью и Оберон

Не то. Я о простых кнопках, а не картинках. Меняется маcштаб кнопок, диалогов и т.д Размер шрифта с последующей расстановкой элементов.

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

Автор:  Иван Кузьмицкий [ Среда, 27 Ноябрь, 2013 18:29 ]
Заголовок сообщения:  Re: Дейкстра: борьба со сложностью и Оберон

Это не я предлагаю, а гугл :) А всё остальное давно уже применяется.

Автор:  Иван Кузьмицкий [ Среда, 27 Ноябрь, 2013 22:35 ]
Заголовок сообщения:  Re: Дейкстра: борьба со сложностью и Оберон

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

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

Автор:  Евгений Темиргалеев [ Пятница, 29 Ноябрь, 2013 21:38 ]
Заголовок сообщения:  Re: Дейкстра: борьба со сложностью и Оберон

Иван Кузьмицкий писал(а):
Нашёл у Дейкстры хорошую формулу для забарывания сложности, привожу перевод:
Цитата:
формулирование точных определений регистрирует зарождающуюся сложность на ранних этапах (precise definition as a design principle acts as an indispensable early-warning system for complexity inadvertently creeping in)
Предваряйте процесс написания кода написанием документации на этот код...

Автор:  adva [ Суббота, 30 Ноябрь, 2013 09:26 ]
Заголовок сообщения:  Re: Дейкстра: борьба со сложностью и Оберон

По моим субъективным ощущениям, если начинать писать код с комментариев, то затем значительно легче его писать (по сути это уже и есть обдумывание/проектирование кода)

Автор:  igor [ Суббота, 30 Ноябрь, 2013 12:47 ]
Заголовок сообщения:  Re: Дейкстра: борьба со сложностью и Оберон

Иван Кузьмицкий писал(а):
Ну вот, теперь встаёт вопрос - как бороться со сложностью? Мы не знаем, что такое сложность, но у нас зато есть формальные знаковые системы (языки программирования) и эффективное воплощение формальной системы (компьютер).
Создаётся такое ощущение, что борьба с излишней сложностью постепенно превращается просто в борьбу со сложностью. В оригинале речь шла о некотором компромиссе ("..., but not simpler").

Автор:  Иван Кузьмицкий [ Суббота, 30 Ноябрь, 2013 13:10 ]
Заголовок сообщения:  Re: Дейкстра: борьба со сложностью и Оберон

igor писал(а):
Иван Кузьмицкий писал(а):
Ну вот, теперь встаёт вопрос - как бороться со сложностью? Мы не знаем, что такое сложность, но у нас зато есть формальные знаковые системы (языки программирования) и эффективное воплощение формальной системы (компьютер).
Создаётся такое ощущение, что борьба с излишней сложностью постепенно превращается просто в борьбу со сложностью. В оригинале речь шла о некотором компромиссе ("..., but not simpler").
Дейкстра утверждает, что ни концепции сложности, ни полезной теории сложности нет. Это значит, что мы не можем формально сказать, где сложность излишняя, а где не излишняя. Стало быть, надо уходить от складывающихся ощущений и бесполезных чувственных образов в сторону формализации. И только оттуда начинать рассуждать про сложность.

Страница 1 из 3 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/