Из пустого в порожнее, или Какой язык лучше?

Владимир Малюх>Использовали в качестве инструмента TopSpeed, если кто такой помнит.

Почему "помнит"?
По-моему, дела у них относительно неплохи в своей нише.
Видел я тут как-то образцы кода генерируемого, кажется, TopSpeed Oberon'ом, так просто в восторге был
Даже скачать собирался, да ссылку где-то заиграл...

ВладимирљМалюх>>...а уж потом перебрались на С, так как на ПК для других языков инструментарий был послабее...

Zeus>Во! Решающий фактор чаще всего.

Естественно!
Как уже даже тут отмечалось неоднократно, профессионалу всё равно на чём писать. Лишь бы было удобно и экономно. А уж в эти понятия входит много чего... Если бы у MSVC был IDE как у BC++3.1, а у Delphi как у VisualStudio 5 и выше, то я бы чаще работал бы на Delphi.

Но при этом бы всё равно считал, что как язык C++ в целом лучше, чем ObjectPascal

А что Forth лучше и того и другого. Вот только IDE совсем нет... Потому и не программим на нём.

Хотя, всё от задач зависит.

Вон, на C++ я уже года полтора не программил, т.к. всё Web да Web... А тут вовсе никакого IDE. Far+colorer вот и весь IDE

MiG31>Хе, вот тема разгорелась



MiG31>Тот, который не понимает COM, для меня не имеет места в професии.

Ну зачем COM, к примеру, при программировании микроконтроллеров?

Эх.. Не хотел ввязываться, но пробрало..
Я скорее программист по неволе - в основном пишу софт для своих(чужих) железок. Но иногда приходится и "чистый" софт делать. Пишу на PAS в разных вариациях (BP/OP) c ASM вставками.
Начинал с ASMа и "васика" - ну небыло для микро-80/РК-86 других компиляторов тогда. Потом встал вопрос о переходе на что получше. Главный критерий отбора - надежность программы. Попробовал C и TP. Остановился на последнем. Причины - возможности в принципе равные, PAS более строгий язык (многие ошибки отлавливаются на этапе компиляции), удобная среда (TP4, TP5). Впечатление от C - навороченный(испоганенный) макроассемблер.

Кстати, на борту у нас довольно долго стоял софт написанный на Модуле-2 (клон PAS таки ). Недавно пришлось переписать на C. Народ совсем не в восторге. Проблем прибавилось.

А по поводу невозможности написания драйвера на PAS.. Основная сложность - адаптировать DDK. Остальное - дело техники. И трудности таки искуственные. В качестве контрпримера можно предложить написать аналогичные вещи для Кроноса на C. Для тех кто не в курсе - был такой монстрик отечественный, система команд заточена под модулу/оберон, операционка на ней-же написана.

А вааще, ИМХО, первая часть топика очень точно отражает суть данного вопроса..

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

Хе, вот тема разгорелась
Почему-то часто начинаю темы, в которых бушуют флеймы

И так, по теме. Может, я слишком абстрактно выражаюсь, а может и просто, но вы слишком абстрактно думаете, но все-таки вы меня не правильно поняли.
Безусловно, профессионалу все равно на чем он пишет. Но, кроме обязанностей, есть и вкусы, предпочитания. И по моему мнению, настоящий проффи ПРЕДПОЧИТАЕТ писать на c++ (именно на ++). Кстати, 2,5 года я проработал в компании, где писали исключительно на VB4 (при том - 16 бит. версия). Ушел из этой компании ради своих убеждений:
1. Среди руководства и коллег была ниская техническая грамотность и страх перед новом. Софт мы писали в основном экономический. Среди версий софта была и т.н. "сетевая", где доступ к базе был файловым. Все это работало, кончено, но мне ОЧЕНЬ не нравилось как оно было сделано. Я дал предложение сделать нормальную клиент-серверскую систему, где транзакции проходили бы через TCP или UDP. Меня назвали "фантазером" и посоветовали не вмешиватся не в свои деля. Я и не стал.
2. Мне надоело писать на VB. Знаете, в этом языке нет целочисленного типа без знака. И когда резльтат какой-нибудь API функции - целое без знака, приходится делать убогие вещи, чтоб разобратся Конечно, иногда мне было просто необходимо писать на C. Скажем, модуль для комуникации с сетью терминалами для чтения безконтактных ID карт. И даже тогда они настаивали написать это на VB!!!
Однажды я поставил вопрос о введении c++ как основного языка для разработки софта фирмы. Они смотрели на меня как вампиры Начали бормотать какие-то глупости о снижении производительности и качества, о потери времени на переучивание и т.д. Они говорили, а я смотрел на птички через окно.

Скоро моя деятельность в этой компании перекратилась.


О COM-е. Может, следовало назвать "компонентный подход" как целое. Но так или иначе - все комп. технологии имеют как база 2 осн. принцыпа - модульность ПО и полиморфизм. Чистый COM - это небольшая надстройка этой базы. Чтоб его понять, надо думать одновременно на 2-х уровнях: системном и высшим, абстрактном. Тот, который не понимает COM, для меня не имеет места в професии.

2KRoN:

Не зачем. Но код для микроконтроллеров составляет около 0.001% из всего кода. Поетому КОБОЛ столь распространен

Zeus>КРоН уже показал, что он не знает Delphi и даже Паксаль (во всяком случае настолько, чтобы компетентно сравнивать), да и Владимир Малюх, при всем моем к нему уважении, тоже.

Разве я показал это?
Я просто сказал, что я не знаю их до тонкостей, как, скажем C++, но программировать на них приходилось, в чужих программах разбираться тоже, так что представление о языке и его возможностях имею хорошие. Просто я пишу, что знаю язык только в тех случаях, когда его действительно знаю.

Zeus>Теперь о частностях. Я-то как раз начинал с Си (опуская Asm, Basic и пр.), и уже потом перешел на Паскаль (в основном).

Очень редкая группа программистов, поверь моему опыту Тех, кто с Си переходил потом на Паскаль. По пальцам можно пересчитать. Даже, пожалуй, одной руки хватит

Zeus>Вообще, при первом знакомстве с чем-либо (даже с музыкой, например) всегда невольно сравниваешь с тем, что уже знаешь, и поскольку последнее ближе, сравнение часто не в пользу новинки. Надо прочувствовать это, чтобы сравнивать.

