фортран мля

[crazy-mike]

ты ето конечно сильно загнул... я почти обиделся... встаёт вопрос: чем можешь доказать свои слова?

1 ) Ты пробовал портировать программы на Фортране из 10000 строк и больше с одной машинной архитектуры на другую? Особенно когда длинна машинного слова и порядок следования байт в слове - довольно сильно различаются?
Иногда проще написать эмулятор процессора машины - чем перенести такое "высокоуровневое приложение"...
2 ) Методы компиляции для языка Фортран - это "что-то с чем-то"...Над ними можно очень долго смеятся...
3 ) Фортран провоцирует одни из самых идиотских ошибок программирования - которые вообще можно допустить.
4 ) Контроля за ошибками округления и стандартных средств управления поведением ошибок округления на уровне стандартных языковых средств не существует вообще. (о механизме exceptions - можно только мечтать)
5) Отсутствие рекурсивных процедур - архаический идиотизм..
Все вышеперечисленное - относится к стандартам языка Фортран. В специализированных расширениях (для микропроцессоров) - все еще хуже..

[marsel331]

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

на с++ я конечно перейду! но есть, бля, спортивный интерес - забубенить на фортрнае такую тему, чтобы никто нимог ничего против сказать, а только признать, что если есть желание и мозги, то и на калькуляторе мона спутник на Венеру запустить !!!

[marsel331]

1 ) Ты пробовал портировать программы на Фортране из 10000 строк и больше с одной машинной архитектуры на другую? Особенно когда длинна машинного слова и порядок следования байт в слове - довольно сильно различаются?
Иногда проще написать эмулятор процессора машины - чем перенести такое "высокоуровневое приложение"...
2 ) Методы компиляции для языка Фортран - это "что-то с чем-то"...Над ними можно очень долго смеятся...
3 ) Фортран провоцирует одни из самых идиотских ошибок программирования - которые вообще можно допустить.
4 ) Контроля за ошибками округления и стандартных средств управления поведением ошибок округления на уровне стандартных языковых средств не существует вообще. (о механизме exceptions - можно только мечтать)
5) Отсутствие рекурсивных процедур - архаический идиотизм..
Все вышеперечисленное - относится к стандартам языка Фортран. В специализированных расширениях (для микропроцессоров) - все еще хуже..

1) никогда не приходилось. ето уже ни маи проблемы
2) ето языг для численных расчётов. ты такие задачи решал?
3) фсе ошибки по концовке оказываются идиотскими там просто надо соблюдать некоторые правила и сафсем глупых ошибок мона избежать. надо просто привыкнуть...
4) не знаю про какой фортран ты говориш, но в visual fortran 6.6 всё мона настроить. правда там всё запутано и надо долго разбираться
5) нах они нужны. в задачах численного расчёта главное скорость и точность.
ты пойми, я не хаю другие языки. я даже очень хочу освоить некоторые. но со своими задачами фортран справляется просто прекрасно! я просто знаю многих умников, на своём фак-те, которые завыё..сь в самом начале и сейчас они просто сосут, когда мы начинаем сравнивать свои задачи и решения !!!

[Sixteen]

на с++ я конечно перейду! но есть, бля, спортивный интерес - забубенить на фортрнае такую тему, чтобы никто нимог ничего против сказать, а только признать, что если есть желание и мозги, то и на калькуляторе мона спутник на Венеру запустить !!!

да можно и на абакусе запустить. тока маленький, медленный и дурацкий

[crazy-mike]

1) никогда не приходилось. ето уже ни маи проблемы
2) ето языг для численных расчётов. ты такие задачи решал?
3) фсе ошибки по концовке оказываются идиотскими там просто надо соблюдать некоторые правила и сафсем глупых ошибок мона избежать. надо просто привыкнуть...
4) не знаю про какой фортран ты говориш, но в visual fortran 6.6 всё мона настроить. правда там всё запутано и надо долго разбираться

