5-й номер журнала «Практика функционального программирования»

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

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

>да я разве спорю?! это не мой тезис был, я как раз и пытался человеку намекнуть на обратное

Да, да, я это в дополнение к мысли написал. Подбросил уголька. :)

Несколько только высказывание поправлу, что не «математики в программировании», а «знания математики для программиста (серьезного)». Программирование — это действительно не особо-то математическая область.

> Начинается все с определения требуемых ТТХ

Это делает организация-заказчик из только им ведомых соображений.

сбора статистики, определения основных геометрических параметров и т.д

Угу, перебрали изделия которые мы делали и выбрали наиболее близкое по требованиям. Это и есть точка отсчёта.

И далее идем от общего к частному, от всей конструкции к узлам,

от приблизительных параметров к более точным

Т.е. проектируем? Переделываем старое изделие с учётом новых требований?

Так, а что всё таки такое «расчёт самолёта в нулевом приближении»? Я подумал, что это какой-то специфичный термин, или профессиональный жаргон. Что вы имели в виду?

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

> Как Вы сможете написать софт не зная предметную область?

Буду общаться со специалистом в предметной области? А как вы обычно это делаете?

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

Саныч, а разве я против строгой типизации? ;)

Кстати, может. RTTI в яве или .net. Down-cast conversion :?>

> Это неверный подход. Ты должен знать ограничения модели,

лучше любого физика и математика

Хм, на основе какого опыта сделан такой вывод?

Иначе твою работу может выполнять любой школьник.

Мне известно, что «любой школьник» не может спроектировать и реализовать большую компьютерную систему даже если в ней совершенно нет никакой математики (а такие бывают). Что ты имеешь в виду?

>> Т.е. физики/математики составляю модели, программисты их реализуют в софте, а проектировщики используют софт.

Как Вы сможете написать софт не зная предметную область?

В коллектив разработчиков обычно входят специалисты-предметники.

> Несколько только высказывание поправлу, что не «математики в

программировании», а «знания математики для программиста (серьезного)».

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

Если предметная область содержит в себе много математики, то в ней, конечно, придётся разбираться, только редко когда эта математика имеет отношение к CS.

> Это делает организация-заказчик из только им ведомых соображений.

Какая разница, кто это делает? Это может быть и КБ, для СЛА очень характерно.

Угу, перебрали изделия которые мы делали и выбрали наиболее близкое по требованиям. Это и есть точка отсчёта.

Если убрать слово «мы» будет точно.

Т.е. проектируем? Переделываем старое изделие с учётом новых требований?

Нет. Мало того, что мы можем не иметь в своем портфолио аналога тому, что нужно построить, так этого аналога может вообще не быть. В авиации примеров много. Поэтому не стоит говорить «улучшили». Часто это «построили с нуля, опираясь на мировой опыт, либо используя все имеющиеся знания»

Так, а что всё таки такое «расчёт самолёта в нулевом приближении»? Я подумал, что это какой-то специфичный термин, или профессиональный жаргон. Что вы имели в виду?

Нет, Вы меня не перестаете удивлять... Не знать такого термина! Сразу видно, что человек не инженер, а «программист» :-D

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

> В коллектив разработчиков обычно входят специалисты-предметники.

То что я видел выглядело не так. Например, группа считает шасси. В группе нет никаких мальчиков-программистов, не имеющих понятия о предмете. Есть все те же инженеры, знающие, что и как считать. Они всем и занимаются. Так было еще лет 10 назад. Сейчас может и иначе.

То что я видел выглядело не так. Например, группа считает шасси. В группе нет никаких мальчиков-программистов, не имеющих понятия о предмете. Есть все те же инженеры, знающие, что и как считать. Они всем и занимаются. Так было еще лет 10 назад. Сейчас может и иначе.

Вы разницы между «считать шасси» и «писать софт для расчёта шасси» не замечаете?

> Вы разницы между «считать шасси» и «писать софт для расчёта шасси» не замечаете?

