Fortress 1.0

> Господин ламер, на каждой платформе есть свой компилятор JVM->native. Стукните себя вилкой в глаз, пожалуйста.

И что, вы уже перекомпилили netbeams? Не порите чушь, ей больно. Компилять jvm->native можно свои проги. Я думаю, мало кто занимается таким для скаченных только что из инета ява-прог, тем более на телефонах! Маркетоиды промыли вам мозг, а вы ведётесь. Ява по определению медленней скомпиленных програм. /end of flame.

> Кстати, насколько я понимаю, на одних только лямбдах в пистоне то же самое не сделать, придётся именованные определения вставлять. Так что VB.NET лучше как минимум пистона.

"Если вам кажется, что анонимус прав, вы ошибаетесь"

Вот, лови Y-комбинатор на Python без именованнных функций:

Y = lambda f : (lambda rec: f(lambda x: rec(rec)(x))) (lambda rec: f(lambda x: rec(rec)(x)))

fb = Y(lambda factorial: lambda x: 1 if x <= 1 else x * factorial(x - 1))

print fb(10)

>> Господин ламер, на каждой платформе есть свой компилятор JVM->native. Стукните себя вилкой в глаз, пожалуйста.

> И что, вы уже перекомпилили netbeams? Не порите чушь, ей больно. Компилять jvm->native можно свои проги. Я думаю, мало кто занимается таким для скаченных только что из инета ява-прог, тем более на телефонах! Маркетоиды промыли вам мозг, а вы ведётесь. Ява по определению медленней скомпиленных програм. /end of flame.

Госпдин ламер, убейтесь пожалуйста.

Восхищен маркетингом МС - почему-то при том же JIT-compiler никакие ламеры не называет C# - интерпретируемым. А Сан все от Java 1.0 не может отмыться....

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

>Извините, все это пустые декларации. Замените в этой фразе "язык" на любое другое сужествительное -- "матан", "теормех", "квантмех" -- и она останется столь же содержательной.

Странно: что Вы заметили "пустые декларации" в последней фразе разговора, но не замечаете пустоты в таком аргументе:"Многие недостатки Fortran являются устаревшими...", тогда как отмеченные Вами недостатки я прокомментировал и недостаками не считаю.

> Кроме того, думаю, что многие нынешние пользователи Фортрана пришли в него тем же путем, что и я сам: просто в наследство мне досталось много кода, написанного на этом языке

Возможно для Вас будет новостью узнать, но сейчас существуют новые проекты на Fortran класса 100TF. Они не доставались в наследство и Fortran бал выбран по вполне объективным причинам. По каким - смотрите выше.

>> Когда и если Вам придётся "выжимать" 1 процент от времени исполнения

>Никогда такой задачи не возникало и, думаю, не возникнет:

Так чего же Вы спорите?

> я ж не real-time управление ядерным реактором пишу

Подозреваю, что управление ядерным реактором не нуждается в повышении вычислительной производительности - чего там вычислять? А вот задаче моделирования термогидравлики ядра реактора совместно с моделированием производительности топлива, старением твеллов и нейтронопереносом очень бы пригодилось. Ну 1 процент - это я конечно утрирую, а вот 5-10% это уже реальная цель.

> Подождать еще 1% от _общего_ времени -- сущие пустяки.

Знаете сколь раз мне доводилось слышать эту фразу? Ещё добавляют "мне некогда заниматься оптимизацией", "мне надо считать", и в конце концов "я в этом всё-равно ничего не понимаю".

Дело в том, что любая задача "растёт", а с ростом задачи проблемы растут нелинейно. Ваш 1% на маленькой задаче может вылится в 5% на задаче в 2 раза большей, в 20% на задаче в 4 большей, а задачу в 8 раз больше Вы вообще посчитать не сможете именно из-за той проблемы в маленькой задаче. Но умение видеть рост алгоритма не имеет отношение к языку программирования вообще.

