kika | The bad, the good and the Haskell

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

ifp5 пишет:
Реально проблема есть только одна единственная (и она та же самая что препятствует использованию OCaml, Haskell, LISP и пр) - что решение выбора языка принимают люди (такие бывают толстые и важные начальники), которые уже решили, что проект будет на жабе. Никаких других проблем в использовании шарпа (или хаскеля) нет.

Ну это на самом деле далеко не так. Это черезвычайно распространенное мнение, которое на самом деле базируется на такой красивой гиковской картине мира, в которой есть good programmers and evil managers. И все плохое проистекает из менеджеров, а все хорошее пишется умными программистами, которые вникают в проблему с полувзгляда и выбирают идеальный инструмент.
Попробуйте написать полезную программу на лиспе и продать ее пользователям (продать в широком, хорошем, смысле - пусть даже и забесплатно). Чтобы она была как программа на С++/Win32 или там на сишарпе/дотнете. Чтобы у нее был гуй, какой модно в этом сезоне (совершенно необязательно, кстати, чтобы он был один в один стянут с последнего оффиса), чтобы у нее был нетворкинг, чтобы она работала с трехмерной графикой под DX9/10 и использовала многоядерные процессоры. По-моему я описал гамез, сам того не желая, ну да ладно. Пусть это будет не гамез, а САПР.

Ровно та же самая проблема у всех на свете "скриптовых языков, лучших чем Перл". Они все безусловно лучше чем Перл (трудно быть хуже с точки зрения среднего программиста), но у перла есть CPAN. End of story here.

P.S. Всех, кто напишет что у Автокада в пузе как раз лисп - сразу забаню. Настолько short minded тут не нужны :-)

Flat | Top-Level Comments Only

From:

grundik.livejournal.com

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

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

Отсюда следует, что проблема в постановке задачи, а не в инженерах. То есть проблема есть при коммуникациях гуманитариев и инженеров.

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

Соответственно, сам себе я задачу поставить не могу 100%-но правильно, я могу только поговорить, посмотреть и произвести прочие ИНЖЕНЕРНЫЕ замеры/исследования, и затем решить ту задачу, которую Я СМОГ ПОНЯТЬ из общения с заказчиками.

PS: категорически не согласен с тем, что программирование не является инженерной дисциплиной. Не инженерного в программировании ровно одна вещь - написание ТЗ на основании желаний заказчика. Как только с задачей всё ясно - тут уже чистое ремесло пошло, никакого творчества.

From:

kika.livejournal.com

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

Ну и насчет постановки задачи. Я вам сейчас начну перечислять поставленные задачи и вам придется этот фонтан руками затыкать. Ну например, ээээ..., задача манипуляции трехмерными моделями на экране. Ни парадигмы удобной нет, ни манипулятора. Все трехмерные пакеты делают это немного по-своему и ни один не делает это интуитивно понятно.
Задача попроще - например мы с вами два джона смита, сидим в чате и неожиданно выясняется что у меня есть редкий дивиди, который вы ищете уже 5 лет. У нас с вами современный быстрый кабель/адсл, и технически процесс передачи 4 с грошами гигабайт займет единицы часов в худшем случае. Наши с вами действия?
Задача посложнее: мы специалисты по спецэффектам и работаем над фильмом, сидим в разных городах. Фильм даже в разрешении 2К занимает порядка 3-4Тбайт в рабочей копии. Бабла у нас - лопатой греби, поэтому у каждого 100мбит стекла в офисе. Никаких проблем купить готовое решение для эффективной передачи информации в обе стороны, чтобы у обоих всегда была синхронизированная копия фильма. Наши действия? Я особо подчеркиваю - это рынок на котором денег фактически unlimited. Бюджеты современных блокбастеров позволяют оплачивать даже прокладку _выделенных_ оптоволоконных линий из LA в Чикаго, скажем.

From:

grundik.livejournal.com

> Формальную верификацию мостов и небоскребов освоили уже достаточно давно

и они всё равно при этом падают...

Насколько я знаю, ядро qnx верифицировано формально.

Формальная верификация возможна, когда есть формальные требования, то есть формальное ТЗ. Формального ТЗ почти нигде нет. z-notation никто не использует. RUP также нифига не даёт (да и не используют и RUP тоже).

> Я вам сейчас начну перечислять поставленные задачи и вам придется этот фонтан
> руками затыкать. Ну например, ээээ...,
> задача манипуляции трехмерными моделями на экране.

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

Вообще я когда-то давно (году в 98) занимался трёхмерщиной в 3DSr4, и там мне было удобно с четырмя экранами, три из которых - проекции, один - изометрия. dummy также не сильно-то и неудобны. Сейчас вроде как такой layout тоже делается нормально.

Про Джонов Смитов - ну это же просто. Ты вставляешь свой DVD в свой iMac, тянешь с рабочего стола иконку примаунченного DVD в окно чата, DVD передаётся мне на рабочий стол, я кликаю по нему два раза и смотрю. Что здесь сложного? То, что у тебя винда, где такого в ближайшее время не будет?