Может поэтому я прочувствовал Си, что перешёл на него после Паскаля?

Zeus>Кстати, Elite для РС есть (времен 286), но спецы говорят (я сам в ней не очень), что она похуже. Интересующимся могу намылить, хотя, наверное, видели все же.

Есть почти буквальный перенос со Speccy на PC, так и называется Elite. Это времён не 286, а XT. Но вот он был весьма нелогичен и неинтересен. А вот потом вышла Elite-2: - Frontier. Вот это был хит. Новые возможности, 100% дух Элиты... Кстати, зайди по этой ссылочке - там и скачать можно. А об уровне игрушки, хоть и реализация в ужасной 320x200x256, можно сказать хотя бы по тому, что последний раз я в неё много играла всего пару лет назад, а поигрывал даже в конце прошлого года А вот потом... Elite-3: First Encounter была дальнейшим развитием Frontier'а, но была написана под кривой Борландовский DOS-экстендер, не шедший под Win95, и потому совсем не прижилась И с тех пор ничего подобного точно не было

Хотя сейчас есть определённые надежды на X-tention

>>...Отсюда, как следствие, иделологические возможности и невозможности инструментов...

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

Одно только слово ПРОИЗВОДИТЕЛЬНОСТЬ. Накладухи в системах с "автоматической коробкой" много, по определению больше чем в "ручных".

Zeus>Все-таки хорошая среда - это гибкая среда, а с этим у Delphi все в порядке (про VB ничего не могу сказать - слишком поверхностно знаю).

Функционально они - аналоги, разве что VB более интегрирован в винды. Мы их обоих тщательно изучали, когда выбирали платформу, на какой API строить к своей системе. В результате пришлось откзаться от обеох (оговорюсь - не только по техническим причинам, но и например по рекламным).

Zeus>Продолжая аллегорию, никто не заставляет ездить с автоматической коробкой. При желании можно и вообще без нее обойтись.

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

>>TP5). Впечатление от C - навороченный(испоганенный) макроассемблер.

Все дело в том, что на С пишешь как хочешь/умеешь. Если стиль программирования плохой, то и на паскале ужасно получиться.
А проблема у паскаля одна - выкручивание рук.
В чем С и хорош - что он настраиваемый на любой стиль программирования.
паскалистам могу порекомендовать начинать с
#define { begin
#define } end



MABP>Кстати, на борту у нас довольно долго стоял софт написанный на Модуле-2 (клон PAS таки ). Недавно пришлось переписать на C. Народ совсем не в восторге. Проблем прибавилось.

Мне приходиться наоборот. В итоге - на 30% меньше текста и кода.

=KRoN=>Ну, во-первых, понятие читабельность я применяю к человеку мастерски владеющему языком. И чем короче и лаконичнее конструкции, тем читабельность программ выше. Не нужно говорить, что i++ читается хуже, чем i:=i+1 или inc(i). Просто, значит, ты плохо владеешь языком. Да, английский язык в целом проще русского, но какой из них выразительнее?

Тут не все так просто. Сложно сказать, что читается само по себе легче, i++ или inc(i), begin или {. По большому счету, одинаково. На мой вкус, скобочки даже похуже - теряются среди текста иногда. Но дело в другом. Гибкие сишные нотации провоцируют навороченные конструкции, которые в сумме плохо читаются. Мало в Си строгости, именно это, я бы сказал, в основном мне не нравится.
Кстати, прямой зависимости между краткостью записи и читабельностью нет. Когда как...

=KRoN=>Да, для дилетанта конструкция Forth'а типа

=KRoN=>vXY @ POINT + @ vSET!

=KRoN=>выглядит куда страшнее, чем что-то типа

=KRoN=>(point*) point_ptr=&vXY;
=KRoN=>point_ptr=point_ptr+1;
=KRoN=>point p=*point_ptr;

=KRoN=>но для профессионала первый фрагмент более информативен, чем второй.

Дилетанту вообще иногда к компьютеру подходить боязно Надо спрашивать только тех, кто понимает и то, и это. Только они могут оценить.

=KRoN=>Так что об удобочитаемости - это ещё аопрос для кого.
=KRoN=>Мы же, кажется, говорим о профессионалах.

Ну да, именно. Согласен, что читабельность программы очень сильно зависит от культуры и профессионализма программиста, но язык всегда оставляет отпечаток. В общем, по моей практике, /при прочих равных паскалевские программы читаются заметно легче сишных.
Кстати, о комментариях. Совсем недавно научился наконец (т.е. заставил себя) писать комментарии почти одновременно с написанием кода. Все-таки ужжасно помогает. Хоть и кажется поначалу, что и так все понятно, а времени требует прилично.
Помнится, еще в школьные годы на каком-то конкурсе институтские преподы меня чуть не завалили, когда я им с гордостью вывалил распечатку 10 тыс. строк кода своей программы (на ассемблере). Они тут же спросили: а где же здесь комментарии?! Ну а я, с понтами, мол, я тут все наизусть знаю (в общем, так и было...) Короче, отмазался, только сказав, что в 20 КБ памяти не влезло. Тогда какой-то профессор сказал, что надо увольнять как программистов, не пишущих комментарии, так и тех, кто комментирует каждую строчку. Я только усмехнулся, но сейчас полностью согласен. С оговоркой, что это для программиста, пишущего для компании, а не только для себя. Чтобы себя уволить - это надо нехилым мужеством обладать перед самим собой.

Zeus>>Так что коли не знаешь до тонкостей, лучше в тонкостях и не сравнивать. А в общем, т.е. по существу, обсуждения языков не было.

=KRoN=>А тонкости я и не сравниваю. Я вижу большую разницу уже на глобальном уровне

Однако обсуждения (а не выкриков) по этому поводу я не заметил (собственно, ко всем относится).

Zeus>>Знаю, зато это элита

=KRoN=>Сложный вопрос. Не могу скзать про тебя, т.к. тебя не знаю с этой стороны, но вот все остальные, с кем сталкивался... Сущие теоретики. Могут месяц рожать алгоритм программы, подгоняя его под имеющийся инструментарий, потом пол-года писать, а в итоге однажды получить шок от того, что кто-то то же самое, но на более подходящем инструменте кто-то делает за неделю.

Ну, это проблемы того, кто не знает подходящих инструментов. Будет учиться.

Zeus>>Вообще, показательно, что многие серьезные ученые брезгуют (sic!) Си (вот Дейкстра например). А ученых я уважаю как-то больше, чем чистых практиков. Такой уж у меня характер.

=KRoN=>Блин, честное слово, я про теоретиков в предыдущем абзаце писал не заглядывая сюда Так я, знаешь, люблю, чтобы ехало. Быстро, надёжно, красиво. А не чтобы с шашечками. Профессиональный программист-теоретик... Гм. Звучит как "теоретик физкультуры", что ли...

А! Хочешь, все-таки, чтобы красиво ехало? И быстро, и надежно? Тогда продется все-таки порожать алгоритм, возможно и в муках.
А "профессиональных программистов-теоретиков" просто не бывают. Как бы это сказать... Адекватного русского термина для computer science вообще нет. Потому я и выразился наиболее обще: ученый. Т.е. человек как минимум с высшим и притом не-инженерным образованием в данной области. Все-такие люди лучше глубины понимают и вообще делают... как бы это сказать... красивее. А я люблю красоту саму по себе. Могу, например, исправлять ошибочки и просто мелочи в уже сданной программе, которая (в исправленном виде) так и останется лежать у меня...
К слову - не чтоб похвастаться, а для подтверждения - очень многие, как пользователи, так и программисты, отмечают именно вылизанность и продуманность моих программ (равно как и интерфейса). Именно потому, что я проектирую зачастую дольше, чем программирую.
Да и, впрочем, без "теоретиков физкультуры" настоящего спортсмена не получится. Так, любительство.

Zeus>>Да и по языкам ясно чувствуется, что Паскаль создан ученым, а Си - практиком.

=KRoN=>Тебе нужно программировать или теоретизировать?
=KRoN=>Кстати, для теоретизации существуют и более удачные языки, чем Паскаль. Даже у того же Вирта.

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

Zeus>>Наоборот, современное проектирование (опять же, языки - лишь частный пример) - это скорее искусство [само]ограничений, чем налепливание побрякушек...

=KRoN=>Ой-йё...
=KRoN=>Ты в каком мире живёшь?

В самом что ни на есть настоящем.

=KRoN=>Если бы у MSVC был IDE как у BC++3.1, а у Delphi как у VisualStudio 5 и выше, то я бы чаще работал бы на Delphi...

Так это не Delphi было бы. Delphi - это в первую очередь именно IDE, и именно этим она мне нравится (не во всем, конечно, но в общем, идеологически).

=KRoN=>Но при этом бы всё равно считал, что как язык C++ в целом лучше, чем ObjectPascal.

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

=KRoN=>Вон, на C++ я уже года полтора не программил, т.к. всё Web да Web... А тут вовсе никакого IDE. Far+colorer вот и весь IDE.

Ага, а мне в свое время хватало экранного редактора Ассемблера ZEUS )