Знаете, что такое «писать софт для рассчета шасси»? Это по сути то что делалось раньше на бумаге. Только теперь результат обсчета можно повторить N-раз. Так что с этой стороны разницы нет. Плюс не забывайте про специальности / специализации типа САПР, АСУТП и д.р. Докатились, так дойдем до того, что есть программисты, пишущие софт, а есть инженеры-эникейщики, ничего кроме кликания в этом софте не умеющие :)))

> Какая разница, кто это делает?

Большая. Например наши ведущие космические предприятия НПО ПМ и Энергия предоставляют совершенны разные данные о радиационной обстановке на орбите. Поскольку это существенно влияет на характеристики изделия, то приходиться опираться на данные заказчика. Чем больше заказчик возьмёт на себя - тем лучше, потом, если вдруг «не взлетит», проще будет ответственность на него перекладывать. Вот Самарский «Прогресс» вообще своих данных по радиации не имел (в СССР они делали спутники-шпионы, которые летают так низко, что никакой радиации там нет). Так нам пришлось долго его убеждать, что это они должна дать данные по радиации, потому что брать на себя ответственность по этому вопросы мы категорически не хотели.

Если убрать слово «мы» будет точно.

Как это его убрать? Будто кто-то другой даст нам свои чертежи, данные испытаний и т.п., на которые мы сможем опереться, наивный.

Мало того, что мы можем не иметь в своем портфолио аналога тому,

что нужно построить

Можно пример подобного изделия? Это противоречит тому, что я знаю о проектировании подобных изделий.

Приближение главное (нулевое, иногда первое или, реже, низшее) —

описание (модель, концептуализация) изучаемого класса феноменов,

Т.е. конкретно термина «расчёт самолёта в нулевом приближении» нет? я такого реально не слышал. А на современном этапе разработка новых таких больших и дорогих изделий начинается с уже существующего прототипа. Проектироваться с нуля - это просто убиться сразу. Я знаю, что в истории авиации (во второй половине 20-ого века) были примеры проектирования с уровнем новизны примерно 50%, но обычно они все проваливались. Сделать самолёт очень сложно.

Сразу видно, что человек не инженер, а «программист»

В тот момент я был «физиком», в программисты я переквалифицировался позже. И да, программист это инженер.

> Знаете, что такое «писать софт для рассчета шасси»? Это по сути то

что делалось раньше на бумаге

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

Плюс не забывайте про специальности / специализации типа САПР,

Не забываем, я также занимался и САПР c GIS (в моей области это были смежные дисциплины). Что вы хотели рассказать про САПР?

есть программисты, пишущие софт, а есть инженеры-эникейщики,

ничего кроме кликания в этом софте не умеющие :)))

Как бы, уже давно так, и такие инженеры-эникейщики называются админы, которые совсем не те инженеры, которые разворачивают и настраивают системы, только у нас мало кто понимает эту разницу

>не нужно

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

Не проблема

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

Знаете, что такое «писать софт для рассчета шасси»? Это по сути то что делалось раньше на бумаге. Только теперь результат обсчета можно повторить N-раз.

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

Так что с этой стороны разницы нет. Плюс не забывайте про специальности / специализации типа САПР, АСУТП и д.р.

По своему опыту скажу, что САПРовцы одновременно и более слабые программисты, и не настоящие специализированные инженеры. АСУ ТП - это каких процессов, тепловых? :)

>> В коллектив разработчиков обычно входят специалисты-предметники.

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

Это не от времени зависит, а от задачи. Есть задачи, в которых «инженеров, знающих, что и как считать» маловато будет - нужен нехилый штат именно прогеров (разных специализаций). Правда, это не расчетные задачи.

> Большая. Например наши ведущие космические предприятия НПО ПМ и Энергия предоставляют совершенны разные данные о радиационной обстановке на орбите. Поскольку это существенно влияет на характеристики изделия, то приходиться опираться на данные заказчика. Чем больше заказчик возьмёт на себя - тем лучше, потом, если вдруг «не взлетит», проще будет ответственность на него перекладывать. Вот Самарский «Прогресс» вообще своих данных по радиации не имел (в СССР они делали спутники-шпионы, которые летают так низко, что никакой радиации там нет). Так нам пришлось долго его убеждать, что это они должна дать данные по радиации, потому что брать на себя ответственность по этому вопросы мы категорически не хотели.

