Podcast 9 - Выпуск N15

Дешевое и некачественное железо плохо! Новые интерфейсы это хорошо!

Слушал я подкаст 9 наскоками. Сначала первых выпусков пять за раз, ну и за последнюю неделю оставшиеся.

Уж очень вы хвалили ИЕ 8. До прослушивания подкастов я использовал хром, а там где он не работал, а я встречал ТОЛЬКО сайты так или иначе связанные с майкрософтом, юзал фф. Были коментаоры, несолидарны с вами в мнении, что ИЕ8 производителен как ничто, но вы здраво, мысляще отбивали такие нападения. Собсно, я и сам не люблю предвзятых отношений, мол все версии ИЕ - га%но.

Ну это все лирика. Решился я заменить фф, на ие в своем повседневном использовании.  Прошла неделя, возвращаюсь на фф. Да, конкретный урл я вам не дам, мол вот на этом сайте ие работает медленно, но имея параллельно запущенный хром и ие с дофига окнами, в конце рабочего дня хром все так же летает, а ие педалит жестко. Скролит рывками, таб открыть с контентом - так вооще молчу (да, в режиме с выключенными плагинами). Общее впечатление, ну медленней хрома в разы, не на 50%, а именно в разы.

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

Полный игнор хрома майкрософтом даже коментировать не хочется.

П.С. если захотите прокоментировать в духе: "фигня, где цифры или урл? Ах нету, ну тогда мы создали акселераторы и это производительно", то лучше не надо. И так уже смешно.

Здравствуйте. С большим интересом прослушал пять подкастов, на днях планирую прослушать остальные и после этого уже "оперативно" следить за новыми. У меня такой вопрос, возможно у вас получится ответить на него в 16-ом или 17-ом выпуске.

Сейчас есть некоторая активизация среди разработчиков по поводу функциональных языков программирования. Вот и в MS Visual Studio 2010 войдет F#. Эта тема меня заинтересовала и я попробовал разобраться. Оказывается, пользы от функционального программирования нет вообще. Разве что не совсем опытных программистов это может заинтересовать, из-за относительно низкого порога вхождения в функциональное программирование. Я обосновал свое мнение в своем блоге и уже участвовал в нескольких, подчас весьма жарких дискуссиях, в Интернете, по этому поводу. Свое мнение мне удалось отстоять, многих, возможно, убедить.

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

Можете вы посмотреть мое мнение по этому поводу, показать (перевести его на английский) для ваших ведущих архитекторов и рассказать в подкасте?

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

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

Если вам удобно - то может быть вы спросите по приватной переписке у ваших специалистов, и когда они пришлют мнения - обобщите (например компании Microsoft так просто удобнее, по каким-то соображениям)? Можно и с явным "обозначением" - какой именно специалист у вас - сказал такое-то мнение (очень желательно бы узнать и его должность - на сколько прислушиваться или нет к его мнению), и как он его обосновал.

Спасибо. Обещаю со временем еще придумать интересные вопросы для ваших обсуждений.

P.S. Да, а вот две части моей статьи по этому поводу - Часть 1 и Часть 2.

Video to ne sobiraetes' zovodit' ?

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

Здравствуйте. Вы тут рассказывали про Snipping Tool - я согласен, что это замечательная утилита. Она даже позволяет выделять или отмечать интересующие фрагменты картинки с помошью "карандаша".

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

P.S. Если не хватает ресурсов у Microsoft, я бы с удовольствием безвозмездно помог с написанием этой маленькой, но очень полезной фичи.

С уважением,

Николай Денисюк

Team Leader команды разработчиков

Materialise Dental Ukraine

Здравствуйте. Спасибо за комментарий.

По поводу параллельного программирования - в Викизнания вчера внес описание своей архитектуры Parallel-Ax (BSD Public Documentation License), там как раз рассказывается в чем плюсы, в этом плане, функционального программирования. За счет того, что нет переменных, сохраняющих состояние. Таким путем если пойти, что "урезанность" ФП позволяет это делать, так можно отказаться от компьютеров - тогда тоже не будет никаких проблем с параллельным программированием. Урезать так (помимо классов, оставляя только функции-методы) - давайте идти дальше, зачем останавливаться!
 Лично я придумал способ - как без урезания функциональности языка - распараллеливать и не иметь никаких проблем.

Про объектную ориентированность (CLOS  - Common Lisp Object System). Я конечно не знаю всего-всего на свете, и, например, этого, но в попытке угадать - речь может идти про использование указателей на саму функцию, и такой шаблон проектирования  как Functor (это не GoF, в GoF есть паттерн проектирования Command, - именно эти два шаблона часто отождествляют вместе).

Другими словами - это всего лишь имтиация объектов. В "обычном" объекте есть:

