Языческие разборки.

Саша, ну я же не в смысле "Beginenders must die!!!" Я сам выучил Паскаль с большим удовольствием (хотя Бейсик, 8080 ассемблер и Фортран знал еще до того). Была такая весчь - Паскаль для ДВК-3М. Он компилировал в ассемблерный (текстовый) файл, и его надо было макроассемблером превращать в OBJ потом и линковать. А потом я долго программировал на Турбо-Паскале под ДОС. И я безоговорочно согласен, что это лучший учебный язык для начинающих, гораздо лучше Бейсика, глаза мои бы его не видели.

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

Ну, откуда там C++ стырило int i = 0; из Алгола? А как это дело нам стырить в Паскаль, если там i: Integer? Опять, казалось бы мелочь, где писать тип, до или после, а все же... Или НЕСКОЛЬКО способов разбивать программу на части, сишный и "модульный". Это тоже следствие паскалевской стуктуры программы, хорошей для обучения, дисциплинирующей, но крайне неудобной для практических приложений большого размера. Или расширенный тип процедурной переменной и все заморочки с @ и @@. В С подразумевается, что ИМЯ функции это и есть ее АДРЕС, как это и есть после компиляции, это то что стоит после CALL кода. А ВЫЗОВ функции обозначается () после ее имени, или после переменной, в которую всунут адрес функции, без разницы. (Это не Саше, а тому, кто спрашивал, зачем нужны эти дурацкие ()? Вот, нужны. В С практически ничего лишнего нет.)

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