MiG31>...Начали бормотать какие-то глупости о снижении производительности и качества, о потери времени на переучивание и т.д. Они говорили, а я смотрел на птички через окно.

Вот и зря. Поставил себя в позу, как я в случае с комментариями (см. выше). Правильные же вещи, в принципе, говорили.

MiG31>Не зачем. Но код для микроконтроллеров составляет около 0.001% из всего кода.

Недооцениваешь, однако. На порядки. Правда, если считать построчно, то может быть и так А если в некоторых "полезных единицах", то для контроллеров и побольше может быть.

MABP>Вдогонку.. Мой босс убежден, что профи пишут исключительно на ASMe, в противном случае это хацкеры..

Как-то обычно считается, что наоборот...

fast>Все дело в том, что на С пишешь как хочешь/умеешь. Если стиль программирования плохой, то и на паскале ужасно получиться.
fast>А проблема у паскаля одна - выкручивание рук.
fast>В чем С и хорош - что он настраиваемый на любой стиль программирования.

Как часто бывает, недостатки следуют из достоинств и наоборот. По моему, хороший язык должен провоцировать и даже заставлять писать хорошо и красиво, а не "любым стилем". Этому не надо противиться, это надо понять и принять.

fast>паскалистам могу порекомендовать начинать с
fast>#define { begin
fast>#define } end
fast>

Вот, кстати, #define - самая что ни на есть вредная и архаичная конструкция. И это не только мое мнение.
Еще, чтобы немного разрядить обстановку , могу сказать, что мне больше всего не нравится в Си. Префикс 16-ричного числа, 0х. После ассемблера, где 16-ричная система чуть не по умолчанию, дико ломает писать два знака (ведь чисел порой целые дампы набивать надо ) Одно это компенсирует всю краткость сишных скобочек. С этой точки зрения мне современный Фортран нравится

quote:

---

А проблема у паскаля одна - выкручивание рук.

---

 

Хм.. Я бы сказал - разумные ограничения. Если хочешь чего этакого учудить - приложи дополнительные усилия, что есть подтверждение сознательности твоих действий. В управлении самолетом примерно аналогичная система - чем дальше тянешь ручку, тем большее усилие надо приложить. Говорят, у вьетнамцев с этим проблемы были - силёнок маловато..

quote:

---

Гибкие сишные нотации провоцируют навороченные конструкции, которые в сумме плохо читаются.

---

 

Во-во.. Для какого ещё языка проводятся конкурсы на самый непонятный исходник?

quote:

---

Я уверен, что для написания больших и особенно высоконадежных программ Паскаль подходит больше, чем Си (если выбирать из этих двух, конечно).

---

 

Полностью согласен. В качестве аргумента в поддержку - ошибки с преобразованием типа данных. Создается впечатление, что основное занятие сишников - вылавливание подобных ошибок. PAS отлавливает эти вещи еще на этапе компиляции.

Zeus>Гибкие сишные нотации провоцируют навороченные конструкции, которые в сумме плохо читаются.

Эх... Ну вот, опять.
Мы о профессионалах говорим или где?

Расписать почему пилоту средней квалификации лучше заниматься высшим пилотажем на Су-27, а пилоту-асу на МиГ-29? Или сам догадаешься?

Профессионал будет писать красиво, наглядно и надёжно и на ассемблере...

Zeus>Мало в Си строгости, именно это, я бы сказал, в основном мне не нравится.

Строгость и гибкость - вещи взаимоисключающие, ИМХО.
Вот потому и хорош Дельфи для обучения, а Си++ - для работы.

Zeus>Кстати, прямой зависимости между краткостью записи и читабельностью нет. Когда как...

