Фортран бинарно совместим с C, а C — с Питоном. Значит, можно вызывать функции фортрана из Питона, но я не знаю как...

Что подразумевается под API? Какая-то либа? Сделай с её помощью модуль для питона и пользуйся.

cffi

f2py

cffi + http://www.yolinux.com/TUTORIALS/LinuxTutorialMixingFortranAndC.html

Я спросил про архитектурное решение а не про средства

Вот это мощьно

Да так можно сказать все со всем совместимо) байты то везде одинаковы

Ну так с помощью f2py фортрановский код заворачивается в питоновский модуль. В numpy/scipy он используется, например, для интерфейса к FFTPACK. С вызовом бинарника я бы не заморачивался.

Есть современная прога на Питоне

А почему просто не написать «современную» прогу на Фортране?

Прогу на фортране можно модифицировать? Я бы такое взаимодействие построил через stdin/stdout.

Тут на самом деле две стороны: 1) Если данных относительно мало, то производительнее будет вызвать один раз код фортрана и вытащить все данных а потом их спокойно обрабатывать на питоне.

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

Встраивать фортан в питон это накладывает некоторые обязательства на поддержку этого кода. Сложнее становится..

Потому что не нравится мне фортран

1) Если данных относительно мало, то производительнее будет вызвать один раз код фортрана и вытащить все данных а потом их спокойно обрабатывать на питоне.

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

Почему это требует именно отдельного бинарника? Для него надо отдельный процесс спавнить, обрабатывать его ошибки, скармливать ему данные... Смысл, если обернуть проще?

Встраивать фортан в питон это накладывает некоторые обязательства на поддержку этого кода.

Какие обязательства? Лицензия, что ли, требует поддерживать? Если саму фортрановскую прогу не надо поддерживать, зачем тебе обертку трогать вообще?

Сложнее становится..

Документацию хотя бы почитал.

А ты в курсе что распараллеленый алгоритм на небольшом кол-ве данных будет работать медленнее чем нераспараллеленный? Он проявит свою мощь только на больших данных.

И еще раз говорю: простота кода и главное архитектуры - это хорошо и это правильно.

Кароч это холивар. Встроенные функции имеют место быть для обработки итерационно в моем случа.

И еще раз говорю: простота кода и главное архитектуры - это хорошо и это правильно.

Так я именно это и предлагаю, а не плодить костыли с subprocess.

А ты в курсе что распараллеленый алгоритм на небольшом кол-ве данных будет работать медленнее чем нераспараллеленный?

Я что-то говорил про распараллеливание? Я его вообще не упоминал, паралелльность или последовательность твоего алгоритма и/или парсера данных вообще не имеет отношения к предмету дискуссии. Другое дело, что при вызове бинарника с фортраном у тебя, сюрприз, всегда запускается отдельный процесс с этим самым бинарником. И этот процесс, по-хорошему, надо пасти — контролировать выполнение, проверять код ошибки и т.д. В случае сгенерированного API проверил код возврата функции и дело в шляпе, просто и понятно.

Пример проблемы с subprocess — если во время выполнения стороннего бинарника ты прибиваешь свою программу по Ctrl-C, твоя фортрановская штука не прибьется автоматически. Я не говорю, что это нельзя реализовать правильно, просто это потребует времени и дополнительного кода.

Потому что не нравится мне фортран

Ну вот, аргументный аргумент. Не нравится ЯП Fortran, но нравистя Python, который даже языком назвать нельзя...

Архитектурно правильно либо оставить все на фортране, либо переписать все на питон и numpy/scipy. А не заниматься симбиозом некромантии с элементами BDSM и хипстоты.

Кроме архитектуры еще важны экономические факторы.

Переписать на питоне не получится, так как как ни крути фортрановские процедуры надо юзать. И кстати f2py как я понял под 3 питоном не работает.

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

Есть крутая прога для инженерных расчетов, эта прога выдает большой файл

МКЭ?

Ага

Архитектурно фортран чище питона. Окай,назовите недостатки фортрана (современный стандарт), которые не дают на нем работать? Пока я вижу религиозное не хочу.

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

Архитектурно фортран чище питона

Ох уж эти ЛОР'овские архитекторы…