( 2 )
Я занимался портированием программ на Фортране с одной платформы на другую (с System/370 на микропроцессорные системы) и всем - что связано с портированием приложений такого рода более 10 лет...
Первое с чего вообще начинали System/370 <--> PDP/11 (перенос программ распознавания образов - обработка аэрофотоснимков и снимков со спутников).
На "клоне" PDP-11 работала RT-11SJ (модификация NTS-монитор) - с векторными процессорами и интерфейсом для программ на языке Fortran (стандарт Fortran-77 - там даже BYTE кроме LOGICAL*1 было в качестве типа данных).
( 3 )
правил там не то чтобы "вообще никаких нет" - а просто "сплошные исключения из правил"
(4) Я имел ввиду общепринятые стандартные (насколько это возможно) реализации языка FORTRAN (в стандартах не фикскируется порядок вычисления аргументов функций - а поскольку в процесс "вычисления функций" могут возникать изменения глобальной области данных - результаты могли получаться довольно "прикольными":
Мне больше нравился примерно такой "глюк":
COS(A) = COS(A) + 1
И результатом выполнения оператора C=COS(B) было что-то "очень странное".
Может быть за Fortran цепляются еще из-за "встроенной реализации комплексной арифметики" (комплексные числа) - но это уже просто глупость - из-за того что есть много красивых библиотек для C и С++. Есть очень интересный стандарт MISRA C - для приложений для embedded systems....
Популярность "фортрана для параллельных вычислений" - вероятно связана с особенностью "соглашений о связях" в ассемблерных программах для System/360 : Там стека не было вообще - каждая подпрограмма обеспечивала свою собственную область сохранения регистрового файла и адреса возврата. Эту особенность "унаследовали" большинство генераторов кода в компиляторах с языка Фортран.
Эту деталь также использовали в реализациях "сопрограмм" - после вызова подпрограммы можно было по RETURN позвращаться каждый раз в разную точку возврата. За счет этого моделировалась "квазипараллельная работа" на однопроцессорных системах.

[marsel331]

( 2 )
Я занимался портированием программ на Фортране с одной платформы на другую (с System/370 на микропроцессорные системы) и всем - что связано с портированием приложений такого рода более 10 лет...
Первое с чего вообще начинали System/370 <--> PDP/11 (перенос программ распознавания образов - обработка аэрофотоснимков и снимков со спутников).
На "клоне" PDP-11 работала RT-11SJ (модификация NTS-монитор) - с векторными процессорами и интерфейсом для программ на языке Fortran (стандарт Fortran-77 - там даже BYTE кроме LOGICAL*1 было в качестве типа данных).
( 3 )
правил там не то чтобы "вообще никаких нет" - а просто "сплошные исключения из правил"
(4) Я имел ввиду общепринятые стандартные (насколько это возможно) реализации языка FORTRAN (в стандартах не фикскируется порядок вычисления аргументов функций - а поскольку в процесс "вычисления функций" могут возникать изменения глобальной области данных - результаты могли получаться довольно "прикольными":
Мне больше нравился примерно такой "глюк":
COS(A) = COS(A) + 1
И результатом выполнения оператора C=COS(B) было что-то "очень странное".
Может быть за Fortran цепляются еще из-за "встроенной реализации комплексной арифметики" (комплексные числа) - но это уже просто глупость - из-за того что есть много красивых библиотек для C и С++. Есть очень интересный стандарт MISRA C - для приложений для embedded systems....
Популярность "фортрана для параллельных вычислений" - вероятно связана с особенностью "соглашений о связях" в ассемблерных программах для System/360 : Там стека не было вообще - каждая подпрограмма обеспечивала свою собственную область сохранения регистрового файла и адреса возврата. Эту особенность "унаследовали" большинство генераторов кода в компиляторах с языка Фортран.
Эту деталь также использовали в реализациях "сопрограмм" - после вызова подпрограммы можно было по RETURN позвращаться каждый раз в разную точку возврата. За счет этого моделировалась "квазипараллельная работа" на однопроцессорных системах.

можеш мне поверить в compaq visual fortran 6.6 глюка типа
COS(A) = COS(A) + 1 нету ) ты наверное так давно возненавидел фортран, что даже и не интересовался его обновками !!! и распараллеливать мона по настоящему(ето факт).

[Sixteen]

можеш мне поверить в compaq visual fortran 6.6 глюка типа
COS(A) = COS(A) + 1 нету ) ты наверное так давно возненавидел фортран, что даже и не интересовался его обновками !!! и распараллеливать мона по настоящему(ето факт).

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

[marsel331]

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

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

[crazy-mike]

и ещё раз хочу напомнить, то что ето язык специально для ... сами знаете!!!

1 ) В далеком 1960-м язык ФОРТРАН позиционировался как "универсальный язык програмирования" .
2 ) Функций - специфических именно для численных расчетов в языке ФОРТРАН нет вообще!!!!!
(стандартные математические функции - не имеются ввиду. Хотя даже и
3) Понятие "итератора" или "функционала" в языке ФОРТРАН вообще не наблюдается. Стандартных языковых средств для работы с матрицами даже в реализациях языка Бейскик больше....
ФОРТРАН - нонсенс имени ранней IBM (которая сама же предпринимала ряд попыток избавиться от этого "мутанта" - предлагая всем пользователям перейти на PL/1). Самое смешное - что в СССР как раз на PL/1 писалось большинство численных приложений , связанных с радиотехникой. И на ЕС ЭВМ (клон System/360, System/370) - PL/1 оставался самым популярным языком программирования. (в нем по крайней мере существовали довольно развитые языковые средства управления точностью вычислений).
Кстати - написать на ФОРТРАНЕ самоизменяющуюся во время выполнения программу в зависимости от типа поступающих на обработку данных - это один из самых экзотических способов интеллектуального самоубийства...

[Sixteen]

в общем марсель сам усе поймет. раньше али позже.