В общем-то, чем меньше знаков требуется для записи одной и той же синтаксической единицы, тем выше, скажем так, информационная плотность языка. Значит выше плотность информационного потока и меньше шумовых данных.

Если бы выбирали доходчивость вместо информационной плотности, то вся математика писалась бы на человеческом языке, а не на кванторах, значках интегралов и квадратных корней. Да и в химии были бы не уравнения и структурные схемы, а "молекула водорода + половина молекулы кислорода при реакции дают одну молекулу воды". Ведь понятно, доходчиво и, главное, дилетанту понятно!

А ещё есть такой язык, как APL...

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

Просто, значит, ты ещё не усвоил знаковое восприятие сишных операторов, а при чтении программы неявно переводишь их в какой-то свой "внутренний алгоритмический формат". Это как с перевода для себя с иностранного языка. Кто-то переводит внутри себя в родной язык, а кто-то сразу думает на иностранном.

Zeus>Тогда какой-то профессор сказал, что надо увольнять как программистов, не пишущих комментарии, так и тех, кто комментирует каждую строчку.

Он прав на 100%
Правильно, максимальная информационная плотность программы будет где-то между "перекомментированной" и "недокомментированной"

Zeus>Чтобы себя уволить - это надо нехилым мужеством обладать перед самим собой.

Да, естественно.
Поэтому так мало программистов на Форте.
Чтобы начать на нём правильно писать нужно "себя уволить" - надо забыть всё, чему учили при обучении классическим АЯВУ и начинать всё заново. "Думать на Форте" - это не метафора. Это, действительно, совсем другой подход. Не даром именно так называется один из известнейших бестселлеров Лео Броуди. Зато потом эти методы, зачастую, ОЧЕНЬ много дают и при программировании на АЯВУ. Я так и не сумел стать профессиональным фортером, но приобрёл для себя там много много полезного.

Вот первый пример/вопрос.

Если мы боремся не за скорость, а за читабельность и надёжность.
Сколько лексических единиц должно быть в синтаксическом блоке? (Подпрограмме/функции/функциональном блоке...)


Zeus>Однако обсуждения (а не выкриков) по этому поводу я не заметил (собственно, ко всем относится).

Просто всерьёз психологическими аспектами взаимодействия человека и программы, при разработке нового языка, по-моему, занимался только Чарльз Мур. Он ведь взялся в своё время на порядок (т.е. буквально в 10 раз) повысить скорость разработки и написания программ. И при этом ещё и более надёжных, чем классические. Результатом семилетнего труда и стал первый прототип Форта. И хотя пользоваться этим языком по-настоящему эффективно мало кто может (я знаю буквально двух-трёх человек, себя, как уже отмечал, не включая в этот список - сказывается испорченность "классическим" программированием), но многие методы Форта, применимые к другим ЯВУ, очень полезны на практике. Хотя теоретики программирования за некоторые из них, например, за построение программы "снизу-вверх" готовы забросать табуретками.

Zeus>А! Хочешь, все-таки, чтобы красиво ехало? И быстро, и надежно? Тогда продется все-таки порожать алгоритм, возможно и в муках.

Естественно
Я же так и говорил.
Вот только алгоритм не должен отрываться от реальностей...

Zeus>Да и, впрочем, без "теоретиков физкультуры" настоящего спортсмена не получится. Так, любительство.

Вот только ни один теоретик физкультуры не победит на соревнованиях. Вообще, не стоит развивать аналогии. Они пересекаются, как правило, только в чём-то одном.

=KRoN=>>Кстати, для теоретизации существуют и более удачные языки, чем Паскаль. Даже у того же Вирта.

Zeus>А, это несомненно. От Оберона я почти в восторге. Но все упирается в те самые инструментальные средства...

Хех...
А вообще, целые операционные системы с прорвой прикладных программ написаны на таких вещах, как vi... В общем, среда помогает, но различия в уровне IDE толжны быть по-настоящему принципиальны, чтобы выбирать язык из-за средств его разработки. Именно поэтому для разработки несложных прикладных систем так часто выбирают Builder/Delphi. Когда львиную долю разработки ПО занимает написание интерфейса пользователя, особенно графического, тут эти средства выходят на первые места. Я, правда, пошёл несколько по другому пути - не люблю писать интерфейсы, потому выбрал программирование для Web. Браузер сам решит как лучше отобразить формы ввода/вывода, а моё дело - писать обработку данных

Zeus>Однако мы не о теоретизации говорим, а о профессиональном программировании. Я уверен, что для написания больших и особенно высоконадежных программ Паскаль подходит больше, чем Си (если выбирать из этих двух, конечно).

Однако подавляющее большинство программистов, всё же, уверены в совершенно обратном Я имею в виду профессионалов. Тебе не кажется странным, что реализаций Паскаля больше там, где больше любителей, а не профессионалов? PC + DOS/Win - вот и 99% использования Паскаля. Много ли пишут на Паскале для Unix? Много ли на нём написано военного софта? А как с уже заезженной тут темой микроконтроллеров?

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

100%!
См. абзац выше

Zeus>>>Наоборот, современное проектирование (опять же, языки - лишь частный пример) - это скорее искусство [само]ограничений, чем налепливание побрякушек...

=KRoN=>>Ой-йё...
=KRoN=>>Ты в каком мире живёшь?

Zeus>В самом что ни на есть настоящем.

Гм. И в этом твоём настоящем мире современные проектировщики пишут хорошие самоограниченные (само - для проектировщиков) программы, без побрякушек и т.п.? Посмотри на то, в чём ты читаешь этот мой текст, на чём оно написано и т.п.

Zeus>Ага, а мне в свое время хватало экранного редактора Ассемблера ZEUS )
Эх... Ностальгия... А вообще... Вот тебе ещё пример!
Какой вариант Asm'а 8080 тебе был логичнее, тот, что на ZX или тот, что на CP/M и т.п.? Т.е. что тебе нравилось больше:

LD A,B
LD A,(HL)
LD A,123

или

MOV A,B
LDAX H
MVI A,123

Zeus>Недооцениваешь, однако. На порядки. Правда, если считать построчно, то может быть и так А если в некоторых "полезных единицах", то для контроллеров и побольше может быть.

Ну, тут согласен

MABP>>Кстати, на борту у нас довольно долго стоял софт написанный на Модуле-2 (клон PAS таки ). Недавно пришлось переписать на C. Народ совсем не в восторге. Проблем прибавилось.