Еще Фортран живой, потому что его современные компиляторы выдают изумительно эффективный и производительный машкод.

Окай,назовите недостатки фортрана (современный стандарт), которые не дают на нем работать?

Туда realloc уже завезли? Как считать из файла массив неизвестного размера? Через промежуточные массивы с копированием?

Как насчёт аналога void* или шаблонов? Как сделать два односвязных списка, один для integer, другой для double precision, без дублирования кода? Я пытался сношаться с transfer, получалось не очень со стороны пользователя.

Честно скажу, что современный стандарт я могу и не знать, особенно если он обновлялся с 2010 года. Я его специально не изучал.

Туда realloc уже завезли?

Я вспомнил про move_alloc. Пожалуй, первый вопрос можно снять.

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

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

Утрируешь. Мы обсуждаем промышленные языки. Брейнфак - эксперементальный/исследовательский. Как минимум - последний не обладает нужной тебе бибиотекой батареек, поэтому приписываю выпад к религиозному оправданию своего слива. Либо жду аргументы или примеры того, чего ты не можешь сделать на фортране и поэтому тянешь руки питону.

Утрирую. Чтобы показать отсутствие ограничений. По теореме о Тьюринг-полноте, принципиальной разницы между языками не существует. Так что потрудись дать определение того, что ты хочешь услышать, иначе это так и останется религиозным срачем. Пример может быть неприниципиального, но существенного недостатка фортрана я привёл выше. Это один из тех недостатков, которые затрудняют создание универсальных библиотек алгоритмов и структур данных силами малой команды.

Помимо generic programming с использованием transfer intrinsic для «симуляции шаблона» есть ещё такая штукенция: http://stackoverflow.com/questions/23706742/template-in-fortran

Спасибо за ссылку, но с тем же успехом можно просто взять m4. А потом вспомнить десятое правило Гринспена.

Вики сообщает, что существует уточнение этого правила, согласно которому это правило применимо, в том числе, и к самому Common Lisp.

Всё равно, Фортран - няшка :) Жаль, что я его так и не выучил в приемлемой степени, как и любой другой язык программирования.

Как насчёт аналога void* или шаблонов? Как сделать два односвязных списка, один для integer, другой для double precision, без дублирования кода?

А чем плоха обычная перегрузка (если она в данном случае применима)? Только тем, что код «дублируется» программистом? О шаблонах в C++ в вики пишут такое:

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

А чем плоха обычная перегрузка (если она в данном случае применима)? Только тем, что код «дублируется» программистом?

Да, тем, что код дублируется программистом. Очень важно иметь возможность выделять повторяющиеся концепции в коде и выносить их в отдельные сущности в виде функций, классов или чего-то ещё. Это называется абстрагирование и является основным инструментом программиста при решении сложных задач. В общем-то, всё программирование можно рассматривать как манипуляции абстракциями. Абстрагирование приводит к логически более стройным и легко расширяемым программам. См. также bottom-up programming. У фортрана, при всей его няшности, маловато возможностей для построения абстракций, хотя, конечно, он улучшается от стандарта к стандарту.

В случае C++ код дублируется компилятором. Это никак не мешает строить абстракции, так как программист работает только с тем, что написано в текстовом файле с исходником. То же самое можно сказать и про связку фортран + m4. Использовать m4 для шаблонизации фортрана в стиле C++ --- это интересная идея и, может быть, я бы повозился с ней если бы ещё работал с фортраном.

Утрирую.

Просто сектант.

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

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

Так что потрудись дать определение того, что ты хочешь услышать, иначе это так и останется религиозным срачем.

Ты наркоман? Как я могу дать опоределение ТВОЕЙ прикладной области? Это же ты решаешь задачу, знаешь её исходные данные и ограничения... Для этого я и спросил, собственнно, чтобы понять - чем не устраивает полный по Тьюрингу язык, заточенный ДЛЯ числодробилок при написании ЧИСЛОДРОБИЛКИ. Фиршейн?

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

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

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

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

Зря стараетесь. ТС любое решение отличное от питоновского будет в штыки воспринимать. Хотя инфа полезная.

Да, тем, что код дублируется программистом.

Проблема программиста. Не языка. Не умеет оперировать уровнем адстракции языка.

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

