RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : Ответить на сообщение

Имя:
e-mail:
FIDO:
Home page:
сохранить данные о вас

Тема:

> > >>Прошу прощения, это о каком фортране идет разговор? FORTRAN-4, FORTRAN-77,
> > >это разве не одно и то же?
> > >Ну-у, батенька Вы даете. 
> > кст почему на вы? я ж вроде пока сильно не хамил... :)
> 
>   Послушай как звучит "батенька ты даешь"... Не-е, "батенька" это только "Вы" :)
> 
> > 
> > >Совсем нет... Вот, специально на Wiki залез посмотреть потому как 
> > >почуял бесовщину 
> > никакой бесовщины. мамайкилянусь!
> > просто определенно где-то видел :"фортранIV ака фортран-77"
> 
>   "Если на клетке с тигром видишь надпись "медведь", то не всему писаному верь" :) 
>  
> > >>>FORTRAN-90?
> > >>про это разговора не было
> > >Вот потому я и спрашивал о КАКОМ Фортране идет речь, потому как Фортраны 
> > >разные бывают. 
> > 4. во всяком случае я именно про него говорил.
> 
>   Ага. Вот теперь когда определен предмет разговора можно более конкретно поговорить о возможностях, скоростях и пр.
> 
> > 
> > >А кстати, почему 90 не рассматривается? 
> > а кто сказал "не рассматривается"? если хочешь - рассмотри. 
> > просто мне про него сказать нечего.
> > 
> > >А ведь есть еще 92/2003 и даже (вот ересь-то) 2008. Забавно, 
> > >кстати как это все в сторону нелюбимого C++ мигрирует. 
> > угу. этот цэ - чума натуральная.
> > жить захочешь еще не так раскарячешься. (с)
> 
>   А ты не подумал, что объяснение может быть более естественное, чем массонский заговор любителей C? Ну, например, нехватка чего-то у Фортрана...
> 
> > вот ты сам и сказал на каком языке думаешь - на языке блок-схем.
> 
>   С чего ты решил? Просто блок-схема это еще одно представление логики программы, причем языково-независимое...
> 
> > >Вот другая вещь очень сильно на мозги давит - после любого 
> > >объектно-ориентированого языка (того же Turbo Pascal) работа в языке 
> > >не поддерживающем объектную модель - сплошное мучение. Все так 
> > >и наровишь объект создать и его сугубые свойства внутри от всех спрятать 
> > >и не передавать в функцию каждый раз 99 параметров :(
> > эк тебя скрутило... однако при желании и к фортрану оо приделать можно.
> > правда судя по дельфям/паскалям это оо столько ресурсов жрет 
> > что потеряется сам смысл использования именно фортрана.
> 
>   А скажи-ка мне дружок, знаешь ли ты какой реальный оверхед при реализации вызова метода объекта в так охаеваемом тобой дельфи-паскале? Так вот, это всего один дополнительный указатель (self) передаваемый как первый параметр при вызове метода. На фоне всего остального это такая мелочь. Зато я видел не объектный код когда в функцию передается 20-30 параметров, вот это действительно Ж.
> 
> > 
> > >>а если серьезно так скорость разработки у него точно на высоте.
> > >>это одной из его задач было.
> > >Разработки чего, метода наименьших квадратов? 
> > имо скорость разработки в этом плане мало зависит от конкретной задачи.
> > впрочем ты можешь лично проверить.
> 
>   Зависит и существенно от наличия стандартных библиотек...
> 
> > 
> > >К сожалению для Фортрана большая часть нынешних прикладных программ 
> > >вообще не нуждаются в мощных вычислениях. У них другие проблемы - 
> > >окошки там разные, кнопочки, на мышку вовремя среагировать... :( 
> > >Не бейте, дяденьки, я ж не говорю про программы типа FLUENT 
> > >(хотя и они потихоньку на C++ переползают :( судя по версиям виденным 
> > >пару лет назад).
> > как меняется со временем скорость апликух я сам вижу.
> 
>   Однако-ж и задачи ими выполняемые тоже... Тот же FLUENT, например. 
> 
> > >Я с легкостью берусь затормозить программу раз примерно в 100 используя, 
> > >например экранный контрол для хранения промежуточного резульата цикла 
> > >(реальный пример из моей бывшей конторы, кстати :( ). Но это не проблема 
> > >конкретного языка, а людей которые плохо понимают что они делают.
> > речь идет не о том как ее затормозить а о том как ее ускорить
> 
>   Не-е. Мы говорим о том, что написать медленную программу можно на чем угодно. И компилятор тут не спасет. Поэтому когда ты говоришь, что программы на C становятся медленнее, это не корректно. Ширпотребные программы вообще становятся медленнее независимо от того на чем написаны из-за низкой квалификации программистов. Еще раз повторяю, даже твой любимый фортран от дурака не спасет.
> 
> > 
> > >А вот что там последние тесты говорят? Какой выигрыш у Фортрана 
> > >по сравнению с последними C++ компиляторами? В конкретных цифрах?
> > ну не помню я конкретные цифры... застрелиться мне теперь?
> 
>   А тогда о чем спор? О сферическом коне?
> 
> > >>а с чего это goto вдруг стали непрозрачными?
> > >Да очень просто. Самое первое, что приходит в голову:
> > >"C":
> > >if( ){
> > >foo();
> > >foo1();
> > >else { // - вот тут скобочку закрыть забыли...
> > >foo2()
> > >}
> > >"F" (прошу прощения если не совсем точно, лет д-цать Фортраном 
> > >не пользовался)
> > >IF THEN 10, 10, 30
> > >10 FOO
> > >FOO1
> > >GOTO 40 - представьте себе тут GOTO потерялось.
> > >30 FOO2
> > >Так вот не надо наверное объяснять, что любой самый убогий C-шный 
> > >компилятор завопит, что вы скобочку забыли закрыть. А вот с точки 
> > >зрения Фортрана (по крайней мере FORTRAN-IV, в котором конструкции 
> > >IF THEN ELSE не поддерживаются) отсутствие "GOTO 40" ошибкой не является...
> > зашибись. для цэ привел пример грамматической ошибки
> > а для фортрана "потерялся" целый оператор.
> 
>   Вот в том-то и идея. Незакрытая скобка для С грамматическая ошибка отлавливаемая на этапе компиляции, а для фортрана прямая головная боль программиста, поскольку перед TRUE секцией ДОЛЖЕН быть GOTO.
> 
> > тебе фортран-компилер кофе в постель должен подавать? 
> > на це в "<=" потерять "<" можно куда проще и результат будет
> > таким же интересным и компилер тоже ничего не скажет.
> 
>   Вот. Наконец-то, хоть один реальный пример... Согласен, сам не люблю = и ==. Однако любой приличный С компилятор уже давно научен выдавать предупреждение (а то и ошибку) в этом случае... Прогресс не стоит на месте.
> 
> > >>>и COMMON блоков можно умишком тронуться.
> > >>язык создавался как способный выжать из железа максимум.
> > >>а уж будет програмер трудиться экономя ту же память
> > >>или решит что ее у него и так навалом - так это сам програмер и решает.
> > >Здрасьте, мы же тут об эффективности. А Вы "будет программист или нет". 
> > >Если не будет, то хорошо, а если будет, то тут-то и тронется пытаясь 
> > >отследить что на что наезжает... Вот тут-то динамическое распределение 
> > >памяти (см. Фортран 90) и помогает.
> > >И в "C" никто не заставляет программиста некорректные (рискованые) 
> > >методы использовать. Хотя и есть возможность. 
> > пааазвольте. в 4 тоже есть динамическое распределение памяти.
> 
>   НЕТУ в IV явного динамического распределения памяти. Почитайте стандарт. Вот напишите-ка мне древовидную структуру произвольного размера на Фортране IV.
> 
> > >И, кстати, а чем по-Вашему "С" таки идеологически хуже Фортрана? 
> > >Конкретные примеры, можно "в студию"?
> > дык как бы уже. апликухи все жирнее и тормознее
> > и их хистори - непрерывный и нескончаемый бугфикс.
> > оно конечно и на фортране можно написать тормозную прогу
> > и ошибку можно сделать но на нем это будут исключения
> > а на цэ - это правило. это просто вдобавок к тому
> > что все-таки язык - это и стиль мышления тоже :)
> 
>   Так все-таки какие особенности С (только КОНКРЕТНО) приводят к его непрозрачности? Если не будет конкретики, обсуждать будет нечего.
> 
> И кстати, никто не мешает использовать goto в С :( Вот уж действительно уродство получается...
> 
>   
> 
> > 
>

_, _, _, _, _ _, _,_ (_ \| / \ \|\ \| / \ \|_/ , ) \| , \ / \| \\| \ / \| \ ~ ~~~ ~ ~ ~ ~ ~ ~