fast>Мне приходиться наоборот. В итоге - на 30% меньше текста и кода.

(недоверчиво так...)
Приходилось с C++ переписывать на Модулу-2 и вышло компактнее?

Zeus>Как часто бывает, недостатки следуют из достоинств и наоборот. По моему, хороший язык должен провоцировать и даже заставлять писать хорошо и красиво, а не "любым стилем". Этому не надо противиться, это надо понять и принять.

Язык для обучения студента - да.
Профессионалу же навязывать что-то - снижать его эффективность.

Zeus>Вот, кстати, #define - самая что ни на есть вредная и архаичная конструкция. И это не только мое мнение.

А с этим никто не спорит
Достаточно почитать того же Страуструпа
#define в C++ оставлен только из-за желания обратной совместимости с C. Ну и на всякий пожарный... Да и вообще, люблю я писать:

#define K +273.15

T = 25 K;

При программировании всякой химии здорово упрощает восприятие многих формул и т.п.

Zeus>Еще, чтобы немного разрядить обстановку , могу сказать, что мне больше всего не нравится в Си. Префикс 16-ричного числа, 0х. После ассемблера, где 16-ричная система чуть не по умолчанию, дико ломает писать два знака (ведь чисел порой целые дампы набивать надо ) Одно это компенсирует всю краткость сишных скобочек.

И это тот, кто ратует за однозначность и строгие рамки??

Ну-ка, что тут написано:
1001b
123d

Ась?

Сколько раз я стукался лбом в такие перлы при разборке чужих программ

Да и 0FFh не короче, чем 0xFF.
И массивы данных с 0x выглядят ровнее, и интерпретировать входные числа проще.

Хотя Паскалевский $ мне нравится, всё же, больше

Zeus>С этой точки зрения мне современный Фортран нравится