1) Переменные (данные).
2) Методы манипулирования (изменения) этих данных.

- если в ФП ввести такие полноценные объекты, с переменными в них, и методами - то это уже не будет ФП, да и с "многопоточностью" сразу все обрубится. Нет, ну правда же?

Тогда вывод - в ФП не может быть полноценных объектов. А все имитации - это имитации и есть. И, следом не менее главное следствие - нет объектов, значит нет ООП. Значит можно использовать только процедурный подход. Или, второй подход - вообще отказаться от каких-либо подпрограмм, программировать "постоянным присваиванием", не использовать многократно код.

И какие бы не приводили абревиатуры из мира ФП и его библиотек - мы упираемся в фундаментальные принципы.

Еще одна альтернатива - в одном языке программирования - совмещать и ФП, и императивное. Но зачем хвостовые рекурсии в императивном программировании? Когда есть ООП, и его ВПОЛНЕ хватает.

Про Ассемблер я упомянул, потому что для него очень характерны операции присваивания, чуть ли не половина программы может состоять из операций присваивания. Такое характереное "свойство" программирования на Ассемблере - я и привел, выделил. Потому что у ФП есть всего две возможности - или программировать в процедурном стиле, или программировать в основном операциями присваиваниями. ООП там может быть только в небольшом виде имитировано.

> Проблема ФП в том, что для его эффективного освоения требуется значительные усилия и развитое абстрактное мышление.

- Как бы немного и нет. Для ООП тоже аналогичное требуется. Разница здесь только в том, что ФП - это чаще всего "write once", а ООП - позволяет создавать отличные фреймворки. Которые очень отличаются от библиотек, написанных в процедурном стиле.

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

Как же нет? Идет "поток выполнение", в котором постоянно идут операции присваивания, а чтобы использовать циклы - используют хвостовую рекурсию.

У меня просто многолетний опыт программирования на ActionScript 1, в котором практически все программировали в процедурном стиле (классы там нужно было регистрировать, в общем мало удобно). И мы, флеш-программисты - активно использовали тогда рекурсии и прочее. Отличие только в том, ActionScript 1 - что там многомерность программирования - давало размещение кода в совершенно разных местах (в таймлайнах кнопок, клипов, на разных уровнях) - в этом программирование на нем было немного в плюсе, в отличии от чисто функциональных языков программирования.
Но потом появился ActionScript 2, где уже были нормальные классы и интерфейсы (с маленькими нюансами) - и программировать уже можно было "чисто" в Java-стиле. И использовать ООП.
 Сейчас Actioncript 1 - мертвая версия языка, в вакансиях пишут про знания 2-ой и 3-ей версии.
 Я не хочу дискутировать на счет флеша, лично мне SL 3 более симпатичне, но все это - была история, как все развивалось в этом языке программирования.

И за последние несколько лет, когда я уже программирую JEE - я ни разу, кажется, не использовал рекурсию, и никто из тех моих колег, код у которых я видел. - О чем это говорит? - Что хвостовые рекурсии - здесь уже не нужны. Они - именно, именно - для замены обычных циклов в ФП.

2 mykolad для этого там есть стирашка Она стирает как раз надписи, что ты сделал. Так что ничего писать не нужно

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

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

Адодин Дима

MSP НГУ

Здравствуйте.

> и не понимаю, в чем "урезанность" ФП

Если из класса удалить все его внутренние переменные (к слову - сохраняющие состояние объекта данного класса) и оставить только методы этого класса, после этого удалить сам класс и оставить одни "голые" методы его (в которых могут содержаться локальные переменные, имеющие жизненный цикл от начала вхождения потока выполнения в такую функцию - до выхода потока из такой функции) - то, по моему, это и есть существенное урезание всей конструкции. Поэтому я даже сравниваю этого как урезание 3D до 2D.

Если к этому 2D добавить переменные глобальной области видимости, добавим различные обходные-эмулирующие пути замены объектов - получается ФП, по моему.

Математика... Читал, неделю-две назад, что там вроде уже все "освоено"... чуть ли не "стопорение" в развитии... Может я не совсем "то" прочел, может есть и другие точки зрения, как бы то ни было - вспоминается один фантастический рассказ, когда из глубин Космоса выныривает нечто, проглатывает космический спутник с адмиралами всего флота, на борту его, и исчезает в неизвестном направлении (по моему произведение написал Г. Гаррисон, один из рассказов про "Стальную крысу").

Один из героев "замечает" на счет этого "проглатывания" (спутника, с адмиралами на его борту) -- Думаете, кто-нибудь будет по ним горевать? - Как бы не так, их места с радостью займут их заместители...