Это все имеет отношение только к бизнес-части, управлению и т.д. Это не конструирование :)

Как это его убрать? Будто кто-то другой даст нам свои чертежи, данные испытаний и т.п., на которые мы сможем опереться, наивный.

Я зря про нулевое приближение писал? Какие чертежи? Эскизы + ТТХ, коих даже в советское время для техники вероятного противника было предостаточно. Впрочем, примеры копирования 1 в 1 тоже были, прямо по имеющемуся железу (например, самолет Douglas DC-3, ракета Sidewinder)

Можно пример подобного изделия? Это противоречит тому, что я знаю о проектировании подобных изделий.

Да Вы ничего и не знаете :) Примеров валом. Миг-25, SR-71, XB-70, B-2, F-117, F-22, YF-23, Ан-124/125 и многие другие.

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

Вы оканчивали авиационный? Я - да. Общеупотребимая терминология. Не только «нулевого», но и «первого», «второго» и т.д.

Проектироваться с нуля - это просто убиться сразу.

Выше я привел лишь несколько примеров, которые пошли в серию (YF-23, XB-70, Ан-124 / 225 не пошли только по причинам, не относящимся особо к самому конструированию)

И да, программист это инженер

Я специально программиста взял в кавычки. Намек должен быть понятен ;)

> АСУ ТП - это каких процессов, тепловых? :)

Ребятки, ну нельзя же так :))) http://ru.wikipedia.org/wiki/%D0%90%D0%A1%D0%A3_%D0%A2%D0%9F

> Да Вы ничего и не знаете :) Примеров валом.

Возможно. Я опираюсь на имеющийся у меня опыт и он как бы отрицает возможность «разработки с нуля». Хотя, возможно мы с вами по разному понимает данный термин.

Вы оканчивали авиационный?

Я физик (писал выше).

Общеупотребимая терминология.

Понятно. Просто раньше сталкиваться с ней не приходилось.

>В коллектив разработчиков обычно входят специалисты-предметники.

Это в каком-то идеальном мире. Чаще всего специалист-предметник и разработчик — это одно и то же лицо. Да даже если и разные, ну не может специалист-предметник дать информацию в таком виде, которую разработчик сможет сразу реализовать. Этап «разобраться во всем этом математическом бреде» все-равно у него случиться. Не сможет программист, не думая о последствиях, по тому, «как тут написано», реализовать сложные вещи. Даже пользоваться библиотеками численных методов не сможет, если не будет знать ограничений методов, не имея понятия о сходимости, например, и т. п. Ему придется вникать в каждый момент.

А если задача требует только элементы предметной области? мне вот нужно было разбираться с разными вариантами spatial trees. И что же мне теперь к предметнику идти? Хорошо, я приду к предметнику этому (какому?), а он мне «вот вам моя монография по этому вопросу». Ок, спасибо дядя! А там опять формулы и математика, с которой все-равно разбираться, чтобы реализовать что-то. Обычно же никакого предметника нет, а есть книжкии мозги.

Ребятки, ну нельзя же так :)))

Вот чёрт, а у нас предмет АСУ ТП был, и Т в нём обозначало «тепловых»... ;)

>> В коллектив разработчиков обычно входят специалисты-предметники.

Это в каком-то идеальном мире.

Я в этой реальности почти 10 лет живу :)

Чаще всего специалист-предметник и разработчик — это одно и то же лицо.

Бывает и так, насчет «чаще всего» - не знаю. Совмещение предметника и прогера в одном лице означает маленькую команду и небольшой проект.

Обычно же никакого предметника нет

Есть хоровое исполнение, есть сольное.

> мне вот нужно было разбираться с разными вариантами spatial trees

А зачем ты с ними разбирался? Я взял либу и юзаю, только на тесты посмотрел как юзать ;)

Правда, это не расчетные задачи.

