• Программист должен решать проблемы бизнеса
    0
    А вот это похоже на правду — увидел уборщика, который тёр тряпкой, и спросил, что он делает. Руководство программистов зачастую такое же тупое
  • Программист должен решать проблемы бизнеса
    0
    В той статье, где программист не должен париться проблемами бизнеса, при голосовании автора полностью поддержали более 60% респондентов, а в это статье, главный тезис которой в общем-то противоположный, автора поддержали более 70%. Возникает вопрос, какова репрезентати́вность голосования и вообще что оно отражает. Возможные варианты:
    — красноречие авторов склоняет читателей на свою сторону, хабралюди — это люди, в общем-то, с ещё несложившимися мировоззрениями, на их мнение можно легко повлиять, красноречиво выразив свою точку зрения;
    — в целом голосовать склонны более те читатели, которые настроены позитивно к теме статьи, а те, что отрицательно, — скорее воздержатся от голосования.
    Как по вашему мнению, для чего проводится голосование и что оно отражает, есть ли в нём какие-то более интересные факты, чем те что на поверхности?
  • Величайшая ошибка в истории физики
    +1
    Главная идея статьи о том, что эксперимент стоит выше всего теоретизирования, мне лично не нравится. Я в данном вопросе встал бы на сторону Пуассона. Неужели эксперименты в физике всегда были решающим фактором, неужели физика как и любая другая наука не была озабочена тем, чтобы совершенствоать свою доказательную базу, разве могут просто результаты экспериментов без их глубокого осмысления и изложения в соответствии с прежними положениями теории составить хоть сколько-нибудь серъёзные знания? Пуассон в попытках опровергнуть умозаключения Френеля не только не сделал «величайшую ошибку», но и внёс не менее значимый вклад в науку, чем те, кто в итоге поставили эксперимент. Вообще метод доказательства от противного, когда вместо того, чтобы явно напрямую доказать что-либо, доказывает что-то иное, чем то, что в предположении проверяется, то есть при допущении истинности главного объекта доказательства приводит к ложности каких-то других положений, из чего делается вывод, что главный объект доказательства ложный. Многие великие умы искали в этом методе некий подвох, и почему на этот метод вообще можно так наивно полагаться. Поэтому оттачивание теоретизирования является нисколько не менее значимым процессом в физике, чем постановка экспериментов.
  • Глубокое обучение программированию: что, зачем и как
    +1
    Недостаточно следовать только новым веяниям, улавливать модные направления, чтобы быть в тренде и оставаться гуру. Движение вглубь зачастую предполагает и освоение фундаментальных технологий. Мне не так давно достался один ios-проект, где значительная часть написана на C++. Но больше всего что меня сначала смутило, что помимо свойственных ios техник многопоточности также использовался API POSIX Threads, который я изучал еще лет пятнадцать назад и который давно считал безнадежно устаревшим в наши-то времена thread-пулов, экзекьюторов, фьюч, akka и других новомодных штуковин. Но в процессе поддержки этого кода оказалось, что в некоторых местах гораздо удобнее использовать C++ классы-обертки над примитивами pthreads, чем тащить логику в objective-c и использвать там мощные GCD и Operations. Вопрос, как мне кажется, не в том, модная ниша или нет, а насколько ты профессионал в своей области.
  • Высшая математика командной строки — GNU Octave
    +2
    Долгое время был уверен во всемогуществе таких именитых программ как Matlab, Mathematica, Maple… до тех пор пока не столкнулся с более-менее серъёзными вещами. Оказалось, например, Matlab, впрочем как и другие известные пакеты, не ахти как поддерживает тензоры, и решение задач математической физики за некторыми исключениями, касающихся некоторых простых случаев, крайне затруднительно в нём, в реальности возникает необходимость писать в нём реализацию численных схем с почти нуля, что само по себе устраняет преимущество его использования как набора эффективных готовых решений. Правда, в самых последних версиях Matlab данные расчётные инструменты были дополнены, но тем не менее, впечатление о Matlab и других гигантах индустрии как о всемогущих универсальных математических пакетах на все случаи жизни было испорчено. В итоге пришлось смотреть в сторону более специфических программ таких как ANSYS, COMSOL и прочих пакетов для решения задач математической физики. Но как и прежде остановился на открытом и опенсорсном варианте в виде OpenFOAM, потому как считаю, что использование открытых программ не только имеет те преимущества, которые описаны в статье, в частности, то, что открытый код всегда можно перепроверить и тем самым обосновать результат, получаемый с помощью этого открытого ПО, но и позволяет лучше разобраться в самих применяемых математических методах. Что касается Octave, хороший пакет, не то что для серъёзных научных работ, но, как было сказано, для категории студент+ прекрасная вещь. Много его использовал, правда, некоторых нужных мне в свое время возможностей, что были в Matlab по обработке сигналов в нем не оказалось.
  • Почему математика хорошо описывает реальность?
    +2
    Теперь мы полностью решили загадку эффективности математики.

    Отлично, лихо вы справились! Помню, несколько лет назад я тоже в основном ради удовлетворения личных интересов задался этим вопросом, правда, чтение многочисленной многоуважаемой и потрясающе интересной литературы так и не дало мне столь категоричного ответа, который вы получили уже на второй страницы (стоило только немного пролистнуть ниже от начала) вашей статьи. Не вдаваясь в премудрости философии и методологии науки, лично для меня этот вопрос остался на следующем уровне. Математика, в первую очередь, это язык изложения описываемых положений, вещей. В связи с этим эффективность математики, по моему настоящему пониманию, может изучаться методами филологии и лингвистики не в меньшей степени результативности, чем в её связи с физикой и другими естественными науками. При этом, заметьте, я математику вообще вынес за рамки естественных наук, потому как считаю, что математика настолько же стоит за рамками, но в то же время настолько же близка как к естественным, так и к гуманитарным наукам. Математика — это всего лишь язык, и заметьте, та же физика помимо математики с требуемой точностью описывается и естественным языком, который мы используем для общения. Почему эффективна математика, по моему скромному мнению, это такой же вопрос, как и почему эффективен язык (русский, английский), почему, если дать описание, инструкцию, сообщение на естественном разговорном языке, подобные выражения мысли оказываются «удачно» связанными с действительностью… если не вводить, конечно, поправки на адекватность индивидуума, их произнесшего. Математика развивается исходя из своих собственных возможностей, правил. И сложные выводы, теоремы получены математиками не в связи с осмыслением их применимости к реальному миру, а исходя из возможностей использования самого языка математики, включая логику (правила вывода) построения новых объектов, исходные положения и т.д. Если исходные положения с достаточной очевидностью накладываются на реальность (прямая, точка, число и пр.), то, следует ожидать, что и результаты сложных выводов, полученные с нашим пониманием очевидности (логика), также окажутся весьма эффективными к применению к реальности. При этом, заметьте, нерешённые проблемы математики не доказывают нелегкую судьбу нашего с вами бытия, реальности, Вселенной и т.д., они лишь показывают ограниченность математики как человеческого (используемого людьми) языка и всего лишь навсего. Теорема Гёделя о неполноте ни коем образом не говорит, что мы оказались в ущербной Вселенной, где могут происходить не поддающиеся никакой логике казусы, она лишь показывает что у используемой в математики логики, по сути дела языка, есть свои ограничения, которые на данном этапе развития этого языка ещё не разрешены. Ещё раз повторюсь, изложенное — просто мое нынешние понимание, которое я счёл приемлемым для своего внутреннего использования, для своего мировоззрения, так сказать, которое не претендует на какой-либо научный статус. Вообще очень рекомендую литературу по данной тематике, которая доставила мне массу удовольствия:

    Владимир Успенский. Апология математики.
    Р. Курант, Г. Роббинс. Что такое математика?
    Клайн М. Математика. Утрата определённости.
    Клайн М. Математика. Поиск истины.

    Прошу простить меня за не по правилам оформленный библиографический список. Вообще очень люблю книги Рихарда Куранта, любой его учебник, любой труд по любому разделу математики изложен настолько живо, интересно, что погружает не только в суть означенной темы, но и почему математика и здесь эффективна, рекомендую )
  • «Ровная» объектная модель или чего стоит «синтаксический сахар»
    0
    Кстати, хотел высказать ещё одну точку зрения в подкрепление основной мысли своей статьи. По C# я привёл достаточно примеров, но мало рассказал о Java, а ведь как раз Java развивается совершенно иначе, нежели C#. Многие говорили, и на хабре в частности, что C# развивается быстрее, чем Java. Но на мой взгляд, C# обрастает разного рода «хаками», в то время как в Java объектная модель остаётся более консервативной. Можно ли сказать, что Java от этого в убытке? Не думаю, да и внешне это никак не видно, рейтинг по версии TIOBE — второе место. Казалось бы, в Java синтаксис в разы проще, чем в C#, но язык от этого не слабее. Да, в Java нет таких сомнительных хаков, в частности над объектной моделью, как типы-значения (исключая примитивы, которые полностью за рамками объектной модели), структуры, невиртуальные функции. Да и от того, что в Java нет замыканий и генераторов, проигрыша от этого тоже нет. В Java есть нестатические внутренние классы, в том числе и анонимные, а это стоит больше, чем разного рода замыкания и больше соответствует «нормальной» объектной модели. В Java перечисления — действительно объекты, которые могут удовлетворять заданным интерфейсам, чего не скажешь о перечислениях в C#. А то, что в Java 7 всё же не включили замыкания — не велика потеря. Так что меня полностью устраивает, как развивается Java, и ей, в частности, были навеяны идеи, которые я изложил в статье.
  • «Ровная» объектная модель или чего стоит «синтаксический сахар»
    0
    Прошу прощение, опечатка: «хранить состояние только во внешним контексте, но не в собственном».
  • «Ровная» объектная модель или чего стоит «синтаксический сахар»
    0
    Логично пишите, я могу согласиться с вами и по части того, что сравнивать prototype-based и class-based подходы не корректно, и по части того, что ничто не застрахует программистов от «кривых рук». Даже, чего скрывать, я полностью с вами согласен. Но всё же есть «но». Я сам уже вижу, что недостаточно чётко раскрыл главную тему статьи. Моя цель заключалась вовсе не в том, чтобы вызвать сравнение прототипо-ориентированных языков с класс-ориентированными, и даже не в том, чтобы задеть за живое функциональщиков. Да, я имею представление о функциональном программировании, сам писал реальные приложения на Lisp и знаю, что ФП мощная вещь и не нуждается в объектной подстилке.
    А в статье главное, что я хотел подчеркнуть, это то что многие возможности современных языков программирования, в том числе замыкания, управляемый полиморфизм (как в C#), и даже генераторы (которые не были рассмотрены в статье, но упомянуты позже в комментарии) не дают столь больших возможностей, как многие это считают. Я хотел рассмотреть язык с минимальной сложностью синтаксиса, но состояние реального положения дел таково, что минимальной сложностью обладает прототипо-ориентированный язык. Поэтому я и заострил внимание на этом подходе. Замыкания, карринг, обёртки функций в чистом виде нужны именно в ФП-языках и именно так, как вы описали в первом комментарии. Но в ООП-языках так или иначе они имеют меньше возможностей, чем вариант на базе явного решения в виде явного создания объекта. В ФП языках (это одна из характерных черт) нет состояния, все функции чисты в том смысле, что извне они обладают ровно пустым состоянием, то есть преобразуют «вход» в «выход» без памяти о том, что было сделано в прежних вызовах. Но в этом и сила ФП-программирования. Сила же ООП-программирования как раз в «программирование с состояниями». Теперь я хочу привести даже не моё мнение, а чисто факты:

    1. Вынесение логики в виде замыкания в ООП-языках преобразуется в объект строго определённого типа, который может замыкаться на внешний контекст и хранить состояние только во внешним контексте, но в собственном.

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

    3. Объект, полученный при явном определении (п. 2), может иметь любой тип, наследовать любой класс, реализовывать любые интерфейсы (протоколы, трейты). В частном случае, он может нести ровно ту же самую нагрузку, что и неявно созданный с помощью синтаксического замыкания объект, описанный в п. 1.

    4. Из пп 1-3 следует, что функциональность явно определённого объекта больше либо равна функциональности объекта, созданного через замыкание.

    Кстати, в подтверждение этого заключения я в статье и привёл два примера на C#.

    Почти то же самое можно сказать и о генераторах. А чтобы использовать решения на базе явного определения объектов достаточно языка с очень простым синтаксисом как, например, Smalltalk. Я не говорю, что замыкания на уровне синтаксиса — это плохо, наоборот они очень даже хорошо смотрятся и, главное, нужно писать меньше. Я хотел сказать, что они более ограничены. Вообще, я хотел сказать, что все хаки более ограничены, чем явное определение объектов.

    Вообще, я уже почувствовал, что написание общетеоретических статей — совершенно проигрышное дело. Спасибо, что не забанили статью. В будущем буду писать статьи только с конкретикой.
  • «Ровная» объектная модель или чего стоит «синтаксический сахар»
    0
    Попробую ответить на некоторые ваши вопросы.

    1. Я знаком с C++ как и ещё полутра десяткой языков и с его невиртуальными методами тоже. Я о нём просто не написал.

    2. В моём «сферическом языке» Class.new() выполняется для создания новых объектов и Class — это объект. Так есть, например, в Smalltalk, где класс Object содержит всё необходимое, чтобы делать новые объекты, но сам он является объектом. В Smalltalk, как и в Self, нет синтаксической конструкции для наследования классов — подкласс создаётся путём отправки сообщения subclass классу-объекту, от которого производится наследование.

    3. Мой язык не такой уж и «сферический», я описал его, используя, в частности, знание Smalltalk и Self, где нет лексических конструкций для определения наследования, инкапсуляции, конструкторов и классов.

    4. В таких языках как C#, Python, Smalltalk замыкание не что иное как объект (замыкание преобразуется в настоящий объект компилятором/интерпретатором).

    5. В некоторых ранних версиях Objective-C представлял собой препроцессор над C++, поэтому и был чистым расширением не C, а C++. Впрочем и сейчас есть сборки, позволяющие использовать C++ в Objective-С, например, вот и вот.

    6. Я делаю вывод, что чистая объектная модель не приводит к плохо структурированному коду, что видно при внимательном прочтении.

    7. Я знаком с yield как в Python, так и в C#. Например, в C# конструкция yield преобразуется не во что иное как в объект IEnumerable. То, как это происходит, хорошо описано здесь.