Мсье хочет сказать, фортран этого не позволяет? Пруф, извольте.

Это называется абстрагирование и является основным инструментом программиста при решении сложных задач.

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

В общем-то, всё программирование можно рассматривать как манипуляции абстракциями.

Учебник можно не копировать. В dev по моему не так много гуманитариев.

Абстрагирование приводит к логически более стройным и легко расширяемым программам.

Во-первых, не всегда. Я могу забодяжить тебе формулу игры (Теория Игр, а не крузис о котором ты подумал) и алгоритм её решения. Формула будет хотя бы 25 неизвестными, которые каким-либо образом связаны друг с другом и имеют вес, который зависит от каждой. Математическая формула - самая высокая абстракция, которую можно придумать. И попрошу тебя внести пять новых переменных и убрать пять старых. Вот тут я посмотрю как ты запоешь. Далее - абстрагирование как таковое ничего не дает. Дает программист, способный пользоваться уровнем абстракции (читай - проектировать нормальную архитектуру). Гекатонны РНР-макак доказали, что если дать бездарю высокий уровень абстракции - он не напишет все равно ничего хорошего, окромя говнокода. Да и если нужен так уж высокий уровень абстракции - Racket или Clean в лапы и лабайте на них. Скорости хватит. Не хватит только если не осилите. Хотя, если не осилили официальные доки фортрана - то сомневаюсь в написании чего-то кроме «Привет, мир» или 1+2.

См. также bottom-up programming. У фортрана, при всей его няшности, маловато возможностей для построения абстракций, хотя, конечно, он улучшается от стандарта к стандарту.

Примеры. Каких абстракций вам не хватает? Вы точно понимаете, сущность каждой абстракции?

В случае C++ код дублируется компилятором.

Криворукость и незнание компилятора. Ну да, бывает и со стороны копилятора. Тут отрицать сложно. Но первое - не отменяет.

Это никак не мешает строить абстракции, так как программист работает только с тем, что написано в текстовом файле с исходником.

Я уже запутался. То вам что-то мешает, как плохому танцору... то резко это ампутируют. Вы уж определитесь

То же самое можно сказать и про связку фортран + m4. Использовать m4 для шаблонизации фортрана в стиле C++ --- это интересная идея и, может быть, я бы повозился с ней если бы ещё работал с фортраном.

Перевожу весь бред написанный в треде: «Ко-ко-ко, я не знаю фортран и не хочу его изучать! Ко-ко-ко, я хочу, чтобы мне дали решение на единственном понятном мне языке - пистоне»

Просто сектант.

От сектанта слышу.

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

Ну отлично, следовательно, одинаково удобно писать на брейнфаке, фортране и питоне.

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

нет чётких критериев «принципиальных вещей, которые не позволяют решить какую-либо задачу».

жду аргументы или примеры того, чего ты не можешь сделать на фортране

потрудись дать определение того, что ты хочешь услышать

Ты наркоман? Как я могу дать опоределение ТВОЕЙ прикладной области?

Сам наркоман. Про мою прикладную область речи не было.

чем не устраивает полный по Тьюрингу язык, заточенный ДЛЯ числодробилок при написании ЧИСЛОДРОБИЛКИ

Числодробилка редко заканчивается числодроблением, так как в неё ещё надо подать данные, а потом представить результат в удобном виде (как раз задача топикстартера). И в какой-то момент оказывается, что со сложными данными чертовски неудобно работать когда все виды контейнеров что у тебя есть --- это массивы чисел. Ты когда-нибудь видел легаси парсер на фортране 77? Я видел. Каша из goto, заполняющая статические массивы в common-блоках. Там использовалась многоуровневая адресация (массивы индексов массивов индексов) для эмуляции деревьев. Я пытался переписать это в современном стиле, со структурами, рекурсивными функциями и динамическим выделением памяти, но бросил когда ниасилил сделать даже односвязные списки. Вполне допускаю, что я просто не знаю фортран достаточно. Можешь ли ты, о гуру, продемонстрировать как организовать удобные односвязные списки произвольных структур в фортране?

Так будьте любезны объяснить, чем этот недостаток не удобен.

Я выше рассказывал чем плохо дублирование кода. Поискать слова попроще? Кроме того, есть ещё совсем очевидные вещи вроде необходимости отслеживать изменения в алгоритме в нескольких местах сразу.

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

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

