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/ |