Язык для обучения программированию

Потом, когда стал работать с людьми, которые реально занимаются моделированием, внезапно выяснилось, что вычматы на c++ херачат только избранные мазохисты

Значит мы с коллегами эти самые избранные мазохисты. Тока один пример - программа для газодинамики горения (Эрика Эриксона, 1995г), 4000 строк на фортране. 1000 строк скажем там интерфейс, то что я на питоне делаю в 40 строк, ладно. Но числ ядро 3000 строк, это против 420 строк на С++ уже моего кода по моделированию многофазной фильтрации (сравнение не вполне корректно, все таки разные методы, у меня неявная схема для давления, но горение и там и там есть, и таки многофазная фильтрация погеморней будет). Ну и примеров таких масса...

Фортран выигрывает за счет предельной простоты и огромного кол-ва библиотек. Но возможности С++ куда шире все таки... и наконец, у меня есть железобетонный аргумент (который я на ЛОРе каюсь уже тыщу раз приводил) - самые быстрые в мире коды для моделирования довольно широкого класса задач пишутся сейчас нами именно на связке Python/С++, и на фортране это вряд ли вопроизводимо... подробнее тут www.linux.org.ru/wiki/en/User:AIv/LRnLA

Ну, например, обычные списки в си

В C нет обычных списков.

Да что-то не сильно шлифовавшийся лет на 20 больше Фортран быстрее С

O_O? Шутите?

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

Функция f(x)=x^2 зависит от конкретного значения x? Или всё-таки существует сама по себе, для всех x одновременно?

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

Ну как же нет? тип list = nil U (cons a (list a)) (для конкретного а, конечно, полиморфных типов нет).

Если первое - семантика зависит от времени. Если второе - очевидно, нет.

Ну вот, ты и ответил на свой вопрос сам.

А что, Portage, deluge,mercurial и проч - мелкая скриптня?

тип list = nil U (cons a (list a)) (для конкретного а, конечно, полиморфных типов нет).

Ты всерьёз считаешь, что это C?

Это не я:-) не пали

А что, Portage, deluge,mercurial и проч - мелкая скриптня?

Depends. Бывают коллекции (пусть и большие) никак не связанных друг с другом мелких скриптов. Бывают большие программы, сделанные при помощи негодных инструментов.

Можем. И будет это выглядеть как \x -> x+1.

разве IORef так выглядит?

Судя по http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest... разница не сильно большая.
Кидайте, mc.yunusov@gmail.com

разве IORef так выглядит?

А ты что спросил?

Ты всерьёз считаешь, что это C?

Это не Си, это тип, который можно выразить в Си. U - юнионы, произведения - структуры с поинтерами.

не понял, что?

Ну вот, ты и ответил на свой вопрос сам.

Согласно твоему определению - первое. То есть зависит от времени. Но в самом начале ты сказал, что семантика от времени не зависит. Как быть?

Там вопрос не в ЯП а в кривизне рук программиста. На самом деле разницы никакой нет наск я понимаю, все различия в производительности связаны с различиями в традициях реализации алгоритма. «Фортран быстрее С» это такой же бред как и «C быстрее С++».

Послал.

Ну просто обычных данных в хаскеле нет - только коданные. О чем и речь.

ADT могут быть обычными данными либо коданными только по отношению к стратегии вычисления кода который с ними работает. В хаскеле реализованы обе стратегии - и строгая и нестрогая, так что можно использовать хаскельный РТД лениво (точнее, нестрого) и тем добиваться инфинитности данных, но можно и строго (с помощью seq, ($!)), тогда данные будут финитны. В си РТД вида:

typedef struct nat {
    struct nat *succ;
} nat;

может быть обработан только строго (ну, без VM games если), и поэтому может служить только для финитных данных.

Это не Си, это тип, который можно выразить в Си.

Ну, попробуй.

Дело не в том, какой код работает, а в том, какие значения принадлежат типу. Если твоему Nat принадлежит бесконечность - это нихрена не данные. Как с ними ни работай.

не понял, что?

Твой предыдущий вопрос не был посвящён деталям функционирования IORef. Поэтому, естественно, я опустил вызов modifyIORef.

Согласно твоему определению - первое.

Это с чего бы?

Я уже написал, как выражать (юнионы, структуры и поинтеры).

Ну как с чего? вот определение твое:

Под операционной семантикой — интерпретацию валидной программы как последовательности элементарных операций.

«интерпретация», а не «функция, которая каждому моменту времени сопоставляет интерпретацию».

Я уже написал, как выражать (юнионы, структуры и поинтеры).

Ещё раз: попробуй СДЕЛАТЬ. Или ты хочешь сказать, что это больше десятка строк?

Да, и, разумеется, сделать так, чтобы там не было бесконечных списков (мы же про индуктивные говорим?)

«интерпретация», а не «функция, которая каждому моменту времени сопоставляет интерпретацию».

«Валидная программа» — это свободная переменная. Терм со свободной переменной означает именно что функцию.

Ну в случае modifyIORef у нас лямбды не будет, так?

«Валидная программа» — это свободная переменная. Терм со свободной переменной означает именно что функцию.

Так переменная «валидная программа» пробегает моменты времени? Другими словами, твое определение значит: «интерпретацию момента времени как последовательности элементарных операций». По-моему, тут нет никакого смысла.

А, я знаю. Сейчас окажется, что программа - это, на самом деле, не сам программный код, а программный код*текущий момент времени, лол.

