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

Про упорядочивание

Господа, прошу разрешить мне отправить старые обсуждения (особливо ООП) в архив вида Обсуждение:Фортран/Архив, оставив здесь лишь ссылку. Затем я хочу начать новое обсуждение, ибо в текущем виде статья вызывает у меня глухое раздражение, но есть ощущение, что в одиночку не потяну исправления.Const 19:55, 24 марта 2007 (UTC)

Полностью поддерживаю. Удалить всю грязь, но не помещать в архив, а удалить полностью. Такие "обсуждения" не украшают российских программистов. Посмотрите в Google на англ.яз. по поводу Fortran и OOP - много публикаций, в т.ч. и статья автора, которого здесь облили грязью (статья переведена на англ. яз. и опубликована в зарубежном журнале). Ваше раздражение по поводу статьи в Википедии мне понятно. Помогу, если не будет грязи. Для начала два примера. Положительный пример - статья в англ. Википедии. Отрицательный пример - wiki.vingrad. Участник:Фортранщик

Уважаемый фортранщик (коллега?), у меня есть к вам несколько просьб:

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

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

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

Const 19:55, 24 марта 2007 (UTC)

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

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

«Старое» обсуждение

Про то, что сейчас на фортране мало пишут - это вы зря. Просто он как жил в своей мало распространенной нише (численные расчеты, моделирование и т.п.), так и живет. И очень удобен в этом классе задач.

Я это знаю и сейчас постепенно правлю статью до истинного положения вещей. --Const 07:32, 2 ноября 2005 (UTC)

Нужно-ли про плаканкюль здесь? Const 09:41, 28 ноября 2005 (UTC)

А что это?Vasiliev Mihail 21:02, 29 ноября 2005 (UTC)

Второе предложение кто-то вставил: «(Язык Планкалкюль был изобретён ещё в 1945 году, но не был реализован вплоть до 2000 года.)» Const 04:56, 30 ноября 2005 (UTC)

Тоже не уверен есть ли необходимость писать про Планкалкюль, автор вероятно хотел сказать, что Планкалкюль является первым языком высокого уровня, но так и не был реализован длительное время, поэтому Fortran является фактически первым языком высокого уровня. Здесь необходимо либо развернуть мысль, либо вообще Планкалкюль убрать - я чуть-чуть поправил, но мне не очень нравится...Cheops 01:59, 2 декабря 2005 (UTC)

На счет ООП в статье - это зря. На самом деле Фортран к ООП отношения не имеет. Есть возможность ИМИТИРОВАТЬ многие объектно-ориентированные фишки, но по сути ООП к Фортрану пристегнуто быть не может. Основное приложение Фортрана - численные рассчеты, так всегда было и всегда будет. И реализовать их удобнее на чисто процедурном языке, без всяких объектно-ориентированных прибамбасов. Они будут только мешать. Как-то это ООП не хочет уживаться с численными алгоритмами. Возьмите любую книгу, в которой обсуждаются вычислительные алгоритмы с точки зрения ООП, например, на Паскале. Можно гарантировать, что там будут разные алгоритмы перебора, ветвления, сортировки, и закончится все это... Ну, те, кто брал в руки такие книги, знают, чем они кончаются. Те, кто не брал, наверно, не поверят: алгоритмом игры "Ханойские башни". Везде. Во всех таких книгах. А вот если надо алгоритм разложения в ряд Фурье - это не к нам, это смотрите на Фортране.

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

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

Ну, объектно-ориентированность помогает далеко не всякому параллелизму. Написать баллансирование нагрузки для программы со сложной объектной структурой ой-как нетривиально. Другое дело, что чисто-процедурный подход предполагает гораздо более простые модели взаимодействия данных. Vasiliev Mihail 19:27, 21 апреля 2006 (UTC)

ООП - это не свойство языка, это свойство мышления. Язык (любой) лишь дает более или менее удобные средства для ОО-мышления. Vasiliev Mihail 19:27, 21 апреля 2006 (UTC)

Так я и не утверждаю, хорошо это или плохо.. Я просто комментирую замечание ув. Анонима: ООП в Фортране частично присутствует — раз; ООП в очередном стандарте Фортрана ожидается полноценным — два.

А использовать или нет эту возможность — личное дело каждого. Так, я — не использую. Мне более по душе структуры данных (F90), конструкция FORALL (F95) и умение работать с параметрами командной строки (F2003). Const 14:10, 24 апреля 2006 (UTC)

Что такое ООП - каждый понимает по-своему (особенно палестинцы). С точки зрения концепции - это примерно так: есть только объекты, они взаимодействуют между собой, посылая друг другу сообщения. У объектов есть методы, которые сидят внутри объектов и действуют почти как "черный ящик". По крайней мере, вовсе не обязательно знать, как они действуют, чтобы вовлечь их в действие. Еще в объектах сидят данные, и в идеально проведенном ООП эти данные снаружи не доступны, это - внутренние поля объектов. Называется это дело "инкапсуляция". Так что чтобы обработать какие-то данные в ООП, надо забить всю обработку в один объект, чтобы он обменивался с другими объектами сообщениями, но не данными. Это можно сделать. Только вот сомневаюсь, что обработка данных внутри этого объекта будет реализована с точки зрения ООП. То есть с наружи будет ООП, а внутри - процедурное программирование.

