Re: Вопрос отцам Фортрана.
ООП в фортране по-моему уже давно есть.
в каком конкретно?
фамилии, явки.
фамилии, явки.
Стандарт принят. Реализаций нет.
В 90,95-ом есть поддержка ООП (не полная).
В 90,95-ом есть поддержка ООП (не полная).
Да, еще с начала 90-х есть всякие операторы include,
interface и прочие.
Есть и работа с динамической памятью - allocate/deallocate.
Фортран становится похожим на Си.
См. описание языка.
interface и прочие.
Есть и работа с динамической памятью - allocate/deallocate.
Фортран становится похожим на Си.
См. описание языка.
Только вот все тобою описанное к ООП никакого отношения не имеет.
Даже interface, так как тут он относится только к подпрограммам.
Даже interface, так как тут он относится только к подпрограммам.
А что, по-твоему, делает include? Разве не объектно ориентирует программирование? 
Про остальные согласен. Я лишь упомянул их в связи с Си-зацией Фортрана.
Про остальные согласен. Я лишь упомянул их в связи с Си-зацией Фортрана.
А что, по-твоему, делает include?Тот, который я знаю, делает тупую подстановку содержимого одного файла в другой (причем даже не условную).
Такое используется, когда почему либо в куче файлов нужно, чтобы был одинаковый кусок и чтобы его не дублировать.
И называется это модульное программирование (модуль можно считать предком класса, но это еще далеко не класс).
Или ты про какой-то другой include?
Разве не объектно ориентирует программирование?Модульно - ориентирует, объектно - нет.
Я лишь упомянул их в связи с Си-зацией Фортрана.Сколько угодно, но неужели ты считаешь Си объектно-ориентированным?
Нет, у меня обо всем этом представление интуитивное и скорее практическое.
По мне - так любая подпрограмма, которую ты вызываешь, уже элемент сегментного
(назовем это так) программирования. Что-то типа разделения труда в экономике.
Смысл в том, что ты начинаешь программирование уже с некоторого ненулевого
уровня, когда часть проблем уже решена за тебя и до тебя. Ты можешь что-то
специальное вызвать и пользоваться, не надо выдумывать этот кусок самому.
Простейший пример - человек вызвал из библиотеки встроенную экспоненту и
посчитал по ней, вместо того, чтобы самому изучать область "сходимости" ряда
Тейлора и других аппроксимаций и т.п. Мне так понятнее.
По мне - так любая подпрограмма, которую ты вызываешь, уже элемент сегментного
(назовем это так) программирования. Что-то типа разделения труда в экономике.
Смысл в том, что ты начинаешь программирование уже с некоторого ненулевого
уровня, когда часть проблем уже решена за тебя и до тебя. Ты можешь что-то
специальное вызвать и пользоваться, не надо выдумывать этот кусок самому.
Простейший пример - человек вызвал из библиотеки встроенную экспоненту и
посчитал по ней, вместо того, чтобы самому изучать область "сходимости" ряда
Тейлора и других аппроксимаций и т.п. Мне так понятнее.
Наверное тебе просто не попадалось сложных задач или у тебя талант к их декомпозиции 
Или ты не пробовал делать свои кирпичики, а лишь довольствовался готовыми.
Когда-нибудь тебе наверняка встретится задача, которая заставит перейти тебя от интуитивного представления к пониманию.
Хотя наверняка бывают гении интуитивного программирования (или ты просто забьешь на это все раньше).
Или ты не пробовал делать свои кирпичики, а лишь довольствовался готовыми.
Когда-нибудь тебе наверняка встретится задача, которая заставит перейти тебя от интуитивного представления к пониманию.
Хотя наверняка бывают гении интуитивного программирования (или ты просто забьешь на это все раньше).
И при чем здесь ООП? Кто обект?
Дай, плиз, определение ООП, и я тебе отвечу.
Нехуй делать. ООП - Объектно ориентированное программирование. Жду ответа.
Сложные задачи для фортрана - это длинные программы, тысячи и десятки тысяч
операторов, реализующие численные методы, причем не один, а обычно несколько
сразу. Плюс работа с большими массивами данных, управление памятью и вводом-
выводом. Для этой цели частично используются средства самого фортрана, частично
- специальные модули на Си и на ассемблере, которые отдельно разрабатываются
под разные платформы и прилинковываются.
Сам я, конечно, писал программы попроще, но видел и такие, и работал на них. И людей, программирующих сие на фортране, видел и знаю. Фортран среди людей, решающих
непростые вычислительные задачи, все еще в ходу, и разумной альтернативы ему,
похоже, так и не придумали. Хотя язык хитрый и требует известной изворотливости
(см. соседний пост про считывание из файла).
Что же касается ООП, то практикам программирования еще предстоит оценить
преимущества такого стиля работы. Для начала неплохо бы выяснить, что же это
все-таки такое.
Что касается вычисления экспоненты - кто не считает это серьёзной задачей, пусть
попробует сам написать алгоритм ее вычисления, численно пригодный (устойчивый) в
широком диапазоне значений x. Можно функцию Бесселя или erf. Поработайте
с суммированием знакопеременного ряда
, поизучайте Паде-аппроксиманты и
цепные дроби...
Почувствуете вкус программирования в исконном значении этого слова
операторов, реализующие численные методы, причем не один, а обычно несколько
сразу. Плюс работа с большими массивами данных, управление памятью и вводом-
выводом. Для этой цели частично используются средства самого фортрана, частично
- специальные модули на Си и на ассемблере, которые отдельно разрабатываются
под разные платформы и прилинковываются.
Сам я, конечно, писал программы попроще, но видел и такие, и работал на них. И людей, программирующих сие на фортране, видел и знаю. Фортран среди людей, решающих
непростые вычислительные задачи, все еще в ходу, и разумной альтернативы ему,
похоже, так и не придумали. Хотя язык хитрый и требует известной изворотливости
(см. соседний пост про считывание из файла).
Что же касается ООП, то практикам программирования еще предстоит оценить
преимущества такого стиля работы. Для начала неплохо бы выяснить, что же это
все-таки такое.
Что касается вычисления экспоненты - кто не считает это серьёзной задачей, пусть
попробует сам написать алгоритм ее вычисления, численно пригодный (устойчивый) в
широком диапазоне значений x. Можно функцию Бесселя или erf. Поработайте
с суммированием знакопеременного ряда
, поизучайте Паде-аппроксиманты и цепные дроби...
Почувствуете вкус программирования в исконном значении этого слова
Определение есть дефиниция. Расшифровка буквограммы чести не делает
P.s. Матерщину прибереги для пивной.
P.s. Матерщину прибереги для пивной.
То, о чем ты говоришь - не сложность программы, а ее длина. Сложность написания, человеко-часы, условно говоря.
ООП начинается с виртуальных методов, это какой-то умный мужик сказал.
ООП начинается с виртуальных методов, это какой-то умный мужик сказал.
Короче не знаешь о чем говоришь, так и запишем. Много слов, по делу ноль.
> ООП начинается с виртуальных методов
Виртуальные методы - это обычная абстракция кода с поздним связыванием, которая вовсе не требует поддержки ООП от языка, так как сильно удобнее делается с помощью closures.
Виртуальные методы - это обычная абстракция кода с поздним связыванием, которая вовсе не требует поддержки ООП от языка, так как сильно удобнее делается с помощью closures.
здесь
Вот, кстати, по делу.
Вот, кстати, по делу.
> ООП начинается с виртуальных методов, это какой-то умный мужик сказал
тут я с ним согласен (хотя, конечно, теоретик программирования из меня никудышный). Другие фишки ооп не особо отличаются от модульного программирования.
а вообще, если ссылаться на классиков, то кто-то навроде Буча утверждал: соль ООП в том, что объекты взаимодействуют через сигналы. То есть, видимо, Буч считал, что главное отличие - инкапсулирование.
тут я с ним согласен (хотя, конечно, теоретик программирования из меня никудышный). Другие фишки ооп не особо отличаются от модульного программирования.
а вообще, если ссылаться на классиков, то кто-то навроде Буча утверждал: соль ООП в том, что объекты взаимодействуют через сигналы. То есть, видимо, Буч считал, что главное отличие - инкапсулирование.
Знание численных методов - это хорошо.
Но от знания методологий программирования не освобождает
Насчет ООП - вот что мне не нравится в Фортране - это то, что приходится любую функциональность писать с оглядкой на структуру данных, которая ею обрабатывается
Взять, например, тот факт, что при передаче массивов в подпрограмму приходится передавать и информацию о структуре этого массива, иначе неизбежно рано или поздно возникает проблема, когда на каком-то из уровней передачи что-то происходит не так (неправильно определяется размерность, например) и счет уходит в неправильном направлении (а этот факт ведь еще и понять нужно).
И вообще кол-во параметров в подпрограммах имеет тенденцию к неограниченному увеличению
И как раз ООП эти проблемы и решает
Осталось дождаться нормальной реализации 2003-го стандарта...
Но от знания методологий программирования не освобождает
Насчет ООП - вот что мне не нравится в Фортране - это то, что приходится любую функциональность писать с оглядкой на структуру данных, которая ею обрабатывается
Взять, например, тот факт, что при передаче массивов в подпрограмму приходится передавать и информацию о структуре этого массива, иначе неизбежно рано или поздно возникает проблема, когда на каком-то из уровней передачи что-то происходит не так (неправильно определяется размерность, например) и счет уходит в неправильном направлении (а этот факт ведь еще и понять нужно).
И вообще кол-во параметров в подпрограммах имеет тенденцию к неограниченному увеличению
И как раз ООП эти проблемы и решает
Осталось дождаться нормальной реализации 2003-го стандарта...
Осталось дождаться нормальной реализации 2003-го стандарта...А что, есть какие-то ненормальные?
Я бы посмотрел. Правда.
Ты уж определись
А то ты
А мы посмотрим, как ты с этим справишься
А то ты
А мы посмотрим, как ты с этим справишься
Не, ну вдруг я не все знаю? =)
> Виртуальные методы - это обычная абстракция кода с поздним связыванием, которая вовсе не требует поддержки ООП от языка, так как сильно удобнее делается с помощью closures.
Важное примечание --- не один closure, а сразу несколько, чтобы оперировать общими данными. Тогда вопрос: в чем отличие набора из нескольких closure с общими данными от объекта с виртуальными методами?
Я никаких отличий, кроме названия, не вижу.
Важное примечание --- не один closure, а сразу несколько, чтобы оперировать общими данными. Тогда вопрос: в чем отличие набора из нескольких closure с общими данными от объекта с виртуальными методами?
Я никаких отличий, кроме названия, не вижу.
> Тогда вопрос: в чем отличие набора из нескольких closure с общими данными от объекта с виртуальными методами?
В том, что можно строить произвольные конструкции (типа CLOS а не те, что зашиты в язык.
В том, что можно строить произвольные конструкции (типа CLOS а не те, что зашиты в язык.
Вот за это спасибо.
> В том, что можно строить произвольные конструкции (типа CLOS а не те, что зашиты в язык.
От объекта (или набора closures) можно вызвать метод, или унаследоваться. Больше вроде особых конструкций не видно. Все остальное --- и там, и там надо руками явно писать. Приведи пример, так непонятно.
От объекта (или набора closures) можно вызвать метод, или унаследоваться. Больше вроде особых конструкций не видно. Все остальное --- и там, и там надо руками явно писать. Приведи пример, так непонятно.
Знание численных методов - это хорошо.Да я не спорю, но вот смотрю соседние дискуссии, и как-то это все отдает
Но от знания методологий программирования не освобождает
обсуждением виртуальной реальности. Тем более фортран - язык специфический,
предназначенный именно для решения численных задач. Был бы Си или Си++ -
вопроса бы не возникло: может, люди коммерческие игры или операционные
системы писать собираются. Ну так не фортране же?
Насчет ООП - вот что мне не нравится в Фортране - это то, что приходится любую функциональность писать с оглядкой на структуру данных, которая ею обрабатываетсяЭта проблема понятна, но решается она только аккуратностью программиста. Что поделать.
Взять, например, тот факт, что при передаче массивов в подпрограмму приходится передавать и информацию о структуре этого массива, иначе неизбежно рано или поздно возникает проблема, когда на каком-то из уровней передачи что-то происходит не так (неправильно определяется размерность, например) и счет уходит в неправильном направлении (а этот факт ведь еще и понять нужно).
Не так переменные опишешь - не те массивы инициализироваться будут.
Интересно, а как с этим в других языках? Неужели там неважно, какие переменные откуда
и куда передаются и чему присваиваются?
То, о чем ты говоришь - не сложность программы, а ее длина. Сложность написания, человеко-часы, условно говоря.Не только. Имеется в виду количество корректно работающих операторов. Можно написать
сколь угодно длинную программу, которая не будет работать, или будет работать
неправильно. Берусь привести массу примеров
ООП начинается с виртуальных методов, это какой-то умный мужик сказал.Вот-вот. Лишь бы ими же и не заканчивалось. Хотя смотря чего хотеть.
Есть, к примеру, очень интересная область априорной оценки затратности или
производительности тех или иных алгоритмов. Но она опять же интересна только
в связи с конкретными прикладными задачами. Например, есть ли алгоритмы
полной диагонализации эрмитовых матриц общего вида размера N*N, которые требуют
менее N^3 действий и т.п. Впрочем, ООП тут, похоже, ни при чем?
От объекта (или набора closures) можно вызвать метод, или унаследоваться. Больше вроде особых конструкций не видно.1. multiple dispatch - с той семантикой, которая нужна в конкретной задаче
2. множественное наследование - опять же с той семантикой, которая нужна
3. другая реализация виртуальных методов - например, для обработки сообщений Windows VMT не особо пригодна, нужен более эффективный словарик
Все остальное --- и там, и там надо руками явно писать.В хорошем языке напишешь руками один раз, а потом будешь использовать. А в типичном ОО - каждый раз будешь писать, в то время как товарищи будут, как в соседнем треде, удивляться, чем же ты недоволен, неужели руки отвалятся?
1. multiple dispatch - с той семантикой, которая нужна в конкретной задачеЭто все из области run-time фич, которые с объектами что-то могут делать. Сам по себе объект ничего не делает. Это примерно как два языка, в обоих есть double, но в одном есть sin, cos, arcsin, arccos, а в другом — нет. IMHO это свойство каких-то библиотек, но не самого типа double. Я это имел ввиду.
2. множественное наследование - опять же с той семантикой, которая нужна
3. другая реализация виртуальных методов - например, для обработки сообщений Windows VMT не особо пригодна, нужен более эффективный словарик
По-поводу 1,2,3 - опять же тут вопрос совместимости. Ты сделаешь свою реализацию VMT, еще кто-то сделает свой VMT --- и всех будут разные VMT. Как это линковать в одну программу? calling convention кто будет согласовывать? У создателей C++ была задача --- сделать один универсальный для всех VMT, чтобы код который написал один программист мог вызывать код, который написал другой программист.
Все твои пункты привязаны к конкретной задаче, поэтому критиковать общие методы бесмысленно. Конкретную задачу всегда можно решить лучше, чем общую. Для конкретных задач в C++ тоже есть фичи, например можно сделать мультиметоды для "своих" классов (см. например Александреску). Можно сделать одним способом, можно другим. Какой лучше --- сильно зависит от задачи. В этом вся и проблема. В языка надо встраивать только те вещи, реализация которых более-менее однозначна и всех устраивает. Почитай Design and Evolution of C++ Страуструпа. Там хорошо написано почему мультиметоды не включили в стандарт. Не потому что не знали как делать, а потому что не могли выбрать реализацию, которая бы устроила всех.
В хорошем языке напишешь руками один раз, а потом будешь использовать. А в типичном ОО - каждый раз будешь писать, в то время как товарищи будут, как в соседнем треде, удивляться, чем же ты недоволен, неужели руки отвалятся?Не вижу, почему надо много раз писать. Написал один раз и все. Например, мультиметоды можно один раз сделать на шаблонах и юзать в куче программ. Со своим VMT - тоже самое. Ботай шаблоны.
Это все из области run-time фич, которые с объектами что-то могут делать. Сам по себе объект ничего не делает. Это примерно как два языка, в обоих есть double, но в одном есть sin, cos, arcsin, arccos, а в другом — нет.Почему сразу run-time? Это и в compile-time можно.
arccos ты в стандартную библиотеку явы запихнёшь, а вот map - уже проблемы, так как нет closures в языке (может, есть уже? я не в курсе)
Ты сделаешь свою реализацию VMT, еще кто-то сделает свой VMT --- и всех будут разные VMT. Как это линковать в одну программу? calling convention кто будет согласовывать?Соглашения нужны, как closures передавать - это нетрудно, в Microsoft как-то справились, и не только.
Для конкретных задач в C++ тоже есть фичи, например можно сделать мультиметоды для "своих" классов (см. например Александреску). Можно сделать одним способом, можно другим. Какой лучше --- сильно зависит от задачи. В этом вся и проблема. В языка надо встраивать только те вещи, реализация которых более-менее однозначна и всех устраивает.Ну а я про что? Объекты (как в яве, например) - это сильно частный случай, соотв. язык, в который они встроены, а closures - нет - сильно неуниверсальный.
Написал один раз и все. Например, мультиметоды можно один раз сделать на шаблонах и юзать в куче программ. Со своим VMT - тоже самое.Шаблоны в С++ - мощная штука, конечно, даже алгоритмически неразрешимые задачи позволяет запрогаммировать
Однако читать это имхо потруднее, чем даже лисп с макросами, и менее ортогонально.
А вот в яве один раз не напишешь, если кодогенератор не делать. Да и в этом случае по 2..3 раза одни и те же названия пишут, где одного достаточно, разве что сразу в gzip encoding кодить
А как примерно ООП сделано в фортране 95? Ссылку не дадите, интересно, как это выглядит. Лучше что-нить in brief.
Вот, можно посмотреть здесь: ссылка .
P.S. Там про фортран 90. 95-тый - это только незначительные добавления к 90-му. В основном связанные с конструкциями для работы с массивами.
О, вот еще клевая ссылка.
Там сравнивают ООП в Си и в Фортране.
P.S. Там про фортран 90. 95-тый - это только незначительные добавления к 90-му. В основном связанные с конструкциями для работы с массивами.
О, вот еще клевая ссылка.
Там сравнивают ООП в Си и в Фортране.
В Си нет ООП. Имеешь ввиду Си++ - так и говори.
Что касается Фортрана-90, то он - не ООП-язык. В той статье, которую ты указал, чёрным по белому сказано- "but it lacks inheritance". ООП - это абстракция данных, инкапсуляция, полиморфизм и наследование. Нет хотя бы чего-нибудь одного из этого - нет ООП. Ботай определения.
Что касается Фортрана-90, то он - не ООП-язык. В той статье, которую ты указал, чёрным по белому сказано- "but it lacks inheritance". ООП - это абстракция данных, инкапсуляция, полиморфизм и наследование. Нет хотя бы чего-нибудь одного из этого - нет ООП. Ботай определения.
О! Вот и еще один фортраноненавистник!
Си поработил твой мозг! (или правильнее С++?)
Си поработил твой мозг! (или правильнее С++?)
Я жаловался.
На самом деле она передается, но как-то криво + криво достается в подпрограммах
Спасибо за ссылку - посмотрю.
На самом деле она передается, но как-то криво + криво достается в подпрограммах
Спасибо за ссылку - посмотрю.
Зачем же так сразу и фортраноненавистник?
Тот факт, что в прошлом веке в фортране не было ООП еще не говорит о предпочтениях
Тот факт, что в прошлом веке в фортране не было ООП еще не говорит о предпочтениях
Фортранофил, я же говорю - ботай определения. Что ты не в курсе, что такое ООП, я ещё из первых твоих постов в этом треде понял. Я к плюсам толерантен. Что в ПХП, что в плюсах, что в шарпе, что в Джаве, что в Аде - да где угодно! - поддержка ООП обозначает поддержку этих четырёх фич. В Фортране-90 этой поддержки нет. О чём тут ещё спорить можно?
А, так это наезды лично на меня. Ну тогда ладно. Я уж подумал ты на святое замахнулся...
Да, я люблю фортран и считаю, что 3 из 4-х - это лучше чем 0 из 4-х.
Да, я люблю фортран и считаю, что 3 из 4-х - это лучше чем 0 из 4-х.
Оставить комментарий
-Serg-
принят ли стандарт фортран 2000\2003есть уже реализации с поддрежкой ООП?