> Чаще всего возникает вопрос об ускорении в разы

Или Вы написали не более двух проектов или я вообще ничего не понимаю в этом мире. Ускорение в разы для хорошо написанного комплекса программ возможно только повышением степени распараллеливания. Редко, когда удаётся сменить метод, но это работает только при сильном увеличении размера задачи и опять упрёмся в ограниченность ресурсов.

Резюме: ускорение в разы достигается совсем другими методами, а не сменой языка программирования.

> отсутствие поддержки со стороны языка (в перевую очередь, его выразительности, дабы "ухватывать" взглядом как можно больший объем в целом) может неприятно сказаться

Программа пишется не на языке программирования. На языке программирования программа кодируется - а это уже совсем другое умение.

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

> изменить определение одного common-блока в своей программе: так я задолбался вручную по нескольким файлам (порядка 8) выискивать его объявление

здесь нечего комментировать кроме как "Fortran причём?". На любом языке можно так написать, что никто ничего разобрать не может. Кстати, иногда это делается специально. Вообще обфускация кода - очень распространённая практика и Fortran прекрасно поддерживает массу методов. common block - не только средство структурирования, но и замечательное средство запутать логику программы.

> избежать простыни аргументов, передаваемых в функцию

уверены в безукоризненном проектировании кода?

>А вот и убейся:

Как правильно сказал зефиров "моя голова". Там же приведена ссылка на y-комбинатор на простой жабе. Его можно с определенной степенью кривости сделать практически на любом языке. Посмотри на жабюаскрипт - он там вообще почти элегантен. ТАк что - жабаскрипт - тоже функциональный язык?

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

> > Извините, все это пустые декларации. Замените в этой фразе "язык" на любое другое сужествительное -- "матан", "теормех", "квантмех" -- и она останется столь же содержательной.

> Странно: что Вы заметили "пустые декларации" в последней фразе разговора, но не замечаете пустоты в таком аргументе:"Многие недостатки Fortran являются устаревшими...", тогда как отмеченные Вами недостатки я прокомментировал и недостаками не считаю.

Я безусловно рад за Вас, но то, что Вы их не считаете их недостатками еще не означает то, что они не _являются_ ими. Не находите странным выдавать субъективное ощущение за объективную реальность?

> > Подождать еще 1% от _общего_ времени -- сущие пустяки.

> Знаете сколь раз мне доводилось слышать эту фразу? Ещё добавляют "мне некогда заниматься оптимизацией", "мне надо считать", и в конце концов "я в этом всё-равно ничего не понимаю".

Не приписывайте, пожалуйста, высказываний, которые я не делал. Любая оптимизация небесплатна -- если я займусь ею, то это будет означать, что что-то останется без моего внимания. Кроме того, оптимизованный алгоритм обычно труднее для сопровождения, в нем можно сделать больше ошибок при модификации, да и доказать, что он работает правильно тоже труднее. Фортран приучает к одной, очень дурной, по моему мнению, привычке: думать так, как думает машина. Это хорошо лишь на _последней_ стадии реализации проекта, но никак не на этапе постановки задачи, выбора алгоритма решения и прототипизации задачи (написания прообраза рабочего кода).

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

> Дело в том, что любая задача "растёт", а с ростом задачи проблемы растут нелинейно. Ваш 1% на маленькой задаче может вылится в 5% на задаче в 2 раза большей, в 20% на задаче в 4 большей, а задачу в 8 раз больше Вы вообще посчитать не сможете именно из-за той проблемы в маленькой задаче. Но умение видеть рост алгоритма не имеет отношение к языку программирования вообще.

Не мешайте, пожалуйста, в кучу, масштабируемость алгоритма или программы с абсолютным временем выполнения при заданных параметрах. Я ни за что не буду на 1% ускорять программу, выполняющуюся секунды (я думаю, и Вы тоже), но предпочту программу, масштабирующуюся линейно, программе, масштабирующейся квадратично, даже если первая проигрывает 1% на конкретном расчете.