Я это и имел ввиду, говоря что не очень сильно, в пределах погрешности, быстрее ассемблера всё равно не получится.

Принял, спасибо.

union list { struct zero {int i;} z; struct cons {int head; list* tail;} c; };

как- то так.

Если твоему Nat принадлежит бесконечность - это нихрена не данные.

Ещё раз:

data N = Z | S N
  deriving Show

infinite :: N
infinite = S infinite

-- infinite
-- > (S (S (S (S (S (Interrupted.

finite :: N
finite = S $! finite

-- finite
-- C-c C-cInterrupted.

что хочешь, то и получаешь - хочешь данные, хочешь коданные. Так как второй вариант в данном случае не имеет смысла - получаем bottom, т.е. как раз факт отсутсвия бесконечного значения при применении строгой стратегии вычисления. В сишке второму будет соответствовать:

#include <stdlib.h>

typedef struct nat {
    struct nat *succ;
} nat;

nat *inf(void)
{
    nat *x = malloc(sizeof(nat));
    x->succ = inf();
    return x;
}

и тоже infinite loop, первому прямого аналога нет.

что хочешь

Что значит что хочешь? У тебя есть конкретный тип - этому типу соответствует конкретное множество значений. Если у тебя там сидят бесконечности - это коиндуктивный тип.

Можно просто struct list { struct list* tail; int head; }; и выявлять конец списка по tail == NULL.

А что такое нельзя делать на фортране, а можно на питоне то?

Графики рисовать, например, гораздо удобнее на питоне.

и я так понял все эти десять лет газодинамикой занимаешься?

Научкой разной.

Ну ладно, я хотел сказать, что если нужны финитные строгие / инфинитные ленивые данные, то есть выбор и перепутать одно с другим сложно. Что там терминологически это уже не так важно (а то тогда можно потребовать язык в котором есть прямые data и codata определения).

1000 строк скажем там интерфейс, то что я на питоне делаю в 40 строк, ладно. Но числ ядро 3000 строк, это против 420 строк на С++

Чего-то вы как-то не так фортран используете.

На нём не надо писать интерфейс, он не для этого. Первый раз слышу чтобы аналогичный вычислительный код на фортране был в 10 раз длиннее, чем на c++. В фортране, в отличии от c++, есть нормальные операции с многомерными массивами, ими надо пользоваться. Там где на c++ надо делать несколько вложеных циклов, на фортране часто можно одним выражением обойтись. Операции с массивами в фортране работают очень быстро.

Ну ладно, я хотел сказать, что если нужны финитные строгие / инфинитные ленивые данные, то есть выбор и перепутать одно с другим сложно.

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

Но числ ядро 3000 строк, это против 420 строк на С++

Типичная разностная схема на фортране это вот:

u(1:n-2, 1:m-2) = ((u(0:n-3, 1:m-2) + u(2:n-1, 1:m-2))*dy2 + &
(u(1:n-2,0:m-3) + u(1:n-2, 2:m-1))*dx2)*dnr_inv

одна строка.

Вот я примерно об этом.

Как альтернатива - выводить «этот код использует ленивую стратегию» и «этот код - строгую» как особые типы?

Можно сделать два типа и две разных реализации, на честном слове - что для одного типа делаем одну стратегию, для другого - другую, сейчас так обычно и делаю (Strict.ByteString и Lazy.BiteString, например), так удаётся избегать конфликтов строгих и ленивых данных (типы-то разные).

на честном слове

nuff said :)

nuff said :)

Я верую, я верую, что Strict.ByteString работает строго, ммм...

Чего-то вы как-то не так фортран используете.

Это не мы, мы его вообще не используем.

В фортране, в отличии от c++, есть нормальные операции с многомерными массивами, ими надо пользоваться. Там где на c++ надо делать несколько вложеных циклов, на фортране часто можно одним выражением обойтись.

На с++ аналогичные операции делаются по мере необходимости, как и многое другое. Более того, за счет шаблонов такие операции можно раскручивать во время компиляции.

Операции с массивами в фортране работают очень быстро.

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

Типичная разностная схема на фортране это одна строка.

Есть довольно много всяких шняг в плюсах, позволяющих делать аналогичные вещи. Напр foreach в stl... более того, это работает не только для трад массивов но и для особо извращенных.

А во что это развёртывается, а?

На с++ аналогичные операции делаются по мере необходимости, как и многое другое.

Я понимаю, что по мере необходимости на c++ можно сделать всё что и на фортране, но всё это требует определённых усилий. В фортране всё необходимое для числодробилок уже есть в языке. Это очень удобно, если ты инженер или научный сотрудник, а не программист.

А во что это развёртывается, а?

В смысле?

Как на C будет выглядеть в смысле, правда уже распарсил, лишние 3 строчки и строки подлиннее, да.

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

Если ты пишешь на плюсах и тебе нужно что то для работы с многомерными массивами напр. - ты не делаешь это сам а берешь нужную библиотеку;-). Хотя я вот сам сделал...

И потом, а как на фортране будет выглядеть схема, не укладывающаяся в одно выражение? Будет неск циклов (по числу выражений)? Но это же жутко неэффективно... или придется писать ручками явно цикл, то тогда какой тут выигрыш по сравнению с С?

Даже в приведенном примере схема неск странная, там часом не += ли нужно? И как это реализуется, без явного создания пользователем временной переменной (массива)? Временная переменная (массив) создается автоматически? А насколько это оптимально? Потому что если в лоб сделать, оно будет ес-но неправильно...