Обсуждение:Фортран/Архив

message: Господа, прошу разрешить мне отправить старые обсуждения (особливо ООП) в архив вида Обсуждение:Фортран/Архив, оставив здесь лишь ссылку. Затем я хочу начать новое обсуждение, ибо в текущем виде статья вызывает у меня глухое раздражение, но есть ощущение, что в одиночку не потяну исправления.Const 19:55, 24 марта 2007 (UTC)
Полностью поддерживаю. Удалить всю грязь, но не помещать в архив, а удалить полностью.
Такие "обсуждения" не украшают российских программистов. 
Посмотрите в Google на англ.яз. по поводу Fortran и OOP - много публикаций, в т.ч. и статья автора, которого здесь облили грязью (статья переведена на англ. яз. и опубликована в зарубежном журнале). 
Ваше раздражение по поводу статьи  в Википедии мне понятно. Помогу, если не будет грязи.
Для начала два примера. Положительный пример - статья  в англ. Википедии. Отрицательный пример - wiki.vingrad. Участник:Фортранщик
replies: text: Уважаемый фортранщик (коллега?), у меня есть к вам несколько просьб:

text: 1) пожалуйста, будьте аккуратнее при правках (вы стёрли мою подпись, пришлось восстановить);

text: 2) пожалуйста, зарегистрируйтесь, ибо так будет чуть проще общаться... по крайней мере никто за вас не подпишется уже;

text: 3) к сожалению (а может и к счастью) тут принято сохранять все обсуждения -- на радость или в назидание потомкам.. давайте следовать этому принципу.

text: Const 19:55, 24 марта 2007 (UTC)
Уважаемый Const, прошу меня извинить за то, что нечаянно стерта Ваша подпись.
С остальными пунктами согласиться не могу. Оставлять потомкам эту грязь и безграмотные суждения? Тон, выбранный анонимом, вообще недопустим в приличном обществе. Обычно администраторы сайтов следят за этим и блокируют непристойные тексты. Не хочу, чтобы мое имя фигурировало в "таком"
обсуждении. Фортранщик

text: Уважаемый Фортранщик, по пункту 1 извинения приняты. По пункту 2 я ответа не увидел. По пункту 3: я тоже не согласен и возмущён, но стараюсь помнить поговорку про чужой монастырь... Пока на подобное удаление не будет получено разрешения от администраторов проекта -- это недопустимо.. К сожалению, администраторы пока отмалчиваются. Const 08:51, 26 марта 2007 (UTC)
thread_title:  Про упорядочивание 

message: Про то, что сейчас на фортране мало пишут - это вы зря. Просто он как жил в своей мало распространенной нише (численные расчеты, моделирование и т.п.), так и живет. И очень удобен в этом классе задач.
replies: text: Я это знаю и сейчас постепенно правлю статью до истинного положения вещей. --Const 07:32, 2 ноября 2005 (UTC)
Нужно-ли про плаканкюль здесь? Const 09:41, 28 ноября 2005 (UTC)

text: А что это?Vasiliev Mihail 21:02, 29 ноября 2005 (UTC)
replies: text: : Второе предложение кто-то вставил: «(Язык Планкалкюль был изобретён ещё в 1945 году, но не был реализован вплоть до 2000 года.)» Const 04:56, 30 ноября 2005 (UTC)
replies: text: :: Тоже не уверен есть ли необходимость писать про Планкалкюль, автор вероятно хотел сказать, что  Планкалкюль является первым языком высокого уровня, но так и не был реализован длительное время, поэтому Fortran является фактически первым языком высокого уровня. Здесь необходимо либо развернуть мысль, либо вообще Планкалкюль убрать - я чуть-чуть поправил, но мне не очень нравится...Cheops 01:59, 2 декабря 2005 (UTC)
На счет ООП в статье - это зря. На самом деле Фортран к ООП отношения не имеет. Есть возможность ИМИТИРОВАТЬ многие объектно-ориентированные фишки, но по сути ООП к Фортрану пристегнуто быть не может. Основное приложение Фортрана - численные рассчеты, так всегда было и всегда будет. И реализовать их удобнее на чисто процедурном языке, без всяких объектно-ориентированных прибамбасов. Они будут только мешать. Как-то это ООП не хочет уживаться с численными алгоритмами. Возьмите любую книгу, в которой обсуждаются вычислительные алгоритмы с точки зрения ООП, например, на Паскале. Можно гарантировать, что там будут разные алгоритмы перебора, ветвления, сортировки, и закончится все это... Ну, те, кто брал в руки такие книги, знают, чем они кончаются. Те, кто не брал, наверно, не поверят: алгоритмом игры "Ханойские башни". Везде. Во всех таких книгах. А вот если надо алгоритм разложения в ряд Фурье - это не к нам, это смотрите на Фортране.