> Или Вы написали не более двух проектов или я вообще ничего не понимаю в этом мире. Ускорение в разы для хорошо написанного комплекса программ возможно только повышением степени распараллеливания. Редко, когда удаётся сменить метод, но это работает только при сильном увеличении размера задачи и опять упрёмся в ограниченность ресурсов.

> Резюме: ускорение в разы достигается совсем другими методами, а не сменой языка программирования.

Я действительно пишу относительно небольшие проекты, но тем не менее, могу привести как минимум один реальный пример, когда мне помогла смена языка: когда мне пришлось писать алгоритм адаптивного интегрирования трехмерной функции на сетке. Шаг сетки должен быть тем меньше, чем больше абсолютное значение функции на нем. После мучительных рабирательств с ужасающей цепочкой условных конструкций и не получив работоспособного кода, я, в конце концов, написал маленький пример интегрирования в итеративном стиле на scheme. Добившись того, чего мне надо (а в 10 строках разобраться оказалось не в пример легче), я просто переписал его на С. Что бы пришлось делать с Фортраном -- не представляю даже. Самое удивительное, что эта программа в элементарном случае (одномерное интегрирование) работает (и масштабируется) как минимум не хуже, чем написанная в обычном (императивном) стиле.

> > избежать простыни аргументов, передаваемых в функцию

> уверены в безукоризненном проектировании кода?

Совершенству нет предела (если нет другого дела). Так что ответ "нет" по-умолчанию. Однако в моем случае оказалось, что в довольно элементарной функции оказалось много параметров -- так поставлена задача. Искусственно (предвычислениями) можно было бы уменьшить их число, однако это лишает код "независимости", внедряя и связывая его с другими программными блоками.

> Из моего опыта - самые дурно написанные программы выходят от физиков-теоретиков, которые считают себы продвинутыми программистами.

Почти про меня. :-)

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

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

"самым приятным программирование нахожу программирование в функциональном стиле во встроенном языке Maple"

то Вам наверное не следует выражать своё мнение по поводу методов и языков программирования терафлопсных машин.

p.s. поймите меня правильно, я ни в коей мере не хочу Вас оскорбить. Но Вы сейчас ведёте разговор Шарикова.

> то Вам наверное не следует выражать своё мнение по поводу методов и языков программирования терафлопсных машин.

Я ни разу не говорил, как нужно программировать терафлопные машины. Я говорил о _возможных_ причинах отказа от Фортрана и появления вот этого самого детища -- Fortress'а. А также о том, когда Фортран (по моему мнению), применять не следует.

Более того, что-то мне кажется (хотя я здесь точно не буду настаивать на своем мнении), что надстройки в виду MPI или OpenMP примерно одинаково искусственно смотрятся что в Фортране, что в С.

> p.s. поймите меня правильно, я ни в коей мере не хочу Вас оскорбить. Но Вы сейчас ведёте разговор Шарикова.

Отвечу реверансом, что приятно поговорить с дельным человеком, но все-таки я не совсем Шариков.

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

Хотя, Вы, наверное, правы. Не вижу в программировании нечего интересного, хотя и занимаюсь им, поскольку почти в любом журнале, даже самом отмороженном (в хорошем смысле) типа Phys.Rev.*, хотять видеть цифирь.

> Возможно для Вас будет новостью узнать, но сейчас существуют новые проекты на Fortran класса 100TF. Они не доставались в наследство и Fortran бал выбран по вполне объективным причинам.

Ха, удивили. Если выбор был между Fortran и C/C++ (а что еще есть живого для MPI/OpenMP?) - понятно, что разумные люди выбрали Fortran.

>> то Вам наверное не следует выражать своё мнение по поводу методов и языков программирования терафлопсных машин.