Про фильмы не понял соли. Надо, чтобы над одним кадром в единицу времени могли работать два человека одновременно, и при этом чтобы они видели действия каждого?

From:

kika.livejournal.com

Расскажите про упавший небоскреб.

Формальная верификация возможна, когда есть формальные требования, то есть формальное ТЗ. Формального ТЗ почти нигде нет. z-notation никто не использует. RUP также нифига не даёт (да и не используют и RUP тоже).

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

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

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

Вообще я когда-то давно (году в 98) занимался трёхмерщиной в 3DSr4, и там мне было удобно с четырмя экранами, три из которых - проекции, один - изометрия. dummy также не сильно-то и неудобны. Сейчас вроде как такой layout тоже делается нормально.

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

Про Джонов Смитов - ну это же просто. Ты вставляешь свой DVD в свой iMac, тянешь с рабочего стола иконку примаунченного DVD в окно чата, DVD передаётся мне на рабочий стол, я кликаю по нему два раза и смотрю. Что здесь сложного? То, что у тебя винда, где такого в ближайшее время не будет?

И что, Стиви настолько храбр, что встроил в операционную систему DeCSS? Я не верю, извините. Если бы он это сделал, то до сих пор бы ходил согнувшись и при слове MPAA падал бы на землю и начинал вопить.
Ну и кроме того, будет ли это работать если оба джона смита за симметричными натами? И если да, то как и почему? И не требует ли это подписки на .mac, после использования которого в целях копирования дивиди согнувшись уже будут ходить оба джона смита?

Надо чтобы над фильмом работали два человека, не обязательно над кадром. Но множество кадров, которое сейчас в работе "с другой стороны" хотелось бы как-то отличать. Но это опционально, достаточно просто копий с обоих сторон. Я забыл сказать что для того чтобы просматривать кино в разрешении 2К нужна полоса в 250мегабайт в секунду минимум, а с учетом рапидов - порядка 700-800.

From:

grundik.livejournal.com

> Расскажите про упавший небоскреб.

11 сентября.

> Перетаскивание двумерных объектов мышкой, например, вполне интуитивно понятно.
> В той степени, что это способен освоить ребенок до пяти лет за единицы минут.

А взрослая женщина сорока лет - неспособна, если до этого ей никто никогда такого не рассказывал. Да и насчёт ребёнка есть сомнения - по крайней мере ребёнок четырёх лет не смог понять в рисователе картинок, что кисть можно макать в краску (куда уж метафора понятнее), меняя таким образом цвет кисти (да, у меня планшет, что даже более интуитивно, чем мышка). Это всё примеры, которые я видел своими глазами (с женщинами сорока+ лет - неоднократно). Раскин даже вроде как пытается объяснить, почему так, мне показалось довольно разумным.

Про храбрость Стиви я не знаю, тут поинт в том, что если DVD передавать запрещено законодательно, то инженеры тут не при чём. Про наты - ну чатятся же они как-то? ;)

Про фильмы мне сказать нечего - тут видимо просто так не решить, надо думать. В Adobe Premier превью генерится в плохом качестве, видимо в этом направлении и придётся думать. Также можно передавать не сам кадр, а описание манипуляций над ним - это видимо технически возможно.

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

From:

kika.livejournal.com

11-го сентября небоскреб не упал. Его уронили. Для инженера странно не понимать разницы.

А про четкость пожалуйста: ТЗ на мосты и небоскребы пишут тоже инженеры. А гуманитарии только говорят "хочу чтоб в Москве половина населения жила за чертой бедности, но зато был бы самый высокий небоскреб!" И шепотом "и чтоб моя жена продавала на это строительство цемент". Как вы понимаете, к ТЗ это не имеет никакого отношения.

From:

grundik.livejournal.com

> 11-го сентября небоскреб не упал. Его уронили. Для инженера странно не понимать разницы.

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

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

Ну и строительство подревнее программирования будет как-никак :)

From:

kika.livejournal.com

Воот. Утрируя - программы точно также работают, потому что когда они не работают - "их уронили".

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

ТЗ пишутся именно инженерами, доросшими до постановщиков задач. Критерий дорастания - это способность понимать гуманитариев.

Ну и строительство подревнее программирования будет как-никак :)

Апчом и речь. Не доросло еще программирование до инженерной дисциплины. Базиса нет, одна надстройка, да и та в основном из пенопласта.

From:

grundik.livejournal.com

> Когда программа не работает - это значит что у инженера, ее писавшего, руки кривые.

Не всегда. Если бинарник из линукса не работает под виндой - то инженер тут не при чём, а кривые руки у того, что ожидал, что винда является нормальным условием для работы бинарника, скомпилированного для линукса. В строительстве с environment всё гораздо определённее (да и в СНиПах дохрена чего прописано уже).