А какие это задачи? Например расчет всяких турбулентностей газовой среды.

>> Правда, это не расчетные задачи.

А какие это задачи?

Сложные программно-аппаратные комплексы обработки сигналов :)

а на чем сейчас пишут DSP?

> а на чем сейчас пишут DSP?

Для программируемых процессоров - на ассемблере, аппаратные делают на VHDL.

>А зачем ты с ними разбирался? Я взял либу и юзаю, только на тесты посмотрел как юзать ;)

Либа-то есть, да. spacial-trees. Хочу заметить, что либы тоже кто-то писал. И представь, что такую либу надо написать тебе, что доброго дяди не нашлось. :)

Да вот мне был знаком только R-Tree, с которым мне довелось поработать, а узнать про остальные? Есть же другие разновидности R+, R*, X-деревья. Пока не узнаешь и не разберешься, то и применить осознанно не получится. А если либу захочешь усовершенствовать, то понимать, что там и как, надо. Ну, может быть, spacial trees — это не настолько уж наукоемкая тема, но я никогда слепо библиотеками не пользуюсь, а разбираюсь на предметном уровне, т. е. смотрю какие-то выводы основных свойств и пр. Зато потом могу точно сказать, что я это знаю. Другой пример — curves. Возьми человека программиста и скажи ему написать библиотеку пересечения кривых разного порядка. Придется влезать в теорию, как ни крути. А если программа требует какой-то апроксимации по точкам, а этих способов апроксимации тоже не один. Разбираться надо? Надо. На уровне математики.

Да сто лет уже как пишут на С, в VisualDSP.

> Хочу заметить, что либы тоже кто-то писал.

Ну, все пишут либы, только каждый своё. Во всем сам не разберёшься, надо и другим доверять. Я обычно стараюсь понять, что за человек автор, что он пишет в списке рассылки, смотрю его другие проекты и т.п. Если видно - что человек «хороший», то наверняка и либа будет приличной.

А если программа требует какой-то апроксимации по точкам,

а этих способов апроксимации тоже не один.

Ну да здесь всё просто: «хода нет, ходи с бубей», точне юзай кубический сплайны, они меня никогда не подводили :)

Разбираться надо? Надо. На уровне математики.

Это самая обычная математика, с которой можно разбираться по мере возникновения потребностей.

> Ну да здесь всё просто: «хода нет, ходи с бубей», точне юзай кубический сплайны, они меня никогда не подводили :)

Да, геометрическое моделирование явно не ваш конек.

> Да, геометрическое моделирование явно не ваш конек.

Какое ещё геометрические моделирование? Я по большей об аппроксимации экспериментальных данных.

> Какое ещё геометрические моделирование? Я по большей об аппроксимации экспериментальных данных.

Ну это оно и есть.

> Ну это оно и есть.

Хм, и что ты хочешь тогда сказать?

> Хм, и что ты хочешь тогда сказать?

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

>Ну да здесь всё просто: «хода нет, ходи с бубей», точне юзай кубический сплайны, они меня никогда не подводили :)

Как бы то ни было, для того, чтобы произнести словосочетание «кубический сплайн», надо про них знать. Не просто слышать, а знать, что это такое. Что лишний раз подтверждает необходимость знания теории. Не надо знать все, но надо уметь разбираться в том, что подкидывает жизнь. Для этого базовые знания нужны и знание, где и что почитать.

Если мне надо решить задачу, а кто-то говорит, чтобы я воспользовался методом Иванова-Петрова, то надо не библиотеку искать, а для начала брать теорию и разбираться. А то ли тебе посоветовали? А нет ли чего лучше? Никто за свои советы и слова не отвечает. Лично я боюсь программистов, которые программируют по типу «надо просто взять и заюзать либу, а разбираются в этом пусть яйцеголовые».

> аппроксимировать можно совсем по-разному

Это, скажем так, не новость.

Кубические сплайны - не самое лучшее решение

даже для большинства случаев.

А какое решение лучше для большинства случаев?

прям жалко прерывать общетеоретическую дискуссию... но я типа вчера обещал

