«Динамический и статический анализ это просто две разных методологии, которые дополняют друг друга.» — согласен только с этим, всё остальное — бла-бла-бла. Действительно, статический анализ кода, если уж он введён в процесс разработки, должен выполняться регулярно, как прогон тестов и т.д. Но ценность его работы уменьшается экспоненциально в зависимости от кол-ва итераций разработки и квалификации разработчиков.
Сам по-себе анализ программистских багов мало полезен, нужна цельная система анализа кода, система для выделения целых кусков кода, и не только «ошибочных», а, например, кандидатов на рефакторинг, кандидатов для реализации в виде стандартных паттерн проектирования и т.д. А пока, статистический анализатор, полезен, только при разгребании унаследованного кода.
Не знаю почему минусуют. Но как раз в эрланге основной принцип: «не можешь сделать — умри» плюс гибкая система супервизоров и апгрейда на лету и есть более надёжная альтернатива «распространению ошибок» по-всему приложению. Вообще эрланг это скорее язык управления, а не вычислений. К сожалению в С/С++ такое применимо только в специфических приложениях.
К расширению для хрома есть пожелания:
1. Автодополнение/запоминание поисковых фраз
2. Открывать новую вкладку при поиске только если текущая не тортилла (можно включать/выключать в опшинс)
Хотел приобщиться к прекрасному, но VMware Player сказал: «Failed to open virtual machine: Failed to query source for information.» при загрузке sage-4.7.1.ova файла.
"...«ising prior» (к сожалению, русский эквивалент установить не удалось — кто знает, подскажите)..." — это априорная вероятность Изинга. В честь Эрнста Изинга, поэтому писать нужно с заглавной буквы. Есть ещё априорная вероятность Джеффри, например.
Вы больны дислексией. Я дал отзыв о статье, а не о теории категорий. С теорией категорий я знаком и, более того, использую в своих проектах. А такие умники как Вы учат наизусть талмуды не потрудившись их понять, по одной простой причине: страсть к моде и попугайству заложены с детства. Общаться далее не наумерен: убогим — убогово.
С полнотой согласен, только в случае ошибок в темплейтных конструкциях (стл, буст, локи) вы получаете список наведённых ошибок, а это уже не камильфо. Одно дело когда чёрным по белому написано — ошибка в такой-то строке вашего файла, а далее, опционально, прицеплены все последствия этой ошибки и совсем другое — лоскут неудобочитаемого текста в котором ты сам должен найти первопричину. STLfilt это хорошо, но он работает только для стл-ошибок, а если я использую буст.мпл или ещё страшнее — буст.прото тогда как? И самое главное, что эту ситуацию кардинально никак не исправить не вмешиваясь в стандарт языка (концепции и были призваны это сделать).
Ну-ну. ждём полной автоматизации — автораспознование лиц — автосуд — автоприговор — автосрок (10 лет строго режима) — автозак — автотруд на свежем воздухе — автооправдание через три года из-за ошибки в ПО (внимательно нужно читать еулу) — автокассация — автоосвобождение. Об этом мире я не перестаю мечтать.
И что? А изложено так будто только что разобрались и решили поделиться этим знанием с окружающими. Я ещё раз подчёркиваю, что Вы написали не понятно что — это не научный доклад, и не научно-популярная статья, и даже не ознакомительный материал — на пальцах. Простите, но теория ради теории ценна только для теоритиков, для практиков ценно применение. Я понимаю гугль, мэп-редьюс и всё такое, но это готовое решение и им успешно пользуются люди даже не подозревая о наличии монад. От статьи, лично я, ожидал следующего: В разработке ПО часто встречается следующая задача — далее формулировка, для её решения в относительно общем виде мы применим теорию категорий — объяснение — как, с попутным изложением материала из теории категорий с привязкой к конкретной задаче. Вы же предпочли запостить ссылку на опыт знакомства с теорией категорий.
На мой взгляд этой статьей Вы ещё больше всё запутали, нет с точки зрения математики и теории категорий всё верно. А вот с точки зрения прагматики и конкретно разработки ПО нет ничего. Какие задачи в разработке ПО позволяет решать теория категория вообще и монады в частности? Какие аналогии между категориями(монадами) и конкретными программистскими решениями просматриваются? Как мне, проектировщику ПО, эти категории(монады) помогут в моей работе?
С точки зрения математики всё ясно — это ещё один уровень абстракции позволяющий оперировать объектами разной математической природы с помощью единого матаппарата. С точки зрения утилитарной непонятно ничего. Придать концептуальную чистоту хаскелю — это локальная проблема адептов и авторов хаскеля — к индустрии производства и разработки ПО это отношения не имеет. Вот Вы упомянули мэп-редьюс и все как-то оживились, правильно, — все знают, что мэп-редьюс это реальная технология, которую можно пощупать и, более того, использовать в своих решениях — значит есть смысл разбираться. Никто, из действующих разработчиков, не будет изучать технологию, я уж не говорю о её теоретических основах, если не будет знать конкретно — какое множество задач можно с её помощью решать. Это не из снобизма, или тупости — инженерам-разработчикам слишком много нужно держать в голове, и порой это знания эмпирические и эвристические, которые невозможно вывести логическим путём из теории, а только запомнить и научиться применять на интуитивном уровне. Просто нет ни времени, ни ресурсов на усвоение чисто-теоретических знаний. Вот если Вы в начале статьи дадите перечень практических возможностей и круг решаемых задач, тогда для читателя не будут страшны ни Ваши стрелочки, ни эндоморфизмы, ни прочие математические кунштюки.
И при этом, Вы не обижайтесь, изложено всё очень сумбурно — такое ощущение, что Вы сами недавно разобрались с этим предметом и решили представить свои умозаключения в публичном виде. Это похвально, но Вы указали лишь реперные точки своих умозаключений, опустив рассуждения и это делает изложение ещё более запутанным, чем если бы это было описано чисто математическим языком. К сожалению это не только Ваша беда, таким подходам грешат практически все «переводы» академических работ, выкладываемых, якобы для научно-популярного обозрения — ни рыба — ни мясо. Для научной статьи слишком фривольно, для научно-популярной — слишком не понятно — и не понятно — зачем? — В чём практическая польза от использования теории категорий в повседневной жизни, в данном случае, разработчика ПО.
Добро пожаловать в реальный мир. Или Вы думаете, что на рынок придёт компания-изобретатель и все участники рынка удивятся, попеняют себе, и потупив очи уйдут с рынка? Да ничего подобного, более того — они даже не будут конкурировать с ней в профессиональном плане — они её либо купят, либо закроют, либо милостиво выделят кусок пирога, если будет послушной. И так будет до тех пор пока основным критерием успешности компании будет прибыль. Именно о ней родной, кстати, эффективные менеджеры трещат на хабре, да и не только, не переставая.
Вот-вот. А то опять началась это бесконечная хаброболтовня о богомерзких патентах. Гугль «выбился в люди» и всё что ему нужно было сделать это следовать своему дао, которое ему разрешили иметь старшие товарищи. Гугль начал совать свой нос в уже поделенный рынок и сейчас у него одна надежда, что ему позволят иметь поисковик и интернет-причиндалы, а то ведь у майкрософт есть бинго.
Что касается патентов, то в ближайшее время их не отменят, потому что это ещё один финансовый пузырь на рынке в котором сосредоточена большая часть капитализации хайтек-компаний.
Что касается изобретений и инноваций в гугле, майкрософте, айбиэм или оракл, то это вздор — эти компании уже давно ничего не изобретают сами, они лишь покупают изобретённое мелкими компаниями, да финансируют рынок венчурного капитала, который кстати тоже пузырь не хилый с его то непредсказуемостью.
Ну наверное не «был», а «считал себя» профессиональным С++ программистом — это разные вещи, поясняю на всякий случай — вдруг вы «были» ещё и «профессиональным логиком».
"… Скучно стало в академ кругах, и ай да еще:
Тут тебе и rvalue-ссылки &&, и constexpr, и шаблоны с переменным количеством параметров. Без этого ж не кодилось.
…
Зачем так усложнять. Зачем все эти шаблоны шаблонов. Перегруженные шаблонные операторы приведения типа..." — Понятно, что Вам не нужно, всё, что относится к мета-программированию, а для меня, например, использования буст.прото и разработка своего эмбеддед DSL для задачи — это, то с чего я начинаю работу над проектом или его частью. Видимо, те проекты, которые разрабатываете Вы уместнее было бы делать на джаве или си-шарпе — безо всякого сарказма. Если Вы затрудняетесь расстановкой спецификаторов и модификаторов, то нужно использовать код-сниппеты, которые генерят шаблонные декларации и имплементации методов и классов или использовать какую-нибудь UML — систему проектирования.
Вот-вот. У меня, лично, да и у всех моих прошлых и нынешних работодателей, не возникает вопроса: «кто я»? Потому что в дипломе, полученном честным путём во времена СССР, чёрным по белому написано: специальность: Инженер-системотехник (Вычислительные машины, комплексы, системы и сети). Собственно этим инженером я двадцать лет и работаю. И если кому-то кажется, что он садовник, то может быть он неверно выбрал специальность. А хабр-такой хабр, здесь таких садовников как г… за баней, это точно.
В С++0х не вкдючили и более серъёзные вещи, например, концепции за которые ратовал сам Страуструп и просил их включить хотя бы как опшионал. Не включили модули, хотя всем очевидно, что это как раз то, чего не хватает с и с++, и вот это как раз нисколько с/с++ не испортило бы. Первое сильно продвинуло бы вперёд метапрограммирование и параметрический полиморфизм вместо стандартной модели наследования и ад-хок полиморфизма, а второе позволило бы навести порядок с единицами трансляции и заголовочными файлами.
Сам по-себе анализ программистских багов мало полезен, нужна цельная система анализа кода, система для выделения целых кусков кода, и не только «ошибочных», а, например, кандидатов на рефакторинг, кандидатов для реализации в виде стандартных паттерн проектирования и т.д. А пока, статистический анализатор, полезен, только при разгребании унаследованного кода.
1. Автодополнение/запоминание поисковых фраз
2. Открывать новую вкладку при поиске только если текущая не тортилла (можно включать/выключать в опшинс)
bartoszmilewski.wordpress.com/2011/01/09/monads-for-the-curious-programmer-part-1/
bartoszmilewski.wordpress.com/2011/03/14/monads-for-the-curious-programmer-part-2/
bartoszmilewski.wordpress.com/2011/03/17/monads-for-the-curious-programmer-part-3/
но, на мой взгляд, очень качественно поданный материал. Есть также бонус для плюсовиков:
bartoszmilewski.wordpress.com/2011/07/11/monads-in-c/
Да и вообще блог Милевски очень интересное чтиво.
С точки зрения математики всё ясно — это ещё один уровень абстракции позволяющий оперировать объектами разной математической природы с помощью единого матаппарата. С точки зрения утилитарной непонятно ничего. Придать концептуальную чистоту хаскелю — это локальная проблема адептов и авторов хаскеля — к индустрии производства и разработки ПО это отношения не имеет. Вот Вы упомянули мэп-редьюс и все как-то оживились, правильно, — все знают, что мэп-редьюс это реальная технология, которую можно пощупать и, более того, использовать в своих решениях — значит есть смысл разбираться. Никто, из действующих разработчиков, не будет изучать технологию, я уж не говорю о её теоретических основах, если не будет знать конкретно — какое множество задач можно с её помощью решать. Это не из снобизма, или тупости — инженерам-разработчикам слишком много нужно держать в голове, и порой это знания эмпирические и эвристические, которые невозможно вывести логическим путём из теории, а только запомнить и научиться применять на интуитивном уровне. Просто нет ни времени, ни ресурсов на усвоение чисто-теоретических знаний. Вот если Вы в начале статьи дадите перечень практических возможностей и круг решаемых задач, тогда для читателя не будут страшны ни Ваши стрелочки, ни эндоморфизмы, ни прочие математические кунштюки.
И при этом, Вы не обижайтесь, изложено всё очень сумбурно — такое ощущение, что Вы сами недавно разобрались с этим предметом и решили представить свои умозаключения в публичном виде. Это похвально, но Вы указали лишь реперные точки своих умозаключений, опустив рассуждения и это делает изложение ещё более запутанным, чем если бы это было описано чисто математическим языком. К сожалению это не только Ваша беда, таким подходам грешат практически все «переводы» академических работ, выкладываемых, якобы для научно-популярного обозрения — ни рыба — ни мясо. Для научной статьи слишком фривольно, для научно-популярной — слишком не понятно — и не понятно — зачем? — В чём практическая польза от использования теории категорий в повседневной жизни, в данном случае, разработчика ПО.
Что касается патентов, то в ближайшее время их не отменят, потому что это ещё один финансовый пузырь на рынке в котором сосредоточена большая часть капитализации хайтек-компаний.
Что касается изобретений и инноваций в гугле, майкрософте, айбиэм или оракл, то это вздор — эти компании уже давно ничего не изобретают сами, они лишь покупают изобретённое мелкими компаниями, да финансируют рынок венчурного капитала, который кстати тоже пузырь не хилый с его то непредсказуемостью.
Тут тебе и rvalue-ссылки &&, и constexpr, и шаблоны с переменным количеством параметров. Без этого ж не кодилось.
…
Зачем так усложнять. Зачем все эти шаблоны шаблонов. Перегруженные шаблонные операторы приведения типа..." — Понятно, что Вам не нужно, всё, что относится к мета-программированию, а для меня, например, использования буст.прото и разработка своего эмбеддед DSL для задачи — это, то с чего я начинаю работу над проектом или его частью. Видимо, те проекты, которые разрабатываете Вы уместнее было бы делать на джаве или си-шарпе — безо всякого сарказма. Если Вы затрудняетесь расстановкой спецификаторов и модификаторов, то нужно использовать код-сниппеты, которые генерят шаблонные декларации и имплементации методов и классов или использовать какую-нибудь UML — систему проектирования.