text: Во-первых, подписывайтесь :)

text: Во-вторых, монстры утверждают, что ООП сильно помогает в разработке параллельных программ (отсылаю к авторитету Аллы Моисеевны Горелик). За себя не скажу, но возможность организации структур (начиная с F90) помогает весьма. Наконец, международный комитет сейчас движется к стандарту (под условным названием F2008), который предполагается снабдить полноценной поддержкой ООП. Const 10:44, 21 апреля 2006 (UTC)
replies: text: : Ну, объектно-ориентированность помогает далеко не всякому параллелизму. Написать баллансирование нагрузки для программы со сложной объектной структурой ой-как нетривиально. Другое дело, что чисто-процедурный подход предполагает гораздо более простые модели взаимодействия данных. Vasiliev Mihail 19:27, 21 апреля 2006 (UTC)

text: ООП - это не свойство языка, это свойство мышления. Язык (любой) лишь дает более или менее удобные средства для ОО-мышления. Vasiliev Mihail 19:27, 21 апреля 2006 (UTC)
replies: text: :Так я и не утверждаю, хорошо это или плохо.. Я просто комментирую замечание ув. Анонима: ООП в Фортране частично присутствует — раз; ООП в очередном стандарте Фортрана ожидается полноценным — два.

text: :А использовать или нет эту возможность — личное дело каждого. Так, я — не использую. Мне более по душе структуры данных (F90), конструкция FORALL (F95) и умение работать с параметрами командной строки (F2003). Const 14:10, 24 апреля 2006 (UTC)
Что такое ООП - каждый понимает по-своему (особенно палестинцы). С точки зрения концепции - это примерно так: есть только объекты, они взаимодействуют между собой, посылая друг другу сообщения. У объектов есть методы, которые сидят внутри объектов и действуют почти как "черный ящик". По крайней мере, вовсе не обязательно знать, как они действуют, чтобы вовлечь их в действие. Еще в объектах сидят данные, и в идеально проведенном ООП эти данные снаружи не доступны, это - внутренние поля объектов. Называется это дело "инкапсуляция". Так что чтобы обработать какие-то данные в ООП, надо забить всю обработку в один объект, чтобы он обменивался с другими объектами сообщениями, но не данными. Это можно сделать. Только вот сомневаюсь, что обработка данных внутри этого объекта будет реализована с точки зрения ООП. То есть с наружи будет ООП, а внутри - процедурное программирование.
Теперь по поводу элементов ООП в Фортране. Опять же не очень понятно, что считать этими элементами. Обычно говорят, что ООП реализуется через инкапсуляцию, наследование и полиморфизм. Еще перегрузкой операторов обычно щеголяют. Вот перегрузка (т.е. переназначение) операторов была в Фортране с самого начала. Можно было определить собственную подпрограмму-функцию Sin(x), чтобы она считала, к примеру, квадратный корень из числа. И будет считать! По крайней мере, должна. Просто встроенная функция Sin(x) будет недоступна. Правда, у меня g77 ругается на фокусы подобного рода, но с точки зрения стандарта вроде не должен.
А со всем остальным вроде бы ясно. Инкапсуляция при обработке данных только мешает обменом результатами вычислений между блоками программы. Наследование + полиморфизм НЕ РАБОТАЮТ, потому что нет классов. Структуры - это фишка, не имеющая никакого отношения к ООП. Просто она требует более сложной работы с памятью, чем была реализована в Фортране до F90. Структуры запросто используются в языках, не относящихся к ООП: классическом Паскале, бейсике (например, QBasic, PowerBasic). 
Короче, где же они, эти элементы?

