анализа литературы по разработке и аудитории различных конференций
Неужели не нашлось литературы по FP, или логическому программированию? Или не проводиться конференций по этим технологиям?
Но пока сторонники функциональной парадигмы пишут своё ПО на IDE которое полностью оопэшное и запускают его на осях которые полностью оопэшные.
Есть и обратная сторона медали. ООП-шники используют в своей работе много «вещей» написанных на функциональных языках, например RabbitMQ — используя его вы думаете о меседжинге и очередях, а не о функциональщине и Erlange. Тоже самое и с IDE — какая мне разница на какой технологии она написана и насколько ее создатель разделяет мои взгляды на программирование? (главное чтобы работала). Вопрос ведь не в том, что я использую, а на чем я пишу/хочу писать/люблю писать.
Мир не-ООП вокруг крайне мал.
У меня есть свой взгляд на эту ситуацию (хотя я очень не люблю сравнивать OOP VS. FP и не вижу конструктива в этом). Но… FP — это программирование с точки зрения математики (чем «функциональнее» язык, тем он ближе к формальным математическим законам), FP дает вам «Formal provability» и требует от вас того же. ООП — это программирование с гуманитарной точки зрения — создавай объекты как ты «видишь мир», описывай взаимодействие как ты его «видишь». Эта свобода все облегчает — мне нужно знать формальные законы, которые связывают мои типы данных и их преобразования. Но отсюда и проблемы — imagination меняется с изучением домена, рефакторить не просто, разбираться в чужом коде сложно — это чужой imagination. Отсюда паттерны, соглашения и тд.
С этой точки зрения ситуация очевидна. У нас очень много людей, которые пишут и читают художественную литературу. И катастрофически мало людей, которые доказывают математические теоремы или читают чужие доказательства.
Могу ошибаться, но e2e4 имеел ввиду другое (просто неудачно использовал термин «медленный клиент»). Проблемой для event-loop будет если control flow задержиться на обработке какого-то запроса. Не важно по какой причине: затянувшийся computation, блокирующий запрос к базе, или еще что-то. Для одного клиента это может быть незаметно, ну на 1 сек сервер задумался — с кем не бывает. Но в данном случае получается, что 1 млн клиентов ждали эту одну секунду — а это совокупно более 11 суток потраченного времени ваших клиентов. И это даст очень резкий пик на графике среднего времени ответа (потому что эта 1 сек пойдет в плюс всем).
Синтетичность теста в том, что он делает достоверно простую операцию независимо ни от каких факторов. В продакшин системах, выполняющих какую-то полезную логику, все намного сложнее.
Ну… Опять вы за свое. В ваших логических рассуждениях есть одна очень большая проблема — они основаны на неверной предпосылке. И я вам на это указал явно. Почему вы не хотите этого понять?
Давайте еще раз. Я писал,
И говорю, что вы тоже, раз поддерживаете автора и считает статью дельной.
Я выделил ошибочное суждение, дабы вам было в этот раз попроще. Я не написал ни одного комментария в поддержку статьи либо ее автора. Приведенный вами аргумент — вымысел.
Можно, с радостью выслушаю аргументированное объяснение. Именно аргументированное. А вот ваши высказывания:
вы любитель потрепать на неведомые вам темы
автор не понимает чего пишет, вы тоже не понимаете
автор «плавает» и вы тоже, раз этого не видите
это не аргументы. Это просто персонолизированные оценочные высказывания (ничем не подтвержденные), к тому же высказанные слишком уж надменным тоном. Ввиду этого считаю дальнейший разговор бессмысленным.
Давайте не переходить на личности, это грубо и некрасиво. Я не оценивал ничьи знания (ни автора статьи, ни ваши), поэтому прошу вас не оценивать мои. и не тыкатать меня носом в то, что я вижу, а чего нет (у вас для этого нет никаких оснований).
Я согласен с комментариями habrahabr.ru/post/149096/#comment_5038319 habrahabr.ru/post/149096/#comment_5038093
и не буду приводить здесь свои рассуждения, дабы не повторяться. Если вы считаете, что исчерпывающий ответ на эти комментарии — «человек забыл про принцип единственной обязанности», то пусть так и будет. Собственно об этом и был мой предыдущий комментарий.
Прежде чем говорить что это говно, научитесь его использовать и научитесь мыслить объектно. Научитесь проектировать и программировать используя ООП.
Я знаю, ООП скоро объявят религией, а любое инакомыслие будет жестоко наказаваться инквизицией. Программисты на Haskell/Erlang/Lisp/Clojure/etc будут гореть в аду за прегрешения и нежелание познавать «О великую истину ООП». Детский сад, ей богу.
Как по мне, то основная причина столь долгих споров заключается в следующем: в комментариях ко всем статьям приводятся указания на различные нестыковки, несогласованности, «непонятностях» в парадигме. Ответы на вполне обоснованные вопросы сводятся к проповеди: «уверуй грешник, ибо правда».
А по поводу
Люди будут еще очень долго кричать что ООП зло. Но чаще всего, это связанно с тем, что они не понимают его и пытаются всему миру доказать, что это не у них не получается, это ООП такое стремное.
ООП это не верх эволюции мышления программистов, там многое притянуто «за уши». А фразы типа «вы сначала научитесь, а потом тут рассказывайте» вообще лишены смысла. С тем же успехом я могу сказать: Научитесь писать на функциональных языках, изучите и познайте теорию категорий, и да возрадуйтесь монадам ибо это хорошо, и да не использованы будут мутабельные данные и не настигнет нас гневный race condition, и принесите функцию в жертву функтору аппликативному и да соблюдите чистоту в функциях порядка высшего… и вот уже тогда пишите нам о том, что такое ООП и какое оно прекрасное (если, конечно, захочется).
С появлением «методов» всплыл ещё один приятный момент в части организации функционала: вместо создания 900 функций с перекрёстно дублирующимися первыми и вторыми половинами названий (помните WordBasic?) можно сделать 30 классов с 30 методами в каждом.
Это заслуга ООП? Нет. Чем это лучше 30 функций в 30 модулях?
Также, в стало возможным сделать языки со строгой типизацией, что дало возможность перенести время обнаружения многих ошибок с фазы выполнения программы на на фазу её компиляции.
Строгая типизация тоже заслуга ООП? Да, ну, ладно, посмотрите на OCaml и Haskell. И не надо приписывать все на свете к «великим достижениям ООП».
Не понял комментарий, но, с ссылкой на завершающий смайлик, сочту за шутку.
На самом деле в исходной строчке кода задача-то и не была поставлена, поэтому «выдумана» из контекста. Но никто не мешает писать код максимально приближенный к доменной модели.
Во-первых, я не знаю почему вы взяли именно протокол передачи данных, а не, например, протокол преобразования (или еще чего-нибудь).
Во-вторых, даже в описанном примере, протокол — описание порядка передачи данных от «кого-то» «кому-то» и поведение «передать данные» присуще «кого-то» (а не протоколу), «получить данные» — это поведение «кому-то» (а не протокола) и т.д. Тоже самое с состоянием.
А вы не задумывались что поток, протокол или скажем сценарий тоже есть объекты? Которые обладают свойствами и поведением. Которые взаимодействуют с другими объектами.
По логике, Протокол и Сценарий это некоторые описания взаимодействий. Каким-таким «поведением» они должны обладать? Я могу использовать протокол, могу не использовать. Но я не могу представить, что протокол еще может себя как-то вести (отказаться использоваться? полиморфно подмениться на другой?.. не могу придумать здравый вариант).
У нас в ВУЗе используется что-то подобное. Написано нашим информационным центром и специалистами кафедры экономической кибернетики. Достаточно удобно, жалко только у каждого факультета свой ресурс (общего нет).
Не знаю как по российскому законодательству, но в Украине банк предоставляет по запросу налоговой данные по движению средств по конкретному счету конкретного юридического лица (или фоп) за конкретный период. По физ. лицам только по запросу органов, но для этого должно быть решение суда, а для открытия дела и доведения до суда нужно сначала что-то предьявить на вас.
Вопрос был не о том ;)
Неужели не нашлось литературы по FP, или логическому программированию? Или не проводиться конференций по этим технологиям?
Есть и обратная сторона медали. ООП-шники используют в своей работе много «вещей» написанных на функциональных языках, например RabbitMQ — используя его вы думаете о меседжинге и очередях, а не о функциональщине и Erlange. Тоже самое и с IDE — какая мне разница на какой технологии она написана и насколько ее создатель разделяет мои взгляды на программирование? (главное чтобы работала). Вопрос ведь не в том, что я использую, а на чем я пишу/хочу писать/люблю писать.
У меня есть свой взгляд на эту ситуацию (хотя я очень не люблю сравнивать OOP VS. FP и не вижу конструктива в этом). Но… FP — это программирование с точки зрения математики (чем «функциональнее» язык, тем он ближе к формальным математическим законам), FP дает вам «Formal provability» и требует от вас того же. ООП — это программирование с гуманитарной точки зрения — создавай объекты как ты «видишь мир», описывай взаимодействие как ты его «видишь». Эта свобода все облегчает — мне нужно знать формальные законы, которые связывают мои типы данных и их преобразования. Но отсюда и проблемы — imagination меняется с изучением домена, рефакторить не просто, разбираться в чужом коде сложно — это чужой imagination. Отсюда паттерны, соглашения и тд.
С этой точки зрения ситуация очевидна. У нас очень много людей, которые пишут и читают художественную литературу. И катастрофически мало людей, которые доказывают математические теоремы или читают чужие доказательства.
откуда такая информация, что «всех» устраивает?
по какой шкале мерять какая парадигма лучше?
«The big idea is 'messaging' — that is what the kernel of Smalltalk/Squeak is all about...» © Alan Key. Так что все-таки, в Python OOP работает «по-другому» (если можно так сказать). К тому же Python OOP (в отличие от Smalltalk) не является «pure» — как и в Java/C++.
Т.е. вывод о «правильности» не слишком уж очевиден.
Синтетичность теста в том, что он делает достоверно простую операцию независимо ни от каких факторов. В продакшин системах, выполняющих какую-то полезную логику, все намного сложнее.
Давайте еще раз. Я писал,
Вы же продолжаете твердить
Я выделил ошибочное суждение, дабы вам было в этот раз попроще. Я не написал ни одного комментария в поддержку статьи либо ее автора. Приведенный вами аргумент — вымысел.
Жаль.
Неправда. Читайте, пожалуйста, внимательно habrahabr.ru/post/149096/#comment_5039788
Можно, с радостью выслушаю аргументированное объяснение. Именно аргументированное. А вот ваши высказывания:
это не аргументы. Это просто персонолизированные оценочные высказывания (ничем не подтвержденные), к тому же высказанные слишком уж надменным тоном. Ввиду этого считаю дальнейший разговор бессмысленным.
Я согласен с комментариями
habrahabr.ru/post/149096/#comment_5038319
habrahabr.ru/post/149096/#comment_5038093
и не буду приводить здесь свои рассуждения, дабы не повторяться. Если вы считаете, что исчерпывающий ответ на эти комментарии — «человек забыл про принцип единственной обязанности», то пусть так и будет. Собственно об этом и был мой предыдущий комментарий.
Я знаю, ООП скоро объявят религией, а любое инакомыслие будет жестоко наказаваться инквизицией. Программисты на Haskell/Erlang/Lisp/Clojure/etc будут гореть в аду за прегрешения и нежелание познавать «О великую истину ООП». Детский сад, ей богу.
Как по мне, то основная причина столь долгих споров заключается в следующем: в комментариях ко всем статьям приводятся указания на различные нестыковки, несогласованности, «непонятностях» в парадигме. Ответы на вполне обоснованные вопросы сводятся к проповеди: «уверуй грешник, ибо правда».
А по поводу
ООП это не верх эволюции мышления программистов, там многое притянуто «за уши». А фразы типа «вы сначала научитесь, а потом тут рассказывайте» вообще лишены смысла. С тем же успехом я могу сказать: Научитесь писать на функциональных языках, изучите и познайте теорию категорий, и да возрадуйтесь монадам ибо это хорошо, и да не использованы будут мутабельные данные и не настигнет нас гневный race condition, и принесите функцию в жертву функтору аппликативному и да соблюдите чистоту в функциях порядка высшего… и вот уже тогда пишите нам о том, что такое ООП и какое оно прекрасное (если, конечно, захочется).
Это заслуга ООП? Нет. Чем это лучше 30 функций в 30 модулях?
Строгая типизация тоже заслуга ООП? Да, ну, ладно, посмотрите на OCaml и Haskell. И не надо приписывать все на свете к «великим достижениям ООП».
На самом деле в исходной строчке кода задача-то и не была поставлена, поэтому «выдумана» из контекста. Но никто не мешает писать код максимально приближенный к доменной модели.
Во-вторых, даже в описанном примере, протокол — описание порядка передачи данных от «кого-то» «кому-то» и поведение «передать данные» присуще «кого-то» (а не протоколу), «получить данные» — это поведение «кому-то» (а не протокола) и т.д. Тоже самое с состоянием.
По логике, Протокол и Сценарий это некоторые описания взаимодействий. Каким-таким «поведением» они должны обладать? Я могу использовать протокол, могу не использовать. Но я не могу представить, что протокол еще может себя как-то вести (отказаться использоваться? полиморфно подмениться на другой?.. не могу придумать здравый вариант).
Люди->ВыбратьЧеловека('Вася')->ОтправитьЗаВодкой()Намного ли отличается от:
(отправить-за "водка" (выбрать :имя "Вася" (все-пиплы)))>>> Чем городить кучу функций, распихать по файлах и папках чтобы потом голову не сломать и инклудить можно описывать основную логику в классах.
Не совсем понял. С реализацией на классах ничего инклудить не надо? Или распихивать по файлам/папкам не придется?