#include <iostream>

class Stone{};
class Scissors{};
class Paper{};

template<class A, class B> struct FightData {};
template<class A, class B> struct Fight: public FightData<A,B>, public FightData<B,A> {};

template<> struct Fight<Stone, Stone> {
    typedef Stone Winner;
    static void say() { std::cout << "Good Stone wins.\n"; }
};
template<> struct Fight<Scissors, Scissors> {
    typedef Scissors Winner;
    static void say() { std::cout << "Good Scissors wins.\n"; }
};
template<> struct Fight<Paper, Paper> {
    typedef Paper Winner;
    static void say() { std::cout << "Good Paper wins.\n"; }
};
template<> struct FightData<Stone, Scissors> {
    typedef Stone Winner;
    static void say() { std::cout << "Stone, Scissors: Stone wins.\n"; }
};
template<> struct FightData<Scissors, Paper> {
    typedef Scissors Winner;
    static void say() { std::cout << "Scissors, Paper: Scissors wins.\n"; }
};
template<> struct FightData<Paper, Stone> {
    typedef Paper Winner;
    static void say() { std::cout << "Paper, Stone: Paper wins.\n"; }
};

/// ну нет у нас списков и reduce, приходится делать свои
template<class A, class B> class Cons {};
class EmptyList {};
template<class A, class B> Cons<A,B> operator >>= (A, B) { return Cons<A,B>(); }
template<class T> void my_reduce(T) {}
template<> void my_reduce(EmptyList) {}
template<class A> void my_reduce(Cons<A, EmptyList>) {}
template<class A, class B, class C> void my_reduce(Cons<A, Cons<B, C> >) {
    Fight<A, B>::say();
    my_reduce(Cons< typename Fight<A,B>::Winner, C>());
} /// полноценный reduce (вероятно с template template parameter) делать поленился

int main()
{
    my_reduce( Paper() >>= Stone() >>=  Stone() >>= Scissors() >>= Paper() >>= Stone() >>= EmptyList() );
    return 0;
}

философское замечание: с++ сильно похож на twm (кто с винды: на NT 3.5 ) — почти все есть, но полировки сильно не хватает

нужна ресинтаксификация при сохранении почти всей семантики

> но я типа вчера обещал

Хм, я бы списки типов из boost взял, но всё равно: Прикольно! Но только это же статика. Тут известны все типы во время компиляции. Мог ведь просто сослаться на довольно известную реализацию интерпретатора Lisp на шаблонах, работающую во время компиляции (ссылку, увы, потерял), что бы продемонстрировать, что шаблоны всесильны! Шаблоны в C++ и правда образую Тьюринг-полный язык, но это статика...

Потом, далеко не каждый C++-разработчик понимает частичную специализацию и концепцию списков типов, так что у многих могут быть проблемы с пониманием этого кода. А defgeneric/defmethod в CL это чистая динамика и очень просто.

> интерпретатора Lisp на шаблонах, работающую во время компиляции (ссылку, увы, потерял)

http://www.intelib.org/intro.html

> о я типа вчера обещал

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

вообще спасибо, на C++ _можно_ извращаться. :-)

> что бы продемонстрировать, что шаблоны всесильны! Шаблоны в C++ и правда образую Тьюринг-полный язык, но это статика...

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

а почему — попробуй догадаться, ну или вспомни — я об этом давно писал

> Но читабельность, для непосвященых, страдает по сравнению с CL.

ты что ли непосвященный?

> Потом, далеко не каждый C++-разработчик понимает частичную специализацию

они могут заняться заправкой картриджей или например начать писать на языках с динамической типизацией

Кстати, а что мешает эксперементировать в haskell? Поменял определение, скомпилил только _нужный_ модуль, а все остальные просто не будут затронуты, и проверка типов на них не зависнет. Ну а если надо проверять взаимодействие, то тут уже обязательно прийдется править, хотя в динамических языках вы просто словите исключение, так что в этом плане они вполне равны.

>с++ сильно

это не c++.

> это не c++

g++ --pedantic c тобой не согласен