Фортран позиционируется как язык для физиков, а они обычно работают небольшими группами. Программы пишут команды в 1-5 человек, причём часто никто из них не является профессиональным программистом. Желания изучать фортран у них, кстати, тоже обычно нет, у них своей предметной области хватает. Но даже если рассматривать фортран в отрыве от физиков. Чем мощнее язык, тем большую производительность будет показывать программист. При этом мощность языка определяется возможностями построения абстракций. С ростом уровня абстракции можно оперировать всё более сложными концепциями, причём в идеале --- в терминах решаемой задачи, а не в терминах перемножения массивов (а когда-то ведь все работали в машинных инструкциях). В фортране (2010 года) нет даже тех теперь уже считающихся примитивными способов построения абстракций, которые есть в C (void*). Это недостаток, и довольно существенный.

Да, тем, что код дублируется программистом.

Проблема программиста. Не языка. Не умеет оперировать уровнем адстракции языка.

Расскажи как это сделать без дублирования.

Мсье хочет сказать, фортран этого не позволяет? Пруф, извольте.

Сделай мне односвязный список.

Абстрогирование у вас от реального мира. А то, что вы назвали абстрагированием - называет уровнем абстракции или объектами абсракцией. Чаще - просто абстракцией.

Абстрагирование --- это построение абстракций. Здесь мы согласуемся.

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

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

Учебник можно не копировать. В dev по моему не так много гуманитариев.

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

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

Я не знаю теорию игр, поэтому плохо понимаю что тут написано. Непохоже, что проблема связана с языком программирования, скорее со сложностью получения нового алгоритма после изменения формулы.

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

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

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

То есть, тогда лучше никому не давать более высокий уровень абстракции и пусть все и дальше перекладывают числа в массивах?

Да и если нужен так уж высокий уровень абстракции - Racket или Clean в лапы и лабайте на них. Скорости хватит.

С тем, что есть более высокоуровневые языки программирования, я согласен. Наша дискуссия началась с вопроса о недостатках в фортране. У других языков есть свои недостатки (и свои преимущества).

См. также bottom-up programming. У фортрана, при всей его няшности, маловато возможностей для построения абстракций, хотя, конечно, он улучшается от стандарта к стандарту.

Примеры. Каких абстракций вам не хватает? Вы точно понимаете, сущность каждой абстракции?

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

В случае C++ код дублируется компилятором.

Криворукость и незнание компилятора. Ну да, бывает и со стороны копилятора. Тут отрицать сложно. Но первое - не отменяет.

Не понял. Код шаблонов дублируется компилятором в машинных кодах для каждого типа аргументов (с некоторыми исключениями при применении шаблонов для метапрограммирования и тех случаев когда код выкидывает оптимизатор). Я не прав?

Это никак не мешает строить абстракции, так как программист работает только с тем, что написано в текстовом файле с исходником.

Я уже запутался. То вам что-то мешает, как плохому танцору... то резко это ампутируют. Вы уж определитесь

Текст программы --- это формализованная запись решения некоторой задачи. Из текста программы получаются инструкции для машины, позволяющие, путём выполнения, решить поставленную задачу. Программист обычно не работает с представлением программы в машинных кодах, он работает только с исходным текстом. Поэтому, если не задаваться некоторыми вопросами оптимизации, не имеет значения, что код дублируется компилятором. С точки зрения программиста у него есть лишь один вариант кода, и, изменяя его, он изменяет алгоритм работы сразу со всеми типами, которые этот код описывает. С фортраном (без m4) такой трюк не пройдёт: даже если алгоритм работы с массивом double precision и массивом integer одинаковый (например, сортировка), надо вручную описывать две функции и следить за соответствием кода в обоих функциях. Здесь нельзя построить абстракцию от типа данных в массиве.

Перевожу весь бред написанный в треде: «Ко-ко-ко, я не знаю фортран и не хочу его изучать! Ко-ко-ко, я хочу, чтобы мне дали решение на единственном понятном мне языке - пистоне»

С твоей стороны видна только наглядная демонстрация парадокса Блаба.

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

В turbo pascal этого тоже нет, а односвязные списки есть.