А мне - Forth (я вас тут всех им достану!

HEX
MAKE-ARRAY CHARS:
00 FF 00 FF 00 FF 00 FF
00 FF 00 FF 00 FF 00 FF
;
DECIMAL

MABP>Если хочешь чего этакого учудить - приложи дополнительные усилия, что есть подтверждение сознательности твоих действий. В управлении самолетом примерно аналогичная система - чем дальше тянешь ручку, тем большее усилие надо приложить.

Не совсем так.
И - есть Су-27, а есть МиГ-29.

MABP>Говорят, у вьетнамцев с этим проблемы были - силёнок маловато..

Это было во времена макроассемблеров...

MABP>Во-во.. Для какого ещё языка проводятся конкурсы на самый непонятный исходник?

Для Perl'а.
Но мы говорим, всё же, о любителях или профессионалах?
Представь, если электрика не станут допускать до распределительного щитка, говоря, что, мол, убить током может...
Так что всё подходит для того, для чего разрабатывалось. Паскаль - для обучения программированию, C - для рабочего програмирования.

>>Я уверен, что для написания больших и особенно высоконадежных программ Паскаль подходит больше, чем Си (если выбирать из этих двух, конечно).

MABP>Полностью согласен. В качестве аргумента в поддержку - ошибки с преобразованием типа данных. Создается впечатление, что основное занятие сишников - вылавливание подобных ошибок. PAS отлавливает эти вещи еще на этапе компиляции.

А кто тебя заставляет в C использовать указатели?
Это как раз тот самый электрораспределительный щиток.
Без которого работа электрика превращается во включение/выключение света в комнате выключателем.

Ошибки же явных преобразований типов отлавливаются в C++ компилятором тоже запросто.

Кстати, в Perl, например, вообще нет типов данных в привычном понимании

И вообще, типы данных - это пережиток тех времён, когда char процессором считался быстрее, чем int, а float был вообще безумным тормозом... В идеале останутся типы number, string и pointer, а ещё через какое-то время один общий тип, как сейчас в Perl/PHP/JavaScript. Когда ты читаешь книгу или слушаешь радио - там что, тебе разные типы данных передают?

MABP>В качестве контрпримера можно предложить написать аналогичные вещи для Кроноса на C. Для тех кто не в курсе - был такой монстрик отечественный, система команд заточена под модулу/оберон, операционка на ней-же написана.

Хех, дык мы как раз из этой самой Kronos Research Group и выросли Тот же наш bCAD я впервые именно для Кроноса и написал, в далеком теперь уже 90-м году. На оберон Кронос кстати не был заточен, читсая модула-машина, это уже позже наш компиляторописальщик Оберон увлекся. И Модула там была немного тог, продвинутая, кое-что от С в нее было внедрено, в основном чтобы printf сделать, уж больно неудобен модуловский.

MABP>Можно поставить вопрос и по другому - на каком самолете проще допустить ошибку пилотирования?

Бр-р-р...
Давай тогда, всё же, определися, о предмете спора
Изначально он зашёл именно о том, что лучше для профи - Pascal (Opj.Pas, Delphi) или C++...

MABP>ОК, пошли в теорию информации.. Помехозащищенность информации достигается только увеличением избыточности. Чем меньше избыточность, тем выше вероятность ошибки..

Не путай избыточную информацию и шум

MABP>А вот тут, ИМХО, причины скорее экономические и психологические, чем технические. *nix слишком C ориентированная ОС, плюс некоторый снобизм "профи" от него.. В качестве контрпримера могу сослаться на вышеупомянутый мною Кронос.

Можно спорить...
Паскаль заметно старше C/C++
И то, что более молодой язык вытеснил старца с насиженного места тоже говорит о многом. И ОС ориентированные на Си появились не рантше самого Си. И "снобизм" тут как раз мало что значит. Так как на этом уровне на порядок бОльший вклад вносят эффективность и экномическая целесообразность. А уж снобизм - это как раз характерная черта распальцованных кулхацкеров, которые погоды тут не делают

MABP>Что касается военного софта, то буржуи таки не много на C пишут, больше на Аде.

Да, но ведь не на Паскале
Если заводить сравнение C++ против Ады - я спорить не стану.
Слишком разные языки.

MABP>На C/C++ в основном noncritical app однако.. У нас правда все не так, пишут на чем не попадя..

Справедливости ради стоит отметить, что с выходом ANSI-стандарта C++ военные в Штатах как-то дружно начали переходить на C++. По крайней мере софт в ГСН новых модификаций AIM-9 и AIM-120 пишется уже на C++.

MABP>Теперь про любителей. ИМХО, просто у них нет некоторой зашоренности, выбирают то, что им больше подходит.

Вот-вот...
Как уже отмечалось, любитель выберет то, что попроще.
А не то, что надёжнее, удобнее, быстрее...

MABP>А над профи довлеют проблемы совместимости с предыдущими версиями, имеющиеся наработки, требования заказчика в конце концов.

Над профи как раз эти вещи давлеют меньше всего
Профи характерен именно тем, что не зашорен и выбирает средство под задачу.

MABP>Кроме того, взглянуть-бы на уникума, который для микроконтроллера на C++ пишет..

Ну, C++ - редкость, конечно
Но кроме контроллеров есть, к примеру, широчайший класс всевозможных PDA и микрокомпьютеров. Вот там C++ используют вовсю. Когда в прошлом году я собирался идти на работу в Сайбико (кстати, на ixbt появился неплохой обзор по этой штучке), то меня на собеседовании так гоняли по C++, что я даже удивился Начиная от тонкостей наследования C++, кончая особенностями работы с указателями на различных архитектурах... А ведь я шёл устраиваться на работу с железом, а не с софтом

>>>Говорят, у вьетнамцев с этим проблемы были - силёнок маловато..

KRoN>>Это было во времена макроассемблеров...

MABP>Года 3-4 назад в Жуковском группа вьетнамцев была на обучении..

А, я думал ты про МиГ-21-е...
Ну, на Су-27 ручку можно и ослабить.
Только редко делают...

MABP>ГЫК! А что, пардон за ламерский вопрос, от C останется ежели указатели убрать?

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

KRoN>>В идеале останутся типы number, string и pointer
MABP>Хех.. А как с железом работать? Во многих вещах каждый битик на счету..

Я же о прикладном софте.
Удивительно ты скачешь с одной темы на другую, я тебе скажу

quote:

---

Давай тогда, всё же, определися, о предмете спора
Изначально он зашёл именно о том, что лучше для профи

---

 

То, что лучше для задачи(ежели заказчик не против), ИМХО. А что касается сравнения C vs PAS, то профи тоже люди. И им свойственно ошибаться. А PAS дает меньше простора для ошибок. ИМХО.

quote:

---

Не путай избыточную информацию и шум

---

 

Дык я не путаю, токмо ИМХО это избыточность, а не шум.

quote:

---

Можно спорить...
Паскаль заметно старше C/C++
И то, что более молодой язык вытеснил старца с насиженного места тоже говорит о многом. И ОС ориентированные на Си появились не рантше самого Си. И "снобизм" тут как раз мало что значит. Так как на этом уровне на порядок бОльший вклад вносят эффективность и экномическая целесообразность.

---

 

Нужно спорить. PAS от рождения ЯВУ. А C это макро ASM-переросток. "Этот язык проектировался для того, чтобы получить непосредственный доступ к объектам, которыми оперируют процессоры ЭВМ: разрядам,байтам,словам и адресам"(Д. Хендрикс) Со всеми вытекающими наследственными болезнями. При ограниченных вычислительных ресурсах того времени и относительно небольшом объеме кода естественно C был эффективней. Бо можно было вылизать код. Характерная особенность сишников старшего поколения - сначала компилят в ASM, а потом его вылизывают. Ну а потом UNIX, потом ея величество совместимость.. Кроме того, у буржуев, в отличии от нас, крайне мало "многостаночников". Ежели его научили писать на C, то он будет на нем кропать до скончания века. И деньги вложенные в обучение персонала и покупку софта там очень даже считают. Эт я к тому, что статистические данные не всегда отражают объективную картину. В смысле win - это не самая лучшая ОС, просто под нея вложенны самые большие бабки.(Это в качестве аналогии )
Со снобизмом признаю - погорячился на хацкеров глядючи.

quote:

---

MABP>А над профи довлеют проблемы совместимости с предыдущими версиями, имеющиеся наработки, требования заказчика в конце концов.

Над профи как раз эти вещи давлеют меньше всего
Профи характерен именно тем, что не зашорен и выбирает средство под задачу.

---

 

Хех, а теперь ты путаешь - профи со свободным художником. ИМХО, профи делает то и так, что заказывают, а не что и как хотца.

quote:

---

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

---

 

Интересно, первый раз услышал про эту штуку.. А ++ небось с прицелом под следующую версию, "с производительность пентиума" и баальшой памятью Честно говоря, когда память измеряется килобайтами я не вижу особого смысла в применении C++ Ну а в PDA под CE сам Бил велел..

quote:

---

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

---

 

ИМХО, как раз в этом. В C требуются дополнительные усилия чтоб сделать программу более безопасной, а в PAS чтоб менее безопасной. Разница, как говорится, на лице..

[QUOTE]Я же о прикладном софте.
Удивительно ты скачешь с одной темы на другую, я тебе скажу/QUOTE]
А что делать? Ежели затрагиваем вопросы от микроконтроллеров и PDA до ОС, САПРов и Су-27 со Вьетнамцами..

Zeus>>Гибкие сишные нотации провоцируют навороченные конструкции, которые в сумме плохо читаются.

=KRoN=>Эх... Ну вот, опять.
=KRoN=>Мы о профессионалах говорим или где?

И что? Профессионалам уже не приходится разбираться в тексте? В том числе и своем? Разве лингвисту приятнее читать справочник, чем хороший детектив?

=KRoN=>Расписать почему пилоту средней квалификации лучше заниматься высшим пилотажем на Су-27, а пилоту-асу на МиГ-29? Или сам догадаешься?

Ну, для пилотажа асу лучше Су-26, а если нужен не пилотаж сам по себе, а качественное выполнение боевого задания, то и ему лучше Су-27.

=KRoN=>Профессионал будет писать красиво, наглядно и надёжно и на ассемблере...

Да, но с разными затратами.

=KRoN=>Строгость и гибкость - вещи взаимоисключающие, ИМХО.

Не совсем.

=KRoN=>Вот потому и хорош Дельфи для обучения, а Си++ - для работы.

Дельфи не хорош(а?) для обучения. Это не совсем паскаль. Впрочем, это отдельный вопрос. Мы говорим именно о работе.

=KRoN=>В общем-то, чем меньше знаков требуется для записи одной и той же синтаксической единицы, тем выше, скажем так, информационная плотность языка. Значит выше плотность информационного потока и меньше шумовых данных.