Так может произойти и в математике - как только станет "понятно", что методы расчета функциями - это всего-лишь частный случай из "3D"-расчетов - мигом появятся 20-50 математиков, которые придумают новые теории расчетов. Так как некоторые одаренные люди занимают руководящие посты в программировании, в математике - уже в 16 лет, вероятность, прогноз такого развития событий - может "иметь место быть".

Другой пример. Языки программирования сначала учат на уровне функций (2D), и даже не функций, а, пишут что-то вроде - "у нас есть метод main(), более подробно мы коснемся его позже" и показывают какие-то базовые конструкции языка, его синтаксиса, на уровне "присваивания", например int a = 3 +5; - т.е. в начале учат "на уровне 1D".

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

В этом нет "ничего такого".

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

Возможно, возможно (!) - математика вовсе не застыла на месте, как говорят о ней кто-то там... посмотрим...

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

А на счет "урезанности", как вы ее подразумеваете, то присмотритесь к F# повнимательнее, это полноценный .Net язык, что подразумевает под собой то, что там можно создавать .Net классы. Правдо для эффиктивного использования такого подхода надо четко осозновать все плюсы и минусы каждого из подходов, и уметь их грамотно сочетать.

Кстати по поводу математики, как житель Новосибирского Академгородка, могу с уверенностью заявить: "математика растет и развивается"

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

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

> А на счет "урезанности", как вы ее подразумеваете, то присмотритесь к F# повнимательнее, это полноценный .Net язык, что подразумевает под собой то, что там можно создавать .Net классы.

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

> Кстати по поводу математики, как житель Новосибирского Академгородка, могу с уверенностью заявить: "математика растет и развивается"

Очень интересует вопрос на счет... вот что мне как программисту, разработчику (в том числе и, например, 3D-игр) - стоит изучить в математических дисциплинах в первую очередь, и что, допустим, во вторую (другими словами - что тоже не было бы лишним). - Т.е. если кто сможет ответить, то желательно бы разделить, на 2, по первоочередности, части.

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

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

>Порядок тут точно верный?

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

>Очень интересует вопрос на счет... вот что мне как программисту, разработчику (в том числе и, например, 3D-игр) - стоит изучить в математических дисциплинах в первую очередь

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

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

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

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

> Порядок тут точно верный, сначала пишется ТЗ на Человеко графическом языке, а перед этим сторятся всякие ч\я и так далее. Идет оценка задачи.И один из этапов, это выбор платформы, языка, и команды разработчиков(если у компании их насколько).

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

> Вот тут мне достаточно трудно ответить. 1. Я не знаю чем занимаетесь вы

Программирование + (именно плюс к этому, дополнительно) меня интересует все в математическичх дисциплинах, что пригодится для 3D-игр.

> В вашем наравлении матиматика ищен например новые алгоритмы расчета коллизий

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

> Если вы пишите на готовом движке (а скорее всего вы так и делаете), то и знать вам больше нечего.

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

>Спасибо, это уже скорее применение математики

А как вы себе представляете развитее математики? Ищется задача которая не решена, либо оно по каким-то соображениям не эффиктивно, может быть вообще неизвестно а существует ли оно. Ищутся похожие задачи, они объеденяются в один класс задач. И для них ищется решение, проверяется его существование и единственность. Сначала ищется какое-нибудь частное решение, затем его пытаются обобщить. Вот в этом процессе и рождаются новые теоремы, новые определения, новые области знаний. Простой пример Теория вероятности, она вся вышла из азартных игр, математики хотели составить модель наиболее выгодного способа игры, а теперь это целый раздел математики. Четкую иерархию из разделов математики создать едвали можно. Матанализ например существует везде где есть функции. Наиболее близкими к информатике являются вычислительная математика, линейная алгебра и аналитическая геометрия(посуте все 3D стоит на них), теория графов, теория управления, теория операций и многое другое.  А что касается дискретной математики, то это всего лишь название предмета, научным направлением она не является. Под этим названием подают различные части(дискретные) математики. Тут теорию множеств, там теорию графов, здесь еще и булевы функции. Вобщем все, что не наскреблось на отдельный курс. Поэтому сказать четко, что надо изучать сначала это, а потом то нельзя. Но, как я сказал матан пригодиться везде, да и линейка в придачу.

Спасибо за подробный ответ.

Все же, как мне кажется, структурировать информацию тем или иным способом можно. Возможно рассматривая все - в каком-то "срезе", контексте применения/использования.

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

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

Давайте возьмем другой пример - как лучше всего изучать C#. На сколько я понимаю - хорошо если знаешь при этом С++ (и "исошный", и CLI). Идем еще "глубже" - чтобы хорошо знать С++ - хорошо если еще знаешь Ассемблер.

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

А вот с математикой у меня нет понимания такой же структуры.