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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Игорь Козин
To : Alexander Conon
Subj : Может я не прав, но..
> >>Прошу прощения, это о каком фортране идет разговор? 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 в С :( Вот уж действительно уродство получается...



>


Fri 13 Jul 2007 16:04 Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1.4) Gecko/200



Programmed by Dmitri Maximovich, Dmitry I. Platonoff, Eugen Kuleshov.
25.09.99 (c) 1999, RU/2. All rights reserved.
Rewritten by Dmitry Ban. All rights ignored.