int ETIM;
static int VOT_ETIM;
int main()
{
int I_VOT_ETIM

?

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

Ну, хорошо, Delphi - это чудесная вещь, которая в своей области не уступает MSVC. Ну, а выйдя за пределы этой области? Скажем, RPC сервер в виде NT сервиса и соответствующий ему клиент? Коммерческие, разумеется, со сложной собственной функциональностью, типа TCP/IP сокетов. Не говоря уже о драйверах...

Потом, обрати внимание, сколько вещей в программировании строилось по тому же сишному стандарту, хотя к С прямого отношения не имеют. Те же сокеты (по образу сишных файлов), RPC (сишные функции), OLE интерфейсы (реализация С++ объектов), та же Ява. С заслуженно вошел в культуру программирования, это уже больше, чем язык. Знать его надо, и желательно хорошо, даже если программируешь на совсем другом языке.

<<Ну и степень удобства MFC? >>

:- Ну а что? По-моему - вполне.

<<В Delphi тоже можно регистрить сообщения и обработчики, не используя расширений языка>>

А как? Пардон, я Дельфи не знаю до таких тонкостей.

Главное мое возражение состоит вот в чем. Профессионал, как бы ни бил себя пяткой в грудь, ошибается. И многие знания, как замечено, иногда умножают печаль Профессионал или нет - различие лишь количественное, просто слабина появится на разном уровне. Может, и не появится, но это смотря чем заниматься и каковы амбиции Ну так вот, Паскаль (а тем паче более поздние его производные) гораздо меньше зависят от профессиональности программиста, чем Си(++). Существующее положение вещей, когда 60-80% времени уходит на отладку - ненормально и во многом, по моему убеждению, порождено традиционным сишным мышлением. Дисциплина нужна всем, и профессионалам даже больше, чем новичкам!

А теперь немного по-мелочи.

k_gornik>Ну, откуда там C++ стырило int i = 0; из Алгола? А как это дело нам стырить в Паскаль, если там i: Integer?

Ничем не хуже: i: integer = 0; // это не затрагивая вопроса вообще о необгодимости инициализации переменных k_gornik>...Или расширенный тип процедурной переменной и все заморочки с @ и @@.

Да чего заморочки, адрес и адрес, вполне естественно. Уж куда симпатичнее, чем сишные звездочки Впрочем, сишные скобочки, применительно к различению функций и переменных, мне тоже больше нравятся, я об этом уже упоминал здесь k_gornik>Потом, обрати внимание, сколько вещей в программировании строилось по тому же сишному стандарту, хотя к С прямого отношения не имеют. Те же сокеты (по образу сишных файлов), RPC (сишные функции), OLE интерфейсы (реализация С++ объектов), та же Ява.

А потому и строилось, что мышление программистов так сформировано. Ну и разве представляют те же сокеты или OLE верх архитектурного изящества? ИМХО скорее наоборот. А в Яве много ли от Си осталось, если хорошо посмотреть? Синтаксис, так это только чтоб программистов не переучивать.

k_gornik><<Ну и степень удобства MFC? >>

k_gornik>:- Ну а что? По-моему - вполне.

Но после VCL не канает k_gornik><<В Delphi тоже можно регистрить сообщения и обработчики, не используя расширений языка>>

k_gornik>А как? Пардон, я Дельфи не знаю до таких тонкостей.

ну типа
procedure WSAAsync(var Msg: TMessage); message WM_USER;

но ведь это типичное расширение...

По поводу дисциплины - к дисциплине надо приучать учеников, а профессионалы... Дисциплина нужна и профессионалу, но на своем месте. Оправдывать все необходимостью дисциплины - это уже маленькое передергивание.

60-80% на отладку - если задача сильно нестандартная, то по другому не получиться, даже если все заранее на бумажке нарисовать. Если стандартная - при достаточном опыте заработает сразу или почти сразу.

k_gornik>>Ну, откуда там C++ стырило int i = 0; из Алгола? А как это дело нам стырить в Паскаль, если там i: Integer?

Zeus>Ничем не хуже: i: integer = 0; // это не затрагивая вопроса вообще о необгодимости инициализации переменных Речь идет не об инициализации вообще, а об объявлении и инициализации в любом месте, именно так было в Алголе. Инициализация нужна с точки зрения дисциплины программирования, именно поэтому придуманы конструкторы. В принципе, любая переменная должна быть инициализирована.

k_gornik>>...Или расширенный тип процедурной переменной и все заморочки с @ и @@.

Zeus>Да чего заморочки, адрес и адрес, вполне естественно. Уж куда симпатичнее, чем сишные звездочки Объясни чайнику, какая разница между @ и @@. В С адрес не звездочки, а &.

Zeus>А потому и строилось, что мышление программистов так сформировано. Ну и разве представляют те же сокеты или OLE верх архитектурного изящества? ИМХО скорее наоборот.

Может и нет, но альтернатива?

k_gornik>><<В Delphi тоже можно регистрить сообщения и обработчики, не используя расширений языка>>

k_gornik>>А как? Пардон, я Дельфи не знаю до таких тонкостей.

Zeus>ну типа
Zeus>procedure WSAAsync(var Msg: TMessage); message WM_USER;

Zeus>но ведь это типичное расширение...

Ну, это и я знаю. А как без расширений?

k_gornik>Оправдывать все необходимостью дисциплины - это уже маленькое передергивание.

Ну так дисциплина же не самоцель. Ей просто надо уметь пользоваться. Чем сложнее программа, тем больше она помогает.

k_gornik>60-80% на отладку - если задача сильно нестандартная, то по другому не получиться, даже если все заранее на бумажке нарисовать. Если стандартная - при достаточном опыте заработает сразу или почти сразу.

Что значит "стандартная"? Которую уже делал? Так нечего второй раз писать k_gornik>Речь идет не об инициализации вообще, а об объявлении и инициализации в любом месте, именно так было в Алголе.

Вот уж это самый большой ужас! Объявлять переменные в произвольном месте - источник многих нелепых ошибок, да и вообще моветон. И не зря это из Алгола убрали!

k_gornik>Объясни чайнику, какая разница между @ и @@. В С адрес не звездочки, а &.

Да неважно, адресация, разадресация, я про всё это. @@ никогда не приходилось использовать, не понимаю, зачем нужно.

k_gornik>Может и нет, но альтернатива?

Ну например Оберон как альтернатива Java.

Zeus>>procedure WSAAsync(var Msg: TMessage); message WM_USER;

Zeus>>но ведь это типичное расширение...

k_gornik>Ну, это и я знаю. А как без расширений?

Как? Ну... Написав самостоятельно оконную процедуру например Или "вмешавшись" в нее - это можно сделать.

Народ! Не имел возможности обстоятельно прочитать вашу переписку, поэтому пока отвечу только на то, за что глаз зацепился.

Итак:
1. по поводу произвольной точки объявления переменных.

Во-первых, это свойство С++, а не С. В С такие вольности себе позволяли только отдельные компиляторы.

Во-вторых, в С++ это к сожалению является насущной необходимостью, так как констуктор объекта вызывается одновременно с объявлением этого объекта (вопрос об удобстве, правильности и т.п. --- оставляю за скобками как не имеющий ответа!)

2. По поводу изменений языка при создании Delphi

Утверждаю, что для реализации VCL(библиотеки) и IDE(оболочки) такого средства разработки, как Delphi не требовалось создания нового языка или замены использовавшегося диалекта на Object Pascal!

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

Просто видимо фирма Borland решила воспользоваться более стандартным с её точки зрения диалектом Object Pascal --- то, что этот диалект до сих пор поддерживается большинством компиляторов опционально, тогда видимо не прогнозировалось, да и вообще не было критерием отбора.

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

4. Костя! Тебе не кажется странным, что современные языки исповедуют именно модульный подход и лишь С++ с упорством, достойным лучшего применения, держится за свои заголовочные файлы, давно отжившие своё?

5. Паскаль столь же гибкий язык, как и С/С++, а в негибком подходе к нему следует винить не язык, а вполне конкретного разработчика средств разработки.

6. По поводу удобства Паскаля для профессиональной разработки: VCL совершенно точно нельзя назвать любительской поделкой, тем паче, что AFAIK она скрывает некоторые баги WinAPI --- её написали 4 человека, сколько человек писали MFC?

7. По наблюдениям Сергея Факаса, большинство ГИС-систем (ну совершенно не любительская задача!) написано на Delphi, включая ту, что написал сам Сергей с 3 своими коллегами по работе. Интересно сколько программистов на С++ потребовалось бы для решения аналогичной задачи?

Отсюда я делаю вывод: существует достаточно широкий круг задач, для которых Delphi (Object Pascal) являются оптимальным решением. Тем же для кого выбор C является политическим решением (а во многих случаях это именно так), предлагаю подумать над вариантом разработки пработающего прототипа на Delphi c дальнейшим переводом на C/C++ --- уверен выйдет быстрее.

PS: Кстати, что-то не слышно никаких планов по выходу BCB-6 и BCB для Linux. Delphi6 уже полгода как вышла, и две версии Kylix вышли для Linux... Бобик сдох?

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

Возможно, изменения в Дельфи вносить не нужно было. Однако внесли . Я не очень разделяю твой энтузиазм по поводу расширений. Если бы не сопроцессор, в С тоже пришлось бы добавлять расширения для УДОБНОГО его использования под Win.

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

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

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

Ну, разумеется библиотека VCL для Паскаля должна быть написана на Паскале, если б это было не так, то Паскаль был бы совсем никудышний. На Паскале МОЖНО создавать вполне профессиональные программы. Но лучшее - враг хорошего.

Я не знаю, что такое ГИС. По моим наблюдениям, Delphi - единственный паскалевский компилятор, активно используемый сегодня. Под другими, кроме Wintel, платформами, Паскаль не очень популярен тем более.

Безусловно, есть широкий круг задач, для которых Паскаль ЛУЧШЕ С. Я уже говорил, что хотел бы, чтобы Паскаль занял нишу Бейсика. Но...

Костя!

1. Что-то я не очень помню, чтобы я излучал оптимизм по поводу расширений языка...

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

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

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

Так что мой наезд по поводу отсутствия модулей остается в силе!

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

quote:

---

По моим наблюдениям, Delphi - единственный паскалевский компилятор, активно используемый сегодня.

---

 

С таким же успехом можно заявить, что Windows --- единственная операционка активно используемая на компьютерах

Итого я до сих пор не прочитал веских аргументов, почему:

quote:

---

Приходится признать, что Паскаль менее гибкий язык.

---

 

PS: и кстати, я, к сожалению, не знаю, что такое "ad hoc"...

О ! Да тут дерутся )). Я тоже вставлю 5 копеек .
Asteroid>Итак:
Asteroid>1. по поводу произвольной точки объявления переменных.