Для создания односвязного списка нужен тип данных, содержащий сами данные и указатель на этот же тип данных. И в учебниках о фортране рассматривается этот вопрос в разделах о производных типах и указателях.

От сектанта слышу.

Пруф

Сделай мне односвязный список.

Почему я тебя должен что-то делать?

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

Пот я и предложил без них.

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

Я принебрегаю философией оторванной от мира. Критического мышления у вас нет - иначе бы видели, что пистон ничем не лучше для ваших задач.

Я не знаю теорию игр, поэтому плохо понимаю что тут написано. Непохоже, что проблема связана с языком программирования, скорее со сложностью получения нового алгоритма после изменения формулы.

Ко-ко-ко-гуманитарий. Сложность в изменении алгоритма из-за появления новых связанных сущностей, которые оказывают влияние на игру. Гуманитарйи жеж.

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

Вы говорите о создании DSL, это позволяет любой тьюрнг-полный язык.

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

4 минуты гуления: http://webkonspect.com/?room=group&id=105&labelid=3071. Просто вы не знаете фортран. И не хотите его знать.

Не понял. Код шаблонов дублируется компилятором в машинных кодах для каждого типа аргументов (с некоторыми исключениями при применении шаблонов для метапрограммирования и тех случаев когда код выкидывает оптимизатор). Я не прав?

Это я вас не понял. Вопрос снят. Но шаблоны - костыли, которые пытаются привнести возможности lisp-family в языки без метапрограммирования. Оно вам правда надо?

Текст программы - это формализованная запись решения некоторой задачи.

Смотря какая парадигма. Чаще всего - алгоритм решения.

Из текста программы получаются инструкции для машины, позволяющие, путём выполнения, решить поставленную задачу.

Гуманитарий, вы случаем не препод? Напоминает

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

Правда? А я то думал

Поэтому, если не задаваться некоторыми вопросами оптимизации, не имеет значения, что код дублируется компилятором.

Правда?

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

Неужели?)

С фортраном (без m4) такой трюк не пройдёт: даже если алгоритм работы с массивом double precision и массивом integer одинаковый (например, сортировка), надо вручную описывать две функции и следить за соответствием кода в обоих функциях.

Может руки стоит выпрямить?

Здесь нельзя построить абстракцию от типа данных в массиве.

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

Он не читал учебники. Расслабьтесь. Питонофанатики они такие.