>Я ни разу не говорил, как нужно программировать терафлопные машины. Я говорил о _возможных_ причинах отказа от Фортрана и появления вот этого самого детища -- Fortress'а. А также о том, когда Фортран (по моему мнению), применять не следует.

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

> надстройки в виду MPI или OpenMP примерно одинаково искусственно смотрятся что в Фортране, что в С.

А разве это важно?

>все-таки я не совсем Шариков

Если бы Вы были Шариков, разговора бы не было вообще. Я лишь отметил, что мы занимаемся совершенно разными делами и Вы случайно (или просто из интереса) стали рассуждать о моей области без достаточного опыта. Делать этого нельзя.

> Ха, удивили. Если выбор был между Fortran и C/C++ понятно, что разумные люди выбрали Fortran.

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

> Если бы Вы были Шариков, разговора бы не было вообще. Я лишь отметил, что мы занимаемся совершенно разными делами и Вы случайно (или просто из интереса) стали рассуждать о моей области без достаточного опыта. Делать этого нельзя.

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

> Ха, удивили. Если выбор был между Fortran и C/C++ понятно, что разумные люди выбрали Fortran.

> Даже в этом топике отметились несколько человек, считающих что Fortran мёртв и писать на нём "в наше время космических кораблей" может только "человек очень тонкой душевной организации" ;)

Но и с этими людьми я тоже, в некотором роде, согласен. Выбор-то был сделан вероятно от того, что больше выбирать и нечего :(

> Фортран сейчас властвует там именно ввиду того, что он приучает думать и дейтсвовать так, как машина, точнее, как машина, производящая математические вычисления

> о мере наработки приемов массово-параллельного программирования будут внедрены более выразительные языки без особой потери этого самого параллелизма

Параллелизм совсем не при чём. Я уже писал выше - Fortran влавствует в мире суперЭВМ потому, что программисту требуется максимально возможный доступ к аппаратуре, а на ассемблере писать непереносимо. Хотя это тоже делается. Повторюсь, удобство и выразительность языка для программирования суперЭВМ - дело пятнадцатое.

> Я уже писал выше - Fortran влавствует в мире суперЭВМ потому, что программисту требуется максимально возможный доступ к аппаратуре, а на ассемблере писать непереносимо.

Э, а тогда как раз не ясно, чем С не помогло?

>Вот, лови Y-комбинатор на Python без именованнных функций:
>Y = lambda f : (lambda rec: f(lambda x: rec(rec)(x))) (lambda rec: f(lambda x: rec(rec)(x)))
>fb = Y(lambda factorial: lambda x: 1 if x <= 1 else x * factorial(x - 1))
>print fb(10)
>sv75

Я тупой :( Оно работает но как нефтыкну. sv75 - сжалься! Ткни ман чего ...

Лучше погугли (Y combinator Python etc), там есть вариант с именованными функциями, он попонятнее, и ссылки на теорию (вплоть до lambda-calculus).

Как можно заметить, lambda rec: f(lambda x: rec(rec)(x)) у меня дважды.

>> Компилятор с такой оптимизацией, до повсеместного введения libastral, не справится.

> Это не врите. Любая оптимизация, доступная человеку, доступна и машине, если, конечно, выражения вы оптимизируете не методом научного озарения.

Ээ... А что-нибудь из теории сложности алгоритмов нам известно? Бывает, именно методом научного озарения удаётся перейти от экспоненциального к полиномиальному времени - и хрен бы какой ГА здесь оптимизировал.

> Бывает, именно методом научного озарения удаётся перейти от экспоненциального к полиномиальному времени

Каким боком фортран этому помогает?

>> Бывает, именно методом научного озарения удаётся перейти от экспоненциального к полиномиальному времени

> Каким боком фортран этому помогает?

Никак. Вся фишка в том что, Fortress - тоже никак :)

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

>> Бывает, именно методом научного озарения удаётся перейти от экспоненциального к полиномиальному времени

>Каким боком фортран этому помогает?

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