OberonCore

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предваряйте процесс написания кода написанием документации на этот код...

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

Создаётся такое ощущение, что борьба с излишней сложностью постепенно превращается просто в борьбу со сложностью. В оригинале речь шла о некотором компромиссе ("..., but not simpler").

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