Asteroid>Во-первых, это свойство С++, а не С. В С такие вольности себе позволяли только отдельные компиляторы.

И это очень плохо. Когда переменные объявлены россыпью по процедуре найти концы сложно. Конечно, с помощью мощных современных IDE искать объявления просто. А простым текстовым редактором ? А ?
В Паскале я знаю где все сидит и оч. просто все могу контролировать. Так что структурированность паскалевских прог есть огромное преимущество при промышленной разработке больших проектов.
Особенный кайф я получаю от модулей и разнесения interface и implementation. Модуль становится объектом (не классом sic !) — у него есть инкапсуляция. Опять же не к ночи будь помянут Java, но там технология саомдокументации вынужденна из-за того, что нет отдельно вынесенного интерфейса класса или пакета. Вот и приходитсянапускать на код всякие генераторы. А в Паскале — просто вырезал интерфейсную часть модуля и поставляй с библиотекой .

Asteroid>2. По поводу изменений языка при создании Delphi

Asteroid>Утверждаю, что для реализации VCL(библиотеки) и IDE(оболочки) такого средства разработки, как Delphi не требовалось создания нового языка или замены использовавшегося диалекта на Object Pascal!
Дык не изменялось ничего много. Я пережил переход от BP 6.0 к Дельфям. Стала более строгой ООП концепция (классы вместо объектов), появились свойства (не такое уж радикальное изменение), расширились области видимости и... Больше ничего радикального не вижу.
И шока при переходе не было .

Asteroid>3. Тот способ регистрации, что привел Zeus, как раз является излишним расширением языка, существуют соответствующие процедуры, к сожалению сейчас я их не помню, а искать времени нет.
Хохма в том, что динамические методы (а именно он имеет место быть в приведенном Zeus примере) были еще в BP 6.0 и TV.

Asteroid>4. Костя! Тебе не кажется странным, что современные языки исповедуют именно модульный подход и лишь С++ с упорством, достойным лучшего применения, держится за свои заголовочные файлы, давно отжившие своё?

Во, во... И проблема с подчеркиванием оттуда. Паскаль программист очень легко обойдет проблему конфликта имен, он просто укажет модуль, из кот-го импортируется процедура. У меня есть место где есть локальный метод Reset. Для работы с текстовым файлом я пишу System.Reset — просто и понятно . Тем более что компайлер меня ругает, если я об этом забываю .

Asteroid>7. По наблюдениям Сергея Факаса, большинство ГИС-систем (ну совершенно не любительская задача!) написано на Delphi, включая ту, что написал сам Сергей с 3 своими коллегами по работе. Интересно сколько программистов на С++ потребовалось бы для решения аналогичной задачи? ))). Я скажу более того, нам первая версия попала в исходниках без особой документации. Разобрались за 2 месяца в 100 тыс строк кода и совсем не десткого (To Горник : ГИС — ГеоИнфрмационные Системы. Проще — электронная карта. Проблема состоит в болшьшом объеме данных, кот-й надо быстро отрисовывать. Например одних дорог только 6 млн. вектроов.)

Asteroid>Отсюда я делаю вывод: существует достаточно широкий круг задач, для которых Delphi (Object Pascal) являются оптимальным решением. Тем же для кого выбор C является политическим решением (а во многих случаях это именно так), предлагаю подумать над вариантом разработки пработающего прототипа на Delphi c дальнейшим переводом на C/C++ --- уверен выйдет быстрее.

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

Asteroid>3. Извини не понял, как появление сопроцессора, кстати, отсутствовавшего в большинстве первых машин, для которых писалась винда, позволило избежать появления расширений в Си.

Полагаю, имелся в виду препроцессор. Жуткая штука Позволить он может много чего, но ИМХО вреда от него гораздо больше, чем пользы.
Кстати, в чистом виде препроцессора в ассемблере нет. Если только в макроассемблере, и то не совсем...

k_gornik>Почитал вот, не удержался, влез Я тоже k_gornik>А ответ простой: если пишешь обыкновенную прикладную программу - никогда не начинать имен с подчеркивания. Если пишется статическая библиотека, и нужна глобальная переменная с внешним линкажом, ее имя ДОЛЖНО начинаться с подчеркивания, чтобы пользователь библиотеки не получил проблемы с конфликтом имен.
Именуй все процедуры и глобалы библиотеки нужным образом. Например, в библиотеке "XBZ" все процедуры и глобалы называются XBZ_globalA, XBZ_global153, XBZ_proc101 e.t.c.
Вы не поверите, работает!

quote:

---

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

---

 

Хочется макросов --- пользуйте m4 --- мощнее зверя в мире нет