Теперь по поводу элементов ООП в Фортране. Опять же не очень понятно, что считать этими элементами. Обычно говорят, что ООП реализуется через инкапсуляцию, наследование и полиморфизм. Еще перегрузкой операторов обычно щеголяют. Вот перегрузка (т.е. переназначение) операторов была в Фортране с самого начала. Можно было определить собственную подпрограмму-функцию Sin(x), чтобы она считала, к примеру, квадратный корень из числа. И будет считать! По крайней мере, должна. Просто встроенная функция Sin(x) будет недоступна. Правда, у меня g77 ругается на фокусы подобного рода, но с точки зрения стандарта вроде не должен.

А со всем остальным вроде бы ясно. Инкапсуляция при обработке данных только мешает обменом результатами вычислений между блоками программы. Наследование + полиморфизм НЕ РАБОТАЮТ, потому что нет классов. Структуры - это фишка, не имеющая никакого отношения к ООП. Просто она требует более сложной работы с памятью, чем была реализована в Фортране до F90. Структуры запросто используются в языках, не относящихся к ООП: классическом Паскале, бейсике (например, QBasic, PowerBasic).

Короче, где же они, эти элементы?

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

Вот тут, например, эти элементы описаны... Const 21:23, 28 апреля 2006 (UTC)

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 поддерживает многие черты полезные для ООП ..." - только полезные для, а не само ООП! "Это позволяет реализовать все важные концепции ООП, хотя в некоторых случаях с большими усилиями чем в объектно-ориентированных языках." Обратите внимание: здесь сам г-н Горелик исключает Фортран из числа объектно-ориентированных языков! И он совершенно прав!

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

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

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

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

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

И еще раз, я правильно понимаю, что вы считаете, что ООП-язык обязательно должен иметь конструкции типа (в терминах фортрана)

type(superclass)
  integer field
  subroutine dosomething(a,b,c)
end type  
  

и что без этого ( а также полиморфизма и наследования) говорить об объектно-ориентированности бессмысленно? Ну, тогда действительно, 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)

убрать ссылку =

Предлагаю отменить последнюю правку - добавление ссылки. На указанном в этой ссылке сайте нарушены авторские права. Автор сайта не является автором представленного материала (сам признается), имена авторов нигде не указаны, хотя и указано,что copyright якобы принадлежит автору сайта. Качество представленного на сайте материала(особенно переводов)даже не хочу обсуждать.195.28.50.41 10:31, 20 января 2008 (UTC)alexandr

• ВП:КОИ --Saramag 08:35, 29 июля 2015 (UTC)

Таблицы языковых структур

Итак, есть такой вопрос. Хотелось-бы подготовить таблицы языковых структур для разных версий Фортрана (66-77-90-95-2003-). Для проследних версий эти таблицы должны содержать, естественно, множества нерекомендованных и исключённых структур. Как вы думаете, имеет смысл такая работа? Const 16:43, 7 апреля 2007 (UTC)

Если я правильно представляю, во что это выльется, то в рамках статей в Википедии это не лучший вариант. Возможно, стоит проводить такую работу в рамках Викитеки, либо Викиучебника, но я ни с тем, ни с другим активно не работал, так что могу и ошибаться. ~ putnik 03:39, 8 апреля 2007 (UTC)

Я попробую подготовить такую таблицу в личном пространстве... а там решим, куда её деть.. Мне оно интересно сделать. Const 17:27, 8 апреля 2007 (UTC)

По поводу таблиц

1. Такие таблицы можно найти в литературе по Фортрану. Зачем изобретать велосипед?

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

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

--83.167.112.28 04:25, 8 апреля 2007 (UTC)Фортранщик

Обсуждения не удаляются. ~ putnik 05:01, 8 апреля 2007 (UTC)

Хотелось бы ссылок на информацию (доступную, желательно, возможно, в инете, а не на бумаге) по составу языка Fortran-66... Ну и замечу, что такая (для меня) интересная информация размазана ровным слоем по мноигим учебникам :( Const 17:25, 8 апреля 2007 (UTC)

1. Такие таблицы действительно существуют и охраняются авторским правом (copyright).

2. Серьезные работы делают не на базе информации в учебниках или в Интернете, а на базе первоисточников (в данном случае - на основе описаний стандартов на англ. яз.).

3. Вы, кажется, намеревались улучшить статью, которая вызвала у Вас "раздражение".

195.28.50.41 09:08, 9 апреля 2007 (UTC)Наблюдатель

Старые обсуждения

Старые обсуждения перенесены в Архив. —BelomoeFF^® 04:00, 7 апреля 2007 (UTC)

"Регистр значения не имеет"

«множество прописных букв и множество строчных букв при написании операторов языка совпадают» - блин, даже интересна целевая аудитория этого выражения )) --178.216.127.205 23:21, 9 сентября 2011 (UTC)

Любой кто знает что такое множество 91.124.40.72 15:36, 10 сентября 2011 (UTC)