Во-1, МАВР уже неплохо ответил. Во-2, информационная плотность зачастую ухудшает читабельность. Ср. проф. лингв. сл. и нормальный текст. Даже для профи.

=KRoN=>Если бы выбирали доходчивость вместо информационной плотности, то вся математика писалась бы на человеческом языке, а не на кванторах, значках интегралов и квадратных корней. Да и в химии были бы не уравнения и структурные схемы, а "молекула водорода + половина молекулы кислорода при реакции дают одну молекулу воды". Ведь понятно, доходчиво и, главное, дилетанту понятно!

Немного разные вещи... Нет времени сейчас, чтобы развить. Во всяком случае, меру надо везде знать.

=KRoN=>А ещё есть такой язык, как APL...

К нему бы еще клавиатуру специальную

=KRoN=>Просто, значит, ты ещё не усвоил знаковое восприятие сишных операторов, а при чтении программы неявно переводишь их в какой-то свой "внутренний алгоритмический формат". Это как с перевода для себя с иностранного языка. Кто-то переводит внутри себя в родной язык, а кто-то сразу думает на иностранном.

Тут как раз несколько наоборот. Как раз по мелочам мне это нравится и даже близко. Я уже говорил, что все конспекты значками пишу, а уж что было на мат.анализе... Вообще ни капли текста. Но я специально (теперь) заставляю себя писать понятно не только для себя; да и для себя понятнее для комфортного чтения.

Zeus>>Чтобы себя уволить - это надо нехилым мужеством обладать перед самим собой.

=KRoN=>Да, естественно.
=KRoN=>Поэтому так мало программистов на Форте.
=KRoN=>Чтобы начать на нём правильно писать нужно "себя уволить" - надо забыть всё, чему учили при обучении классическим АЯВУ и начинать всё заново. "Думать на Форте" - это не метафора. Это, действительно, совсем другой подход. Не даром именно так называется один из известнейших бестселлеров Лео Броуди. Зато потом эти методы, зачастую, ОЧЕНЬ много дают и при программировании на АЯВУ. Я так и не сумел стать профессиональным фортером, но приобрёл для себя там много много полезного.

Я форт неплохо себе представляю. Кстати, кому приходилось программировать внутренний калькулятор на ZX Spectrum (на котором весь его Бейсик построен), вообще хорошо фортовскую идеологию понимает

=KRoN=>Вот первый пример/вопрос.

=KRoN=>Если мы боремся не за скорость, а за читабельность и надёжность.
=KRoN=>Сколько лексических единиц должно быть в синтаксическом блоке? (Подпрограмме/функции/функциональном блоке...)

Не очень понял. Сколько нужно...

Zeus>>А! Хочешь, все-таки, чтобы красиво ехало? И быстро, и надежно? Тогда продется все-таки порожать алгоритм, возможно и в муках.

=KRoN=>Естественно
=KRoN=>Я же так и говорил.
=KRoN=>Вот только алгоритм не должен отрываться от реальностей...

Ну, а я о чем?

Zeus>>Да и, впрочем, без "теоретиков физкультуры" настоящего спортсмена не получится. Так, любительство.

=KRoN=>Вот только ни один теоретик физкультуры не победит на соревнованиях. Вообще, не стоит развивать аналогии. Они пересекаются, как правило, только в чём-то одном.

ИМХО здесь уместно.

=KRoN=>А вообще, целые операционные системы с прорвой прикладных программ написаны на таких вещах, как vi... В общем, среда помогает, но различия в уровне IDE толжны быть по-настоящему принципиальны, чтобы выбирать язык из-за средств его разработки. Именно поэтому для разработки несложных прикладных систем так часто выбирают Builder/Delphi. Когда львиную долю разработки ПО занимает написание интерфейса пользователя, особенно графического, тут эти средства выходят на первые места. Я, правда, пошёл несколько по другому пути - не люблю писать интерфейсы, потому выбрал программирование для Web. Браузер сам решит как лучше отобразить формы ввода/вывода, а моё дело - писать обработку данных

О, проясняется. Я интерфейс писать люблю и его уважаю. Это важнейшая часть современного ПО (думаю, никто не спорит).

=KRoN=>Однако подавляющее большинство программистов, всё же, уверены в совершенно обратном Я имею в виду профессионалов. Тебе не кажется странным, что реализаций Паскаля больше там, где больше любителей, а не профессионалов? PC + DOS/Win - вот и 99% использования Паскаля. Много ли пишут на Паскале для Unix? Много ли на нём написано военного софта? А как с уже заезженной тут темой микроконтроллеров?

Тут опять МАВР неплохо сказал. Я внутренне уверен, что такое распространение Си не слишком связано с его достоинствами/недостатками. С этим согласен даже Ритчи (потом нарою цитату, если интересно). Просто он появился в нужнов время в нужном месте.

=KRoN=>Гм. И в этом твоём настоящем мире современные проектировщики пишут хорошие самоограниченные (само - для проектировщиков) программы, без побрякушек и т.п.? Посмотри на то, в чём ты читаешь этот мой текст, на чём оно написано и т.п.

Побрякушек немало

=KRoN=>Эх... Ностальгия... А вообще... Вот тебе ещё пример!
=KRoN=>Какой вариант Asm'а 8080 тебе был логичнее, тот, что на ZX или тот, что на CP/M и т.п.? Т.е. что тебе нравилось больше:

=KRoN=>LD A,B
=KRoN=>LD A,(HL)
=KRoN=>LD A,123

=KRoN=>или

=KRoN=>MOV A,B
=KRoN=>LDAX H
=KRoN=>MVI A,123

О!! Совершенно однозначно, первое! Разумеется.

Остальное попозже.

MABP>Интересно, первый раз услышал про эту штуку..

Хех...
С десяток попуоярных журналов в Штатах и Европе назвали "Кубик" "игрушкой ?1 2000-го года"

Жду, вот, пока Сай-2 в России появится, чтобы выбрать, наконец, Пальм, PV450 или эту игрушку

А еще есть такая беда, как отладка кода...

Да, когда-то важно было ужать программу до минимума. Каждый бит, каждый такт процессора был на счету. Вот и языки были "машинно-ориентированными". Ну, потратит программер неделю на отладку/вылизывание - не беда.

