написание проги + кросс-платформенность
Пиши на C, причем, раз задача вычислительная, то имеет смысл воспользоваться готовой библиотекой, например, GSL. Тогда во-первых не придется реализовывать всякие примитивы вычислений, а во-вторых основная забота о кроссплатформенности ляжет на библиотеку, т.е. особо думать не придется.
ИМХО, написать числодробилку на C так, что её трудно портировать будет - это ещё надо постараться...
Насчёт C/C++ для вычислительной проги - здесь однозначно за. Ява не для этого, а переносимость у C и основных частей C++ не хуже.
С библиотекой, imho, сложнее. Насколько это нужно, и что нужно - не ясно, надо на задачу посмотреть, но у конкретной GSL есть очевидный минус, что она с common GPL лицензией, и если тебя заботит "лицензионная чистота" твоих программ (а она может беспокоить для коммерческих программ или для программ, которые ты будешь использовать для публикаций то лучше забить на неё и поискать что-нибудь с нормальной лицензией.
С библиотекой, imho, сложнее. Насколько это нужно, и что нужно - не ясно, надо на задачу посмотреть, но у конкретной GSL есть очевидный минус, что она с common GPL лицензией, и если тебя заботит "лицензионная чистота" твоих программ (а она может беспокоить для коммерческих программ или для программ, которые ты будешь использовать для публикаций то лучше забить на неё и поискать что-нибудь с нормальной лицензией.
> ИМХО, написать числодробилку на C так, что её трудно портировать будет - это ещё надо постараться...
Какие ограничения на тип int, например? Обычно закладываются, что int - это 4 байта (с вытетающими ограничениями ни меньше, ни больше.
Какие ограничения на тип int, например? Обычно закладываются, что int - это 4 байта (с вытетающими ограничениями ни меньше, ни больше.
Числодробилка - это обычно вычисления с плавающей запятой, разве не так? А закладываться на четырёхбайтовость инта - это и называется "постараться" 
Фортран подойдет?
У него платформозависимость мб только из-за использования специфических библиотек (winapi например.
У него платформозависимость мб только из-за использования специфических библиотек (winapi например.
фортран не катит
интересует первый вопрос
Почему, если не секрет?
есть знакомый товарищ, который пишет на фортране - приходится писать
хорошо пишет, с импользованием ЦЕРНовских библиотек, такие толстые проги пишет
он меня отговорил
хорошо пишет, с импользованием ЦЕРНовских библиотек, такие толстые проги пишет
он меня отговорил
Гарантии у тебя такие, ИМХО:
char - не меньше 1 байт
int- не меньше 2 байт
long - не меньше 4 байт
на остальное гарантий не дается
char - не меньше 1 байт
int- не меньше 2 байт
long - не меньше 4 байт
на остальное гарантий не дается
Вроде ж я предложил решение: использование библиотеки заметно снизит количество платформозависимого кода, его можно вынести в отдельные файлы и сделать варианты для нужных платформ.
А какие аргументы приводил?
Ввод-вывод отдельно, очень низкоуровневые вещи отдельно.
Как обычно, в общем-то.
А вообще, числедробилки пишут на фортране.
---
...Я работаю...
Как обычно, в общем-то.
А вообще, числедробилки пишут на фортране.
---
...Я работаю...
По-традиции чтоли? В чем преимущество Фортрана перед теми же Сями?
Куча существующего кода (именно в данной области как правило слегка более шустрые компиляторы.
Только не компиляторы, а получающиеся программы.
---
...Я работаю...
---
...Я работаю...
В чем преимущество Фортрана перед теми же Сями?Язык более простой, я бы сказал прямолинейный, компилятору проще оптимизировать. Как следствие - более шустрый исполняемый код.
Неправильно.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
Что именно неправильно? По возможности с аргументацией.
От того, что язык более простой, оптимизатор проще не становится.
Даже наоборот --- сложнее.
Вот если бы ты говорил про статическое выделение памяти
и большую историю применения фортрана в быстрых вычислениях,
было бы другое дело.
---
...Я работаю...
Даже наоборот --- сложнее.
Вот если бы ты говорил про статическое выделение памяти
и большую историю применения фортрана в быстрых вычислениях,
было бы другое дело.
---
...Я работаю...
В чем преимущество Фортрана перед теми же Сями?В том, что Фортран именно для этого и предназначен (и создавался).
А, как всем известно, специализированный инструмент в своей епархии побьет любой другой.
Если конкретнее, то, например, работа с массивами в Фортране более продуманная (а численные задачи часто работают с массивами).
С типами в Фортране тоже определенность полная - сколько скажешь, столько и будет.
Статическое выделение памяти удобно только когда под каждую задачу делаешь отдельную программу (пусть даже ты ее просто скопировал и исправил размерности массивов).
А вот при создании чего-то более-менее универсального - статикой уже не обойдешься.
Хотя конечно больше вариантов - это не меньше вариантов.
А вот при создании чего-то более-менее универсального - статикой уже не обойдешься.
Хотя конечно больше вариантов - это не меньше вариантов.
"Быстро" и "удобно" --- не обязательно сосуществуют.
---
...Я работаю...
---
...Я работаю...
Эффективность программы зависит в основном от опыта пишушего и от количества прочитанных мануалов к фортранным компиляторам. Ну и конечно от использования правильных библиотек (причём нередко наиболее быстрые библиотеки - сишные, а отнюдь не фортранные). Большая история применения фортрана в быстрых вычислениях тут побоку, я так думаю. Фортран всё больше и больше используется в вычислениях именно как простой язык, а не как быстрый. А быстрые вычисления всё чаще пишутся на других языках, в том числе на C/С++.
Это понятно, но проигрыш по скорости в разы так получить сложно, зато удобство (особенно от последующего интенсивного использования) может перекрыть с лихвой (компы ускоряются гораздо быстрее, чем улучшается удобство работы с ними, к сожалению 
).
).Если нужно удобство, то надо отказываться как от фортрана, так и от сей.
---
...Я работаю...
---
...Я работаю...
А что использовать?
A48: ОПЯТЬ?
---
...Я работаю...
---
...Я работаю...
Конечно, я имел в виду получающиеся программы.
Но это фигня, там не такая разница чтобы ради нее писать на этом недоязыке (да простят меня его фанаты).
Главная причина, которую кстати до сих пор не назвали, - инерция мышления.
Но это фигня, там не такая разница чтобы ради нее писать на этом недоязыке (да простят меня его фанаты).
Главная причина, которую кстати до сих пор не назвали, - инерция мышления.
Давайте внесём вот в FAQ/FGA?
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
Против.
Требую добавления пункта
17а. Collected С++ wisdom
Требую добавления пункта
17а. Collected С++ wisdom
недоязыке
Вообще, имхо, фортран нужно, по хорошему, искоренять, а его до сих пор поддерживают.. В итоге - чем дальше, тем сильнее увязают, как в болоте.
A48: ОПЯТЬ?Уже было? А можно ссылку? Или по каким словам и где искать?
Давайте внесём вот это в FAQ/FGA?Это все не про меня
2
2
А можно поподробнее про то, почему надо выкинуть Фортран и чем его заменить?
А чем он лучше того же Си ?
А чем хуже?
Просто раз ты взялся это утверждать - значит знаешь это - вот и поделись
Или хотя бы дай хороший набор критериев для сравнения языков программирования
Просто раз ты взялся это утверждать - значит знаешь это - вот и поделись
Или хотя бы дай хороший набор критериев для сравнения языков программирования
Мне, например, не хватает в Фортране только нормального ООП (как раз для удобства).
Так его и в Си тоже нету
Мне этот вопрос очень интересен, так как я хочу его для себя решить.
Сейчас, например, я не могу сказать человеку, пишущему на фортране - пиши лучше на Си (или еще каком языке; на каком? так как я не смогу назвать те причины, по которым ему от этого станет лучше
Так его и в Си тоже нету
Мне этот вопрос очень интересен, так как я хочу его для себя решить.
Сейчас, например, я не могу сказать человеку, пишущему на фортране - пиши лучше на Си (или еще каком языке; на каком? так как я не смогу назвать те причины, по которым ему от этого станет лучше
В Си хоть указатели есть, и на них делается нормальное ООП.
Субьективно, код на фортране выглядит корявым. Он навязывает программисту определенный стиль. "A Real Programmer can write Fortran in any language"
Это не есть гуд.
Субьективно, код на фортране выглядит корявым. Он навязывает программисту определенный стиль. "A Real Programmer can write Fortran in any language"
Это не есть гуд.ООП на Си?
Ну ты жжошь!
Ну ты жжошь!
А чо такого?
Нормальный программист может писать в ООП-стиле на почти любом языке.
Посмотри сурцы второй кваки.
Нормальный программист может писать в ООП-стиле на почти любом языке.
Посмотри сурцы второй кваки.
Вырожу свое. В целом, неоригинальное.
1) Юникс-вей: Не надо писать графический интерфейс. Это должно быть консольное приложение. Если будет нужно, графический интерфейс прикрутишь потом. Раз программа счетная, то вообще неясно, что у тебя зависит от платформы. Если все же есть платформнозависимые функции, можно обернуть их вызовы и расположить в отдельном файле.
2) Фортран vs Си Имхо, Фортран неудобный язык. Первоочередная цель -- простой, понятный и корректный код. Второй шаг: найти то, что кушает 90% времени и переписать его хоть на ассемблере (если это будет оправдано). Для реализации первой задачи на мой вкус больше подходит С++.
У меня самого програ по большей части вычислительная и весьма кросплатформенная. Она довольно-таки существенно плюсовая.
1) Юникс-вей: Не надо писать графический интерфейс. Это должно быть консольное приложение. Если будет нужно, графический интерфейс прикрутишь потом. Раз программа счетная, то вообще неясно, что у тебя зависит от платформы. Если все же есть платформнозависимые функции, можно обернуть их вызовы и расположить в отдельном файле.
2) Фортран vs Си Имхо, Фортран неудобный язык. Первоочередная цель -- простой, понятный и корректный код. Второй шаг: найти то, что кушает 90% времени и переписать его хоть на ассемблере (если это будет оправдано). Для реализации первой задачи на мой вкус больше подходит С++.
У меня самого програ по большей части вычислительная и весьма кросплатформенная. Она довольно-таки существенно плюсовая.
В Си хоть указатели естьНе знаю, как насчет указателей, а ссылки в Фортране есть.
А указатели - палка о двух концах.
и на них делается нормальное ООП.На них - это на указателях?
Субьективно, код на фортране выглядит корявымКак-то не замечал.
Если ты видел только проги в фиксированном формате - ты много потерял.
Он навязывает программисту определенный стильНе замечал.
Пишу, как мне нравится - проблем не испытываю
п.с.: ну вот, только подумал, что мне сейчас знающий человек все по полочкам разложит - ан нет
Новому человеку достаточно сложно заботать фортран в силу того, что на нем довольно много вещей, навязанных по историческим причинам, а не здравым смыслом. В С с этим попроще.
Из примера таких вещей: в свое время я потратил около 5 часом только на то, чтобы выяснить, что в fixed форме отступы слева важны. В результате, оказалось, что рабочая программа от нерабочей отличается пятью пробелами - по одному на одну строчку. При этом компилятор выдавал неудобоваримое сообщение (что вероятно было особенностью только конкретного компилятора) и никак не продвигал меня к тому, чтобы заведомо правильная программа скомпилировалась.
На то, чтобы выловить все "рояли в кустах" в Фортране, человеку потребуется достаточно большое время, больше, чем для С. Говорю по своему опыту, но возможно я просто неправильно ботаю, не так, как предполагает Фортран.
Из примера таких вещей: в свое время я потратил около 5 часом только на то, чтобы выяснить, что в fixed форме отступы слева важны. В результате, оказалось, что рабочая программа от нерабочей отличается пятью пробелами - по одному на одну строчку. При этом компилятор выдавал неудобоваримое сообщение (что вероятно было особенностью только конкретного компилятора) и никак не продвигал меня к тому, чтобы заведомо правильная программа скомпилировалась.
На то, чтобы выловить все "рояли в кустах" в Фортране, человеку потребуется достаточно большое время, больше, чем для С. Говорю по своему опыту, но возможно я просто неправильно ботаю, не так, как предполагает Фортран.
не хватает в Фортране только нормального ООПв последнем фортране вроде прикрутили полноценные объекты.
ООП на Си?http://www.planetpdf.com/developer/article.asp?ContentID=663...
Ну ты жжошь!
Object-ed Programming in ANSI C , Axel-Tobias Schreiner
прогу надо сделать многопоточной
фортран отбрит к черту после детального изучения (я посредственно знаю и си, и фортран)
вычисления вычислениям рознь. одно дело вычисления - матрицы перемножать, другое дело - 3д-графику рендерить, третье дело - что-нибудь типа нейронных сетей, четвертое дело - работа с графами. по стилю требуемых для реализации вычислений, больше подходит си
фортран отбрит к черту после детального изучения (я посредственно знаю и си, и фортран)
вычисления вычислениям рознь. одно дело вычисления - матрицы перемножать, другое дело - 3д-графику рендерить, третье дело - что-нибудь типа нейронных сетей, четвертое дело - работа с графами. по стилю требуемых для реализации вычислений, больше подходит си
почему многопоточной?
многопоточность vs кросс-платформенность
имхо, это жесть
многопоточность vs кросс-платформенность
имхо, это жесть
Для того, чтобы на С сделать программу многопоточной и оставить при этом кроссплатформенной, одним достаточно дешевых способов является использования MPI или OpenMP
Для того, чтобы на С сделать программу многопоточной и оставить при этом кроссплатформенной, одним достаточно дешевых способов является использования MPI или OpenMPНу, не сказал бы, что прямо очень дешевый способ, т.к. MPI требует своего особого подхода к разработке, который не для всех задач удобен.
С OpenMP ситуация, имхо, похожая.
А кроссплатформенные треды для C есть, например, в исходниках mysql, а ещё есть отдельный проект pthread-win32 - порт pthread для Windows.
Да, и не стоит забывать про Apache Portable Runtime.
Прикрутить-то прикрутили, а вот какие компиляторы его поддерживают?
Зато он достаточно часто используется, а значит все подводные камни изучены и описаны, а во-вторых расчетная задача вполне может в какой-то момент захотеться запускаться на кластере. Тут-то и вылезет из-за чьих-то спин гражданин MPI, хитро так прищурится и скажет: хе хе.
Да я вовсе не против MPI, если задача "достаточно хорошая".
Самому мне не очень понравилось использовать MPI. Уж не знаю, чего там было неподходящим - задача или руки, но удовольствия я не получил
Самому мне не очень понравилось использовать MPI. Уж не знаю, чего там было неподходящим - задача или руки, но удовольствия я не получил
Так и от программирования на С тоже удовольствия получаешь не много. Только ведь ты программистом работаешь не для того, чтобы получать удовольствие. Правда?
Новому человекуВ Фортране или в программировании?
Я никаких проблем с вниканием в него не заметил.
От выбора компилятора тоже много зависит - те же CVF и IVF в этом смысле сильно различаются.
В Фортране, конечно
прогу надо сделать многопоточнойА где она будет выполняться?
А то есть такой интересный проект в Переславле - под него мне понравилось писать многопоточные приложения.
фортран отбрит к черту после детального изученияМожет раскажешь подробнее? Меня этот вопрос очень интересует.
Если ты не получаешь удовольствия от работы, почему бы не поменять профессию?
Только ведь ты программистом работаешь не для того, чтобы получать удовольствие. Правда?Звучит очень странно
Если ты просто зарабатывать деньги хочешь - есть работы значительно денежнее.
А если и не для того, и не для другого - тогда что, просто больше ничего не умеешь что ли?
Больше всего я писал на Йаваскрипте и на Йаве + понемногу на С/С++/Сшарп.
Необычные моменты были, но хорошая книжка + форум все порулили
Необычные моменты были, но хорошая книжка + форум все порулили
Если ты не получаешь удовольствия от работы, почему бы не поменять профессию?
Не думал, что флудерская фраза вызовет такой живой отклик.
Я получаю большое удовольствие от программирования, но работаю не только ради него. В частности, лежать на диване и смотреть Вавилон 5, мне подчас, особенно по выходным, нравится больше. Есть даже несколько разделов математики занятие которыми мне тоже приносит удовольствие. Вот только математикой сыт не будешь, по крайней мере, с моими способностями к ней.
А если и не для того, и не для другого - тогда что, просто больше ничего не умеешь что ли?
Умею, но не профессионально. В какой-то момент я для себя решил, что моим хлебом будет программирование, после этого вторичные для этой специальности скиллы развивал очень слабо.
Так и от программирования на С тоже удовольствия получаешь не много.Да нет, нормально так.
Только ведь ты программистом работаешь не для того, чтобы получать удовольствие. Правда?Мне приятнее получать удовольствие, чем не получать.
Если в языке нет поддержки ООП, писание "в ООП-стиле" требует некоторых лишних усилий.
В Quake предметная облать весьма бедная. Там и без ООП можно обойтись.
В Quake предметная облать весьма бедная. Там и без ООП можно обойтись.
нет, ну, конечно, ученым - не программистам этот язык в самый раз... Чисто исторически, фортран возник достаточно давно, т.е. его можно назвать ранним языком... Однако программисты пошли дальше. А для ученых возможностей, видимо, хватает... Вот только возинкает одна проблемка: большинство человек, которые более-менее искушены в программировании на других языках, посчитают фортран недоязыком, потому-что в нём тесно. Даже расширения синтаксиса не сильно его улучшили, а всего-лишь сделали не столь отстающим... Ведь фиксированная запись была введена для упрощения трансляции (ресурсы поджимали).
Я не являюсь опытным программистом, поэтому не могу разложить причины написанного "по полочкам", однако расскажу конкретный случай: когда-то мне дали разобраться в библиотеке xml_parser для фортрана... Кто-то её написал, а мне нужно было проанализировать, можно ли ей будет воспользоваться для одного проектика... Я тогда фортран совсем не знал. Почитал немного про синтаксис (уже тогда у меня вызывала отвращение куча лишних вещей, которыми программист, использующий более современные языки, не сталкивается, да и вообще, каким-то убогим казался посмотрел эту библиотечку... Короче, структура xml-ки задавалась прямо в програмном коде... Т.е., ограниченность языка сыграла главную роль в невозможности сделать более гибкую библиотеку (чего очень хотелось). Когда я спросил, почему юзается фортран, а не С, мне ответили, что под фортран куча готовых библиотек уже отлаженных. Вот и юзают, чтобы не заморачиваться в проверке корректности работы квадратного корня из комплексного числа и т.п....
Я не являюсь опытным программистом, поэтому не могу разложить причины написанного "по полочкам", однако расскажу конкретный случай: когда-то мне дали разобраться в библиотеке xml_parser для фортрана... Кто-то её написал, а мне нужно было проанализировать, можно ли ей будет воспользоваться для одного проектика... Я тогда фортран совсем не знал. Почитал немного про синтаксис (уже тогда у меня вызывала отвращение куча лишних вещей, которыми программист, использующий более современные языки, не сталкивается, да и вообще, каким-то убогим казался посмотрел эту библиотечку... Короче, структура xml-ки задавалась прямо в програмном коде... Т.е., ограниченность языка сыграла главную роль в невозможности сделать более гибкую библиотеку (чего очень хотелось). Когда я спросил, почему юзается фортран, а не С, мне ответили, что под фортран куча готовых библиотек уже отлаженных. Вот и юзают, чтобы не заморачиваться в проверке корректности работы квадратного корня из комплексного числа и т.п....
Такое ощущение, что все видели только старый фортран =(
нет, ну, конечно, ученым - не программистам этот язык в самый раз
Можешь провести четкую грань между ученым и программистом?
Чисто исторически, фортран возник достаточно давно, т.е. его можно назвать ранним языком... Однако программисты пошли дальше
Так Фортран тоже пошел дальше
большинство человек, которые более-менее искушены в программировании на других языках, посчитают фортран недоязыком, потому-что в нём тесно
Очень хотелось бы пообщаться с ними и узнать их аргументированное мнение.: Короче, ссылку в студию
Ведь фиксированная запись была введена для упрощения трансляции
Фиксированная запись была введена исключительно для того, чтобы размещать программы на перфокартах (когда-то это был единственный способ ввода). Ресурсы тут совсем не при чем
По поводу примера - если кто-то решил задачу именно так - это еще ничего не значит - на любом языке можно написать плохо.
Например, имея опыт написания на языке, поддерживающем одну парадигму, и перейдя на язык, поддерживающий другую, вполне можно накосячить.
Решение можно рассматривать только по совокупности всех условий.
Да и не похоже, чтобы авторы этого примера были проф программерами.
Иначе они использовали для парсинга xml-я более подходящий язык.
Когда я спросил, почему юзается фортран, а не С, мне ответили, что под фортран куча готовых библиотек уже отлаженных.
О том, что можно использовать код на фортране и на си в одном проекте, они конечно же не в курсе?
п.с.: Так что пока вопрос остался открытым...
У меня тоже такое ощущение
А как насчет моих вопросов?
А как насчет моих вопросов?
По поводу того, что он лучше или хуже других языков программирования аргументированного мнения ни разу не встречал. Просто его не любят почему-то. =)
А ты сам кроме фортрана на чем пишешь?
Только на Delphi
Так что сравнивать мне не с чем, но прояснить ситуацию все же хочется =)
Так что сравнивать мне не с чем, но прояснить ситуацию все же хочется =)
Осталось найти прояснителя...
Оставить комментарий
NataNata
мне надо писать прогу, по большей части вычислительную, пока что на win32, в будущем предполагающую, что ее нужно будет портировать под unixы и прочиевопросы: 1) как правильно организовать структуру программы, чтобы структура в принципе предполагала возможность быстрой переделки проги под другую платформу - ну, скажем, всего лишь путем замены пары небольших файлов с исходниками?
2) язык программирования? (java не пойдет, тк нужна существенная вычислительная производительность)