И в какой-то момент, устав от избыточной сложности, хорошо бы предпочесть искать простые решения. Это не впадание в старческий маразм (я надеюсь), а всего лишь ступенька в эволюционном развитии программиста. Я получал письма от людей, которые рассказывали мне о проектах, развалившихся под собственной сложностью, о проектах, которые просто не были закончены. Дело здесь не только в объёмах работы и её организации. Отчасти, проблема в том, что один человек уже не то что не может отслеживать в одной голове все детали проекта, а просто берётся за голову как свести несводимое, грозящее рухнуть под собственным весом как Колосс на глиняных ногах.
Также я получал письма от людей, которые сделали большие коммерческие проекты на Обероне силами маленьких коллективов. Реализовали поддержку нужных им платформ и фич, взяв за базис систему ETH Oberon. Поскольку проекты их коммерческие - они вовсе не торопятся делиться своими решениями, т.к. затратили на это свои личные средства и ресурсы. Возможно, проблема Оберона ещё и в том, что для него нету мощной поддержки платформы (примерно как AppStore). Но рано или поздно должно появиться стойкое неприятие избыточной сложности. Да, поиск простых решений безусловно требует нетривиального подхода, и сложность такого поиска отнюдь не сопоставима с написанием очередного калькулятора для бизнеса. Но искать такие решения нужно, потому что у нас перед носом который-то на очереди кризис п/о. А знаете как звучит один из базовых тезисов Вирта в отношении современного состояния информатики? "Мощность железа растёт меньшими темпами, чем замедляется софт". И это не голословное высказывание мэтра Вирта, оно весьма подкреплено фактами.
Вам, господа, нужно знать что есть некоторое количество весьма умных людей, которые предпочитают минимальный подход Оберона. То, что их мало не должно вас смущать. Причины этого уже неоднократно анализировались. Оберон сейчас в неблагоприятной конкуренции с другими средствами (ему просто не находится место в умах программистов, оно вытеснено другими средствами), поэтому его развитие сейчас происходит замедленными темпами, поэтому, например, нету юнит-тестирования. Или может быть есть. Я не знаю. Но это вовсе не из позиции, что оно неполезно. Просто не хватает сил потянуть всё сразу. А тут пришёл чел, поковырял среду 15 минут (или попытался открыть бинарь в блокноте) и поставил вечный диагноз. У меня тут книжица лежит "Разработка операционной системы и компилятора. Проект Оберон", выпущенная в ДМК пресс тиражом в 200 экземпляров. Раритет практически. Думаете неинтересная? Да уж поинтереснее сишарпов для чайников за 21 день, поверьте на слово. Какие тут могут быть вопросы по развитию Оберона, если программерское сообщество в массе своей охотно купается в избыточной сложности, ест с неё хлеб, орудует ею и не видит других путей вообще никак. Собственно, есть и подход "Я не верю в простое решение сложных задач. Сложные задачи требуют сложных средств" (Жан Ишбиа, автор языка Ада). И можно поспорить, существует ли вообще простое решение. А кто-то, устав от гонки в никуда, просто уходит из программирования вообще.
А то тут говорили много хороших слов про язык Си. Да, прекрасная затея, пользуемся. Но багрепортим. Не доверяется как-то продукту, который не был бы вылизан десятками умных голов и сотнями бетатестеров за годы и годы. Где здесь есть ниша для простого подхода? А если надо заточить кодогенерацию под другой проц? Уже надо переписать тысячи строк кода, и снова бетатестирование и прочее. Оберон-компиляторы, как правило, дают не очень хороший код. Их просто не вылизывают до такой степени, это требует лет и лет. Но зато заточить под новый кодогенератор проще. Это не оправдание компиляторов Оберона. Это не повод делать плохие сишные компилеры. Это пример того как, пожертвовав избыточной сложностью, получить одни достоинства за счёт отказа от других. Это повод искать как упростить сам подход к кодогенерации. Например, разработкой оптимизированных под это дело железных процессоров. Чтобы не пришлось по-комсомольски героически решать ненужные задачи. А кто построил плохие процессоры? Дяди, которым надо было делать быстрые деньги. И потом тогда никто не знал как лучше проектировать процессоры. Но теперь ведь знают. Но продолжают городить thumb поверх arm, и закончится это тем самым, до чего дошла архитектура i8086. Т.е. избыточностью, рудиментарностью и т.п. Но прощаем. Арму прощаем, он ещё молод. Оберону прощаем, он всё ещё так мал. Сишарпу не прощаем, ему двигаться почти некуда. Не будет надмножеств сишарпа, как есть C++ и Objective C над Си. Не будет никогда и универсальности. Не будет и энтузиастов, которые возьмутся облагораживать этот язык просто за то, что он хорош. Неподъёмное дело.
Избыточная концептуальная перегруженность (в т.ч. и в языках программирования) воспринимается совершенно с младенческим восторгом. Слышь, во что за штука такая, да! Улёт! Но я могу легко объяснить своей племяннице что такое модуль, но затрудняюсь ей объяснить что такое сборка (коллекция классов), экземпляры классов и прочие This. И это только маленький пример того, как наслоение таких моментов на бедный ум девелопера приводит к появлению клана избранных-очень умных-элитных, куда простым смертным зась, а как второе - к появлению кучи глючащего и странно работающего софта, ошибки в котором скрыты годами и пылью лет. И какие бы решения не предлагала промышленность - чаще они уводят от сути или незавуалированно являются теми же яйцами в профиль, но под другим "фирменным" соусом, т.е. практическое средство конкурентной борьбы за умы. И появляется догма "Нет синтаксиса, удобнее сишного, и C# пророк его...", которая на ура хавается благодарным сообществом из-за новых (хорошо забытых старых) плюшек.
И в то же время в Оберон-среде можно найти аналог (или по крайней мере разработать) любой из фирменных плюшек. Как языковых, так и среды.
Не останавливайтесь на сказанных мной словах, я могу иметь понимание, но быть в затруднении передать его программистам, которые с молоком матери всосали Си [C++, C#, Java, Python и т.д.]-парадигму со всеми её достоинствами и недостатками. И если о достоинствах принято кричать на все углах, то мы с вами как честные люди должны поднять вопрос об их недостатках, не ограничиваясь тёплым и уютным кружком задач, с которых мы едим свой кусок хлебца.
Я наверно повторюсь, но как-то больше веры людям, разработавшим за год или пару лет язык, компилятор и ОС, а не к поддержаторам-калькуляторов-на-плаву. Пусть такая формулировка даже кого-то задевает. В мире, полном конкуренции, предполагается конкурентная борьба, а она закономерно стимулирует чувство соперничества. Но если мы сейчас опустимся до пиписек, то диалог наш будет происходить малость неконструктивно и на эмоциях. Впрочем, кому-то - решать уютные задачи по калькуляторам. Но это не значит, что так могут жить (и работать) все.
Но если как бы понимаешь что такое модульность в Обероне - откуда такие восторги по поводу dependency injection? Которая реализуема с помощью этой модульности аж на ура и безо всяких усилий, т.к. прямо поощряется идеологией Оберона.Сообщение от ZEK
И даже более того - данная возможность была заложена неодобряемым вами г-ном Виртом в ОС Оберон ~25 лет назад! Ещё задолго до появления таких монстров как .NET и Java.
Вирт просто пытается искать и утверждать новые подходы к отладке, что ему простительно как опытному профессору. Он говорит "я бы пошагово сборщик мусора не отладил". А ты бы отладил? И многопоточные риэлтаймовые программы тоже? С учётом всех взаимовлияний и зависимостей?
А INT3 такие могут быть полезны не только для отладки, но и для многих других применений, например, для профилирования кода.
Может быть я просто хочу бурной и активной публичной коллективной деятельности по облагораживанию Спектрума.а прозвучало это так, как будто вы тут один что-то делаете, а остальные вообще здесь лишниеВо оптимист, да?
P.S. Ответил сегодня сколько успел, буду отвечать позже, если не утону в мессагах.
Ответить с цитированием