Кстати, если дружишь с C, то можно и такое попробовать использовать (https://habrahabr.ru/company/intel/blog/255305/), вызывая функции Fortran из C.

pipe?

В turbo pascal этого тоже нет, а односвязные списки есть.

Если я правильно помню, то в Turbo Pascal есть тип pointer, полностью аналогичный void* в C.

Для создания односвязного списка нужен тип данных, содержащий сами данные и указатель на этот же тип данных. И в учебниках о фортране рассматривается этот вопрос в разделах о производных типах и указателях.

Для создания одного односвязного списка --- да, этого достаточно. Для создания библиотеки для работы с односвязными списками нужно обобщить понятие «данное». В фортране нет понятия «указатель», есть понятие «указатель на конкретный тип данных»: «указатель на integer», «указатель на real». Нет способа (ну или я не знаю) кастануть integer(:) в character(:).

От сектанта слышу.

Пруф

Тогда сначала ты пруф, что я сектант.

Почему я тебя должен что-то делать?

Ну а как я тебе должен доказывать? Я утверждаю, что что-то сделать невозможно. Ты утверждаешь обратное. Я должен доказать отсутствие что ли? Ты что, и в Бога веришь?

Критического мышления у вас нет - иначе бы видели, что пистон ничем не лучше для ваших задач.

Критического мышления у тебя нет, иначе ты бы видел, что про мои задачи мы вообще не говорили. Или ты хочешь сказать, что фортран не хуже питона во всех задачах?

Ко-ко-ко-гуманитарий.

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

Сложность в изменении алгоритма из-за появления новых связанных сущностей, которые оказывают влияние на игру.

Эта сложность никак не связана с выбором языка программирования. Здесь сложность в самой задаче. Особенности языка программирования начнут сказываться когда программист будет её формализовывать.

Вы говорите о создании DSL, это позволяет любой тьюрнг-полный язык.

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

4 минуты гуления: http://webkonspect.com/?room=group&id=105&labelid=3071. Просто вы не знаете фортран. И не хотите его знать.

Такие же ссылки я находил когда решал задачу. Вот программа на C99. В ней два массива, один int, другой double, преобразуются в списки, списки разворачиваются и печатаются. В программе продублирован лишь код печати списков и собственно последовательность действий, для наглядности. Функции list_reverse пофигу какие там типы данных в списках. Функция array_to_list_view написана для произвольного типа данных.

Вот аналогичная программа на Fortran 2008. Как её изменить, чтобы она заработала?

Вот программа на GNU Fortran. Она работает, но в ней используются нестандартные расширения: Cray pointers и функция loc. Во-первых, они нестандартны, причём это не из тех расширений, что при необходимости добавляются сторонней библиотекой (как практически всё в std в C++). Если целевой компилятор их не умеет, то всё, скорее всего будет проще эту часть переписать на C, чем портировать.

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

В-третьих, синтаксис для работы с Cray pointers крайне неудобен, так как переменные приходится объявлять парами и всюду работать с ними через побочные эффекты вида «изменили значение указателя, обработали значение переменной». Впрочем, я уже понял, что эстетические вкусы у нас совершенно разные и приводить этот аргумент бесполезно.

Вообще, складывается ощущение, что фортран всеми силами старается оградить программиста от прямой пработы с памятью, но при этом не предоставляет никаких механизмов для решения проблем, которые в том же C решаются через void*. Это один из тех случаев, когда программа думает, что она умнее пользователя.

Но шаблоны - костыли, которые пытаются привнести возможности lisp-family в языки без метапрограммирования. Оно вам правда надо?

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

Смотря какая парадигма. Чаще всего - алгоритм решения.

Алгоритм --- в императивной. Моё определение подходит и для других.

Гуманитарий, вы случаем не препод? Напоминает
Правда? А я то думал
Правда?
Неужели?)

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

Может руки стоит выпрямить?

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

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

Одна и та же задача на разных языках реализуется с разными усилиями. При этом разница во временных затратах может быть колоссальна. Что-то мне надоело тривиальные вещи рассказывать...

Он не читал учебники. Расслабьтесь. Питонофанатики они такие.

Я смотрю, ты целый один учебник прочитал и на большее тебя не хватило? Для fortran-only «программистов» это весьма характерно.

Как насчёт аналога void*

transfer

http://jblevins.org/research/generic-list.pdf

Заместо шаблонов для полиморфизма через перегрузку лично я достаточно активно в своё время пользовался cpp.

Тогда generic programming (если он применим) используй, чего тянуть то время? Лучше полчаса потерять, потом за пять минут долететь.

Если я правильно помню, то в Turbo Pascal есть тип pointer, полностью аналогичный void* в C.

А что толку? Односвязный список там всё равно будет реализовываться через создание своего типа, внутри которого будет указатель на этот же тип, не?

На самом деле в Fоrtran есть целочисленный указатель (просто pointer), который всегда типа «integer(4)» (для переменной любого типа) и указатель-ссылка (используется в паре pointer-target). Указатель в Fortran не то же самое, что в C.

складывается ощущение, что фортран всеми силами старается оградить программиста от прямой пработы с памятью, но при этом не предоставляет никаких механизмов для решения проблем, которые в том же C решаются через void*.

Это называется скрытие реализации, что нормально для языка высокого уровня. Зато сколько проблем пораждается в C за счёт отсуствия подобных скрытий.

Емнип и если я вообще правильно понимаю, то в C реализация такого примера (передача аргументом имени произвольной функции для подстановки, пример не мой) будет через указатели на функции:

program degtest
  implicit none
  intrinsic asin, acos, atan
  write (*,*) ’arcsin(0.5): ’, deg(asin,0.5)
  write (*,*) ’arccos(0.5): ’, deg(acos,0.5)
  write (*,*) ’arctan(1.0): ’, deg(atan,1.0)

  contains
    real function deg(f, x)
      implicit none
      intrinsic atan
      real, external :: f
      real, intent(in) :: x
    
      deg = 45*f(x)/atan(1.0)
    end function deg

end program degtest