Сейчас гораздо более ценная вещь - время этого самого программера. По-моему, поиск ошобок в Паскалевском тексте - гораздо легче. А главное - сама ВЕРОЯТНОСТЬ ошибок на Паскале гораздо ниже.

Вот и считайте: "выигрыш" 10 кб кода или день лазания по исходнику (хорошо если своему!)

И не надо морочить голову "профессионалами": профессионалы - они тоже люди, и разбор конструкций из 10 плюсов с 13 звездочками у них тоже занимает время и не повышает безошибочность кода.

Zeus>И что? Профессионалам уже не приходится разбираться в тексте? В том числе и своем? Разве лингвисту приятнее читать справочник, чем хороший детектив?

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

Zeus>Ну, для пилотажа асу лучше Су-26, а если нужен не пилотаж сам по себе, а качественное выполнение боевого задания, то и ему лучше Су-27.

Ну, спрофилируем задачу - какая машина лучше для БВБ?

=KRoN=>>Профессионал будет писать красиво, наглядно и надёжно и на ассемблере...

Zeus>Да, но с разными затратами.

Не-а.
При крамотном подходе и хорошем знании матчасти можно писать весьма доходчивые программы на масме. И даже объектные

Лениво рыться в архивах, но про кое-какие из моих исходников, народ не верил, что это ассемблер, пока макросы не показывал

=KRoN=>>В общем-то, чем меньше знаков требуется для записи одной и той же синтаксической единицы, тем выше, скажем так, информационная плотность языка. Значит выше плотность информационного потока и меньше шумовых данных.

Zeus>Во-1, МАВР уже неплохо ответил. Во-2, информационная плотность зачастую ухудшает читабельность. Ср. проф. лингв. сл. и нормальный текст. Даже для профи.

Ещё раз приведу пример - "две молекулы вдорода взаимодействуя с одной молекулой кислорода дают в результате реакции две молекулы воды". Извини, если бы на таком языке писалась бы химия... Не представляю уровень нынешнего развития цивилизации, каким бы он был...

=KRoN=>>Если бы выбирали доходчивость вместо информационной плотности, то вся математика писалась бы на человеческом языке, а не на кванторах, значках интегралов и квадратных корней. Да и в химии были бы не уравнения и структурные схемы, а "молекула водорода + половина молекулы кислорода при реакции дают одну молекулу воды". Ведь понятно, доходчиво и, главное, дилетанту понятно!

Zeus>Немного разные вещи... Нет времени сейчас, чтобы развить. Во всяком случае, меру надо везде знать.

Не вижу разницы. Более компактная запись при однозначной идентификации предпочтительнее, чем более развёрнутая. Человеческий мозг способен одновременно воспринимать 7 ± 2 токена. И чем больше в них удасться вложить, тем проще работать с задачей. Естественно, до тех пор, пока токены однозначно идентифицируются. Кстати, поэтому пресловутая запись i++; (для того, кто её усвоил) опознаётся быстрее, чем inc(i); В случае короткого имени переменной, правда i:=i+1; тоже идентифицируется хорошо, но только потому, что это уже усвоенный токен. Для длинных имён переменных вариант с присваиванием уже начинает проигрывать...

=KRoN=>>А ещё есть такой язык, как APL...
Zeus>К нему бы еще клавиатуру специальную


Ну, китайцы же, иероглифы как-то вводят

Zeus>Я форт неплохо себе представляю. Кстати, кому приходилось программировать внутренний калькулятор на ZX Spectrum (на котором весь его Бейсик построен), вообще хорошо фортовскую идеологию понимает

Если ты под фортовской логикой понимаешь только обратную польскую запись, то ты форт как раз поверхностно знаешь

Дело не в формате записи. Как раз запись может быть и инфиксной, и префиксной. Идеология форта в методологии декомпозиции задачи на подзадачи. Расчленение всей программы на субмодули, каждый из которых легко воспринимается одним взглядом, целиком. И тестирование/отладка каждого такого модуля по отдельности. Это, конечно, не всё, но очень важное Впрочем - это целая толстенная книжка

=KRoN=>>Сколько лексических единиц должно быть в синтаксическом блоке? (Подпрограмме/функции/функциональном блоке...)

Zeus>Не очень понял. Сколько нужно...

Я выше уже упоминал цифру - семь, плюс-минус две.
Особенность человеческого восприятия.
Если больше, то ты уже не в состоянии охватить блок целиком и он перестаёт быть психоструктурной единицей. Как следствие, тебе приходится прогонять его в сознании по частям. А это - путь к ошибкам. Меньше - невыгодно по вычислительным соображениям
В общем, как в своё время народ материли за GOTO, так Форт идёт дальше и негативно относится к функциям и подпрограммам на экраны размером.

Zeus>О, проясняется. Я интерфейс писать люблю и его уважаю. Это важнейшая часть современного ПО (думаю, никто не спорит).

О, проясняется. Тогда понятно, почему тебе близок Delphi

Zeus>Тут опять МАВР неплохо сказал. Я внутренне уверен, что такое распространение Си не слишком связано с его достоинствами/недостатками. С этим согласен даже Ритчи (потом нарою цитату, если интересно). Просто он появился в нужнов время в нужном месте.

Си и Си++ - всё же несколько разные вещи
Даже более разные, чем виртовский Паскаль и Delphi

=KRoN=>>Какой вариант Asm'а 8080 тебе был логичнее, тот, что на ZX или тот, что на CP/M и т.п.? Т.е. что тебе нравилось больше:

=KRoN=>>LD A,B
[...]
=KRoN=>>или
[...]
=KRoN=>>MOV A,B

Zeus>О!! Совершенно однозначно, первое! Разумеется.

Вот ты и попался!
Первая запись гораздо менее однозначная и допускает больше ошибок

LD (BC),(DE), скажем

GrayCat>И не надо морочить голову "профессионалами": профессионалы - они тоже люди, и разбор конструкций из 10 плюсов с 13 звездочками у них тоже занимает время и не повышает безошибочность кода.

Профессионал, будь он трижды человек, не допустит "конструкций из 10 плюсов с 13 звездочками". Это как раз почерк дилетанта, освоившего навороты C++, но не научившегося ими пользоваться. Такой человек и в Паскале ТАКОГО может наворотить...

Кстати, вылетело из головы - в Delphi ввели цикл с произвольным аргументом, или как и в Паскале остался только целочисленный с шагом 1?