text: Согласен с предыдущим оратором. Отнесение Фортрана в категорию объектно-ориентированных языков дезориентирует читателя. Может, после долгой эволюции какой-нибудь фортран-2038 и можно будет записать в объектно-ориентированные с полным правом, но пока ещё до этого дойдёт... --V1adis1av 10:44, 28 апреля 2006 (UTC)
replies: text: :Вот тут, например, эти элементы описаны...  Const 21:23, 28 апреля 2006 (UTC)

text: 195.19.226.194, подписывайтесь, пожалуйста. 
А теперь по делу. Концепчия ООП, как вы говорите, подразумевает объекты, обменивающиеся сообщениями, так? Так кто вам мешает написать для хранения внутренних данных объекта структуру, и реализовать набор операций над ней, ответственный за прием этих самых сообщений? То, что данные не доступны снаружи, можно реализовать и по-другому - договорившись их не использовать напрямую. (Или программисты тупы и слов не понимают, надо, чтобы компилятор обругал?) Если вам нужна инкапсуляция - никто не мешает делать вложенные структуры и т.п. То же самое касается и наследования, посмотрите статью по ссылке, приведенной Const. Vasiliev Mihail 21:46, 28 апреля 2006 (UTC)
Можно было бы сказать очень коротко: объекты - это экземпляры классов, если классов в Фортране нет, то и ООП нет. Цитата из книжки С. Немнюгина и О. Стесик "Современный фортран", стр. 8: "Фортран является языком программирования высокого уровня. Он относится к категории императивных языков и изначально создавался для программирования вычислений". Императивных - в смысле процедурных. Но поскольку вы дружно суете мне в нос препринт Горелика, я на основании этого препринта буду говорить подробно, и даже очень подробно. 
А.М. Горелик рассматривает некоторые фишки, появившиеся в Фортране, и рассмотрение это идет по одной и той же схеме: в Фортране-77 этого не было, в Фортране-90,95 это есть, и рассматриваемая фишка - признак объектно-ориентированного программирования. При этом он сплошь и рядом оказывается не прав: или данная фишка уже была в Фортране-77, или она исключена из Фортрана-95, или, чаще всего, она не имеет никакого отношения к ООП. Собственно, основная проблема заключается во 2-м разделе препринта, где перечислены основные концепции ООП. Что-то их подозрительно много по сравнению со стандартной, почти Гегелевской триадой: инкапсуляция - наследование - полиморфизм. И что-то дяденька стыдливо умалчивает, что реализуются эти самые концепции ООП через классы. Да, в препринте сказано: "Механизм инкапсуляции для реализации абстрактных типов данных", но что это за "абстрактные типы", понимай как хочешь. 
Теперь подробнее по списочку "основных концепций ООП". Статический контроль соответствия формальных и фактических аргументов при вызове процедур - это что, действительно фишка, присущая только ООП? Ну, г-н Горелик не осмеливается это утверждать так прямо, он пишет: "Для ООП важным является наличие в языке возможности статического контроля соответствия ..." А для программирования в рамках других концепций  это не является важным? Почему бы не сказать: "Для ООП важным является использование математического сопроцессора", и не отнести эту фишку к основным концепциям ООП?
Еще подробнее. К этой "основной концепции" отнесено явное объявление переменных (А.М. Горелик пишет: "объявление объектов". Не объектов, а переменных!) и оператор IMPLICIT NONE, а также возможность проверки соответствия типов формальных и фактических аргументов. В общем-то, в Фортране описание переменных по умолчанию было всегда, это роднит его с бейсиком. И никто не запрещает поступать так и в Фортране-95, наплевав на IMPLICIT NONE, это уже личное дело самого программиста. Причем утверждение г-на Горелика о том, что оператор IMPLICIT NONE введен в Фортран-90,95 не соответствует действительности, он был еще в Фортране-77. Заявляю об этом на основании руководства программирования на Фортране-77 от Sun Microsystems, там не сказано, что эта фишка относится к нестандартным расширениям языка Фортран-77. Ну и компилятор g77 вполне понимает IMPLICIT NONE.
Далее: "В Фортране 77 интерфейс с вызываемой внешней процедурой был только неявным... В Фортран 90/95 для внешних процедур может быть задан явный интерфейс". Это справедливо. И это очень хорошо. Но при чем здесь ООП? Только ООП позволяет нам работать со внешними процедурами? Я уже говорил: пока задаваемый интерфейс не перешел в интерфейсный класс, об ООП говорить нет никаких оснований. В том же самом g77 с помощью нестандартных расширений языка можно задавать способ передачи аргумента (по ссылке или по значению) и нормально работать с внешними процедурами, если они поддерживают C calling convention. А если STDCALL, то уже не пройдет. Но это не из-за того, что в g77 не хватает ООП, а потому, что он делался на основе gcc и под Linux, там все вызывается единообразно.
Теперь - типы данных, определяемые пользователем. "Для ООП в языке необходимы средства, позволяющие добавлять определяемые пользователем типы данных". Это совершенно справедливо. Но вовсе не означает, что такие средства нужны только для ООП, и тем более, что их наличие - признак ООП. Это просто удобный способ представления данных. Да, в стандарте Фортрана-77 их не было, но многие компиляторы их поддерживали в качестве нестандартного расширения языка. Например, компилятор Фортрана-77 от Sun Microsystems (включая вложенные структуры). Поддержки подобных вещей у g77 нету. 
Определяемые операции и присваивания. Программеры на ООП языках очень носятся с этой фишкой, особенно с так называемой перегрузкой операторов. Ну, если надо, то почему бы не использовать такую штуку? Но причем здесь ООП? Поскольку в Фортране фактически нет зарезервированных слов, название любой встроенной функции можно переопределить в качестве названия собственной подпрограммы, которая будет вычислять нечто совсем другое, и такая штука была возможна в Фортране всегда. Что теперь, на этом основании будем зачислять FORTRAN IV в объектно-ориентированные языки программирования?
Инкапсуляция и абстракция данных. "Фундаментальной идеей ООП является инкапсуляция данных и соответствующих операций" - пишет неугомонный А.М. Горелик. Не до конца написал, дяденька! Надо бы дополнить: инкапсуляция данных внутри класса, в качестве полей и методов класса - вот что является фундаментальной идеей ООП! Далее: "Инкапсуляция в Фортране 90/95 реализуется с помощью модулей ... и различных механизмов динамического размещения объектов". Так какое же это ООП? Это из области модульного  подхода к программированию, как в Borland Pascal. Разве что если трактовать понятие класса черезчур расширенно: "В такой трактовке в Фортране 90/95 аналогом класса является модуль, содержащий одно описание производного типа и описание операций над данными этого типа". Ну да, таким образом можно изобразить некое подобие класса, мягко говоря, через ж... И работать с ним придется через ж..., поскольку сам язык не имеет встроенных средств для работы с классами.
Про динамическое размещение переменных (не объектов!) в памяти требуется еще поговорить особо. "Наличие различных механизмов динамического размещения объектов также обеспечивает поддержку инкапсуляции и абстракции данных". Справедливо. Но использоваться эти фишки могут и для многих других надобностей. Зачем все к инкапсуляции сводить? "Инкапсуляция достигается за счет того, что размер массива, создание и освобождение (уничтожение) производятся в самой процедуре и при вызове об этом можно не заботиться. Массивы, которые необходимы только в процедуре, скрыты внутри этой процедуры, и остальная программа не должна их касаться." Извиняюсь, но массивы, создаваемые внутри процедуры и недоступные извне ее, были в Фортране очень давно. Опять FORTRAN IV будем записывать в объектно-ориентированные языки? "В Фортране 77 не допускались массивы переменной длины". В основной программе - да, но применительно к случаю, рассматриваемому А.М. Гореликом - передачи массива в процедуру в качестве параметра - это не верно, пояснения будут потом.
И так, в качестве механизмов динамического размещения массивов рассматриваются "автоматические массивы, границы которых вычисляются при входе в процедуру; размещаемые массивы, границы которых вычисляются при выполнении программы; массивы, создаваемые в процессе выполнения программы, т.е. массивы, которые не были заранее явно объявлены в программе". Все правильно, идем дальше. "Если в процедуре появляется временный массив, с переменными границами, который используется только внутри процедуры, в Фортране 77 он должен быть формальным аргументом". А вот это - полная чушь! Не надо путать Фортран с ранними версиями Бейсика или Паскаля! Про FORTRAN IV не уверен, но Фортран-77 точно позволяет описывать в подпрограммах временные масивы, недоступные извне подпрограммы. "В приведенном примере массивы X и Y – массивы с передаваемой конфигурацией. Это тоже новая черта Фортрана 90/95; конфигурация формального аргумента перенимается у фактического." Опять неточность, даже две. Массивы с передаваемой конфигурацией появились еще в Фортране-77, а из стандарта Фортрана-95 они, хе-хе, были исключены. Теперь размещаемые массивы - которые создаются через ALLOCATE. Да, такой фишки не было в Фортране-77. Только вот, если вспомнить, был такой язык - Алгол-60. И в нем эти размещаемые массивы были самым заурядным делом. И не надо было даже использовать команды ALLOCATE - DEALLOCATE. Просто объявлялась целочисленная переменная, а строчкой ниже - массив, в качестве границы которого записывалась эта переменная. И все. Если к тому времени, когда массив начинал использоваться, значение этой целочисленной переменной оказывалось определено - никаких проблем. Как, запишем Алгол-60 в число объектно-ориентированных языков? Про массивы, создаваемые в процессе выполнения программы, А.М. Горелик не пишет ничего. Жалко. Это какая-то сугубо эзотерическая фишка. Вроде она в стандарт прописана, и все про нее упоминают, но я ни в одной книге, ни в одном руководстве для программиста на Фортране не смог найти ни одного практического примера, как этой фишкой пользоваться. В лучшем случае говорят: пользуйтесь вместо них размещаемыми массивами, это проще и не создает лишних хлопот. В общем, не ходите, дети, в Африку гулять. Вот и г-н Горелик ничего про них не смог найти.
Далее идет полиморфизм. "Примером полиморфизма может служить операция деления в Фортране". Ну да, и не только она. В языке FORTRAN IV были отдельные функции для вещественных аргументов и для аргументов удвенной точности, типа SIN(X) - DSIN(X). В Фортране-77 (а может, еще раньше, не знаю) уже можно использовать одну функцию для разных типов аргументов. Так что такой статический полиморфизм поддерживался задолго до Фортрана-90/95. Вот операции над массивами, записываемые так же, как и над скалярными величинами - да, это только с Фортрана-90. И необязательные параметры процедур - тоже.
Следующими пунктами идут наследование и динамический полиморфизм. "Полное наследование в явном виде не поддерживается, но может быть смоделировано." "В явном виде динамический полиморфизм в Фортране 90/95 отсутствует, но может быть смоделирован, хотя не всегда это сделать просто." Может, не стоит и заморачиваться?
Выводы из вышесказанного:
1. Данный препринт является наглой агиткой на тему "Объектно-ориентированное программирование - светлое будущее всего человечества". До ООП программеры просто лаптем щи хлебали, не могли ни с внешними процедурами работать, ни использовать динамическую память, ни объявлять пользовательские типы. И вообще сидели на одних перфокартах.
2. Фортран-77 - это все-таки не диагноз, а вполне нормальный язык программирования, пусть и с явными ограничениями. Из препринта видно, что г-н Горелик не знает Фортрана-77, и никогда на нем не программировал. Скорее всего, и на Фортране-90/95 тоже. В общем, это явно программист на С++, который полез копаться в Фортране, чтобы выяснить, а нельзя ли в него встроить ООП. Вот вынесенный вердикт: "Мы показали, что Фортран 90/95 поддерживает многие черты полезные для ООП ..." - только полезные для, а не само ООП! "Это позволяет реализовать все важные концепции ООП, хотя в некоторых случаях с большими усилиями чем в объектно-ориентированных языках." Обратите внимание: здесь сам г-н Горелик исключает Фортран из числа объектно-ориентированных языков! И он совершенно прав!
Так что все эти пользовательские типы, динамические массивы, интерфейсы и прочие примочки еще не делают Фортран объектно-ориентированным языком. Ибо они реализуются отнюдь не через классы и объекты. А выискивать элементы ООП при отсутствии самих объектов - это уже идеология в чистом виде. То есть идиотизм.

text: И снова повторюсь: подписывайтесь!

text: Теперь по существу. Откуда такая злоба на ООП в частности и на оное же в Фортране конкретно, что вы совершенно не слушаете оппонентов? Гораздо выше звучали имя и отчество «г-н Горелик» и в соответсвии с ними (Алла Моисеевна) выходит не «г-н», а «г-жа»... Насчет незнания Фортрана единственным российским членом международного комитета по стандартизации Фортрана... звучит забавно.

text: Если будете настаивать, пройдусь по вашим ошибкам и незнанию предмета (да-да! вы как минимум не знаете стандарта языка, о котором берётесь судить).

text: И не упоминайте более книгу Немнюгина и Стесик: там слишком много ошибок, а единственное место, где использован документ комитета по стандартизации фортрана страдает отсутсвием ссылки на первоисточник (это называется плагиат) и наличием фактических ошибок («Мне Мойша Битлов напел» вспоминается). Const 17:18, 8 мая 2006 (UTC)

text: И еще раз, я правильно понимаю, что вы считаете, что ООП-язык обязательно должен иметь конструкции типа (в терминах фортрана)
 type(superclass)
   integer field
   subroutine dosomething(a,b,c)
 end type

text: и что без этого ( а также полиморфизма и наследования) говорить об объектно-ориентированности бессмысленно? Ну, тогда действительно, Fortran-не ОО-язык. Но я все же считаю, что OO - свойство не языка, но мышления. И к ОО-языкам следует относить все, на которых это мышление может быть реализовано без больших сложностей. А то, что в C++ и Java методы "спрятаны" внутри объектов - это не более, чем синтаксический трюк. Vasiliev Mihail 16:33, 11 мая 2006 (UTC)
Подскажите, пожалуйста, несколько хороших форумов по Фортрану? Гость 27/11/06
Несколько - не знаю, а один вполне живой могу указать. Там, правда, не только один Фортран:
http://forum.vingrad.ru/index.php - раздел "Красная книга" - "Разное".
В общем, ссылочки на форумы были бы в статье полезны. Может, кто-то еще подбросит?
=================
Тон, выбранный анонимом при обсуждении ООП в Фортране, возмутителен.
Вырванные из контекста цитаты и произвольная их трактовка, грубые ошибки и незнание стандартов языка – все это не выдерживает никакой критики.
Создается впечатление, что грубостью аноним хочет прикрыть некомпетентность  в вопросах, которые пытается обсуждать.
А теперь по существу. ООП – это методология программирования, которая в ряде случаев облегчает разработку программ, в т.ч. и программ для решения вычислительных задач. В Фортране 90/95 имеется много полезных средств, которые могут быть использованы для решения разных проблем, включая и реализацию методологии ООП.  Фортран 2003 (а не 2038 !) уже содержит полный набор средств для реализации ООП.  Кстати, пример конструкции, который приводит Vasiliev Mihail, – неверен. Это делается иначе.
Что касается статьи о Фортране в целом. Неточности и ошибки, много внимания уделяется несущественным (даже устаревшим) чертам и не отмечаются важные преимущества языка.
Возмутительный тон обсуждения ООП не позволяет принять участие в улучшении статьи; не хочу, чтобы любой неспециалист правил мой текст.
Удивляюсь, почему на сайте допускается такой тон, тем более, что IP-адрес анонима известен. [[Участник: Фортранщик 17.12.2006
* Вы меня извините, но мне кажется, что поведение анонимов - не повод не улучшать статью. А если ваши правки систематически откатываются - это повод для обращения к администраторам. Да, кстати - я и не претендую на точность фрагмента - почитайте окружающий текст - этот фрагмент как раз и показывает, КАК в фортране НЕ делается. И ровно поэтому фрагмент приведен в обсуждении, а не в статье. То, что то же самое делается по-другому, я отчетливо понимаю, но объяснить людям с Java/C++ мышлением, что метод класса не обязан описываться в описании класса - довольно трудно :) Vasiliev Mihail 07:53, 21 декабря 2006 (UTC)
* Off: Зарегистрируйтесь, что ли - это удобно и позволяет легко отличаться от абстрактных анонимов. IP-адрес - не всегда надежная ссылка на личность. Vasiliev Mihail 07:55, 21 декабря 2006 (UTC)
==============
thread_title:  «Старое» обсуждение 

message: Тон, выбранный анонимом при обсуждении ООП в Фортране, возмутителен.
Вырванные из контекста цитаты и произвольная их трактовка, грубые ошибки и незнание стандартов языка – все это не выдерживает никакой критики.
Создается впечатление, что грубостью аноним хочет прикрыть некомпетентность  в вопросах, которые пытается обсуждать.
А теперь по существу. ООП – это методология программирования, которая в ряде случаев облегчает разработку программ, в т.ч. и программ для решения вычислительных задач. В Фортране 90/95 имеется много полезных средств, которые могут быть использованы для решения разных проблем, включая и реализацию методологии ООП.  Фортран 2003 (а не 2038 !) уже содержит полный набор средств для реализации ООП.  Кстати, пример конструкции, который приводит Vasiliev Mihail, – неверен. Это делается иначе.
Что касается статьи о Фортране в целом. Неточности и ошибки, много внимания уделяется несущественным (даже устаревшим) чертам и не отмечаются важные преимущества языка.
Возмутительный тон обсуждения ООП не позволяет принять участие в улучшении статьи; не хочу, чтобы любой неспециалист правил мой текст.
Удивляюсь, почему на сайте допускается такой тон, тем более, что IP-адрес анонима известен. [[Участник: Фортранщик 17.12.2006
* Вы меня извините, но мне кажется, что поведение анонимов - не повод не улучшать статью. А если ваши правки систематически откатываются - это повод для обращения к администраторам. Да, кстати - я и не претендую на точность фрагмента - почитайте окружающий текст - этот фрагмент как раз и показывает, КАК в фортране НЕ делается. И ровно поэтому фрагмент приведен в обсуждении, а не в статье. То, что то же самое делается по-другому, я отчетливо понимаю, но объяснить людям с Java/C++ мышлением, что метод класса не обязан описываться в описании класса - довольно трудно :) Vasiliev Mihail 07:53, 21 декабря 2006 (UTC)
* Off: Зарегистрируйтесь, что ли - это удобно и позволяет легко отличаться от абстрактных анонимов. IP-адрес - не всегда надежная ссылка на личность. Vasiliev Mihail 07:55, 21 декабря 2006 (UTC)
thread_title: =====

thread_title: ==