• Независимые браузеры более не конкурентоспособны
    0

    Из этого возникает вопрос, как так получается, что у автора поста проблема? Почему чтобы быть популярным надо поддерживать DRM — люди дурачки, что ли выбирают, чтобы им жизнь испортили? И почему нетфликс выбирает DRM а люди выбирают нетфликс? В нетфликсе не знакомы с этим исследованием? В нетфликсе дурачки?

  • Чем меня разочаровал Typescript и стоит ли он того?
    0

    То есть автоматизировать можно не только рефлексией? А если, например генерировать автоматически и не сохранять в кодовой базе (например, partial классы), которые считать некоторым промежуточным представлением?

  • Чем меня разочаровал Typescript и стоит ли он того?
    0
    причём автоматизировать это можно только рефлексией без каких либо гарантий на этапе компиляции.

    А кодогенерация? типа


    https://github.com/cezarypiatek/MappingGenerator

  • Прощай, чистый код
    0

    Я бы подумал о том, как мне удобно это формулировать.


    Вот, например, если бы я писал текстовый документ, я бы поместил это в раздел "Треугольники", "Квадраты" или "Прилипание фигур" чтобы было компактно и понятно?


    Если, например, ресайз специфичен для видов фигур а не видов каких-то еще штук, я бы его отнес к фигурам.


    Если прилипание всегда зависит от каждой пары, то его раздел в "прилипание", если есть несколько выделенных пар, но в основном нас интересует прилипание к прямоугольнику, то можно в разделе "прилипание" сначала описать эти пары, а потом "любая фигура и прямоугольник — см раздел "прилипание к прямоугольникам" в разделе посвященной этой фигуре".


    Если язык такого не поддерживает, приходится воплощать десятое правило Гринспена.

  • Strong Types, или — все-таки — Strong Hypes?
    +1

    К какая IDE умеет извлекать информацию о типах из документации? Возможно я чего-то не знаю, но пока я вижу некоторые усилия по формализации описаний типов (type annotations в питоне, typescript) а не разбор естественного языка в документации.

  • Strong Types, или — все-таки — Strong Hypes?
    0

    Не является ли это разновидностью статической типизации?

  • Strong Types, или — все-таки — Strong Hypes?
    0
    Она должна вводить интерфейсы.

    А как они должны описываться?

  • Strong Types, или — все-таки — Strong Hypes?
    +1

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

  • Функциональное программирование — это не то, что нам рассказывают
    0

    Почему нельзя проверить и выдать результат "если core реализован корректно, то эта функция ничего не выводит на консоль"?

  • Функциональное программирование — это не то, что нам рассказывают
    0
    да и не может проверить по достаточно очевидным причинам

    По каким?


    Насколько я понял, он проверяет и заставляет громко поклясться мамой (unsafeperformio) что легко отличимо на code review либо не использовать.


    Насколько я знаю, есть раcширение Safe Haskell в GHC которое позволяет отличать тех кто клянется мамой от тех кто использует чужие клятвы мамой и выбирать доверять этим клятвам или нет.


    Во-вторых, "проверяет" не то же самое, что "проверяет и дает 100% гарантию". 100% гарантии нигде нет.

  • Публикация кода VVVVVV показала, насколько грубо устроены игры внутри
    0

    В приткладном — свой мир со своими бизнес правилами. Пользователю нельзя давать выстрелить себе в ногу. И не только себе.

  • Микросервисы: как соблюсти контракт
    0
    и следить за границами

    следить за соблюдением каких правил?


    Код ревью.

    А что-то автоматическое?

  • Микросервисы: как соблюсти контракт
    0

    Я так понимаю, что в микросервисах огранисения типа агрегатов DDD — нельзя например передавать ссылки, на что-то внутренне а только value object. Пакеты это никак не ограничивают.

  • Микросервисы: как соблюсти контракт
    +1

    Интересно, не придумал ли кто-то способа энфорсить слабо связанную архитектуру, не заставляя маршалить данные и взаимодействовать по сети?

  • Функциональное программирование — это не то, что нам рассказывают
    +1
    сли такой договор есть и мы верим, что человек, который ф-ю писал, ему следует — то надо, с-но, посмотреть на имя функции/тип/документацию и выяснить, вызывает она внутри print или нет.

    Если договоренность есть, то можно написать инструмент, который будет проверять это. Если договоренности нет, то придется исследовать все дерево вызовов.


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


    100% гарантии никогда нет — бывают ошибки в компиляторах или рантаймах.


    Если же договоренности нет (или веры нет) — только тело смотреть, других вариантов не остается.

    Т.е. есть разница между наличием и отсутствием договоренностей?

  • Функциональное программирование — это не то, что нам рассказывают
    0
    Причем этот ризонинг делаться будет совершенно одинаково что в хаскеле, что на сишке.

    Это касается абсолютно всех программ программ на хаскеле или только того подмножества где есть только монада IO и ни одной функции не использующей этой монады?

  • Функциональное программирование — это не то, что нам рассказывают
    0
    А можно — как "композиция ф-й Stack -> Stack", никаких сайд-эффектов, чистая функциональщина.

    Можно предложить разделение на формально-функциональную и функциональную по духу программу.


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


    Прок от формальной функциональности в том, что императивный стековый мирок там будет изолирован.

  • Функциональное программирование — это не то, что нам рассказывают
    +1

    А код — это не только поведение. Код — это еще и восприятие человеком. Для людей нужны названия переменных, комментарии, разбиение на функции для понятности и так далее.


    Еще мне интересно как вы автолифтанете reflection. Я не очень во все этих монадах. Но мне кажется, что тогда из семантики языка придется убрать всякие int и прочее и оставить только IO int либо думать о что MethodInfo.GetParameterType возвращает анлифченный тип параметра.

  • Функциональное программирование — это не то, что нам рассказывают
    +2

    Это только если вы придумаете свой язык с синтаксисом, допустим C#, и будете приписывать ко всем функциям IO (назовем его, допустим IO#). В реальном языке C# никакого IO, его нет в документации библиотеках и reflection. Язык — это договоренность относительно того, что, что означает.


    Как только вы придумаете такой язык, он будет бессмысленным, так как там будет две категории функций — те, к которым осмысленно приписано IO типа Console.WriteLine и те, к которым бессмысленно приписано IO типа String.Concat и нет никакого способа не приписывать IO к функциям и от этого приписывания нет никакой выгоды.


    Т.е. вы можете мысленно транслировать C# на очень похожий бессмысленный язык IO# но


    1. это будет другой язык, так как то, что считать параметром а что считать возвращаемым значением уже определено в спецификации C#


    2. это будет бессмысленный язык так как на нем не будет возможности не приписывать IO к функциям.


  • Функциональное программирование — это не то, что нам рассказывают
    0

    Я так понимаю, что когда она интерпретируется то тоже нет сайд эффектов, так как состояние мира передается как RealWorld

  • Функциональное программирование — это не то, что нам рассказывают
    0

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


    int Factorial(int n)
    {
        Log.Info($"Computing factorial of {n}");
        return Enumerable.Range(1, n).Aggregate((x, y) => x * y);
    }

    Как если мы запретим другим частям программы, например, читать этот лог, но мы получим ссылочную прозрачность и можем считать эту функцию чистой.

  • Функциональное программирование — это не то, что нам рассказывают
    0
    Представьте себе, что в условном C IO написано просто везде, поэтому, чтобы не захламлять программу, договорились его нигде не писать явно — компилятор проставит

    Если компилятор проставит, то это значит изменение типа — т.е. я смогу например в своей функции мемоизации проверить не содержит ли тип IO и принять решение могу ли я мемоизировать эту функцию или нет.


    Рассуждения Druu верны если отбросить то, что у библиотек, компиляторов, IDE, RTTI и других людей уже есть некоторое соглашение о том, что является типом и аргументами функции а что — нет.


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

  • Функциональное программирование — это не то, что нам рассказывают
    0

    С моей точки зрения она всегда чистая (я не очень силен
    монадах). Просто когда вы ее выполняете внутри монады завернут RealWorld (состояние мира) и оно всегда разное, а способов его генерировать запоминать и не возвращать не бывает.


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

  • Заменяем User Story на Job Story
    0
    что является не лучшей идеей

    Тут битая ссылка


    Как модератор, я хочу создать новую игру, введя название и необязательное описание.
    Или же:
    Я хочу создать новую игру, введя название и необязательное описание.
    Неужели небо рухнуло?

    Если я сисадмин, я могу сделать это скриптом — мне нужна автоматизируемость, если я модератор, у меня должен быть удобный интерфейс. Если я игрок, у меня могут быть урезанные права, например.

  • Функциональное программирование — это не то, что нам рассказывают
    +1

    Допустим вы воспринимаете программу на C как синтаксический сахар для программы на haskell, где все функции подняты в IO.


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


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


    Как только вы мысленно уберете IO из типа этих функций у вас будут ошибки мысленной компиляции.


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

  • Функциональное программирование — это не то, что нам рассказывают
    –1
    Так а какая разница?

    Разница в том, что автор считает чисто функциональной программу в которой есть одно гигантское определение чистой функции внутри которого грязный код


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

    Я не очень понимаю, что такое "содержательный способ" в данном случае. В моем представлении речь идет о том из кусков какого типа мы составляем программу — то есть о форме записи алгоритма.


    Если является — то грязных функций не существует, т.к. любую грязную ф-ю в любом языке можно рассматривать как функцию, возвращающую ИО.

    Речь идет о способе выражения программы. В тот момент как мы представляем функцию, возвращающую IO мы мысленно делаем эквивалентную функциональную программу. Мы можем мысленно перевести практически все с русского на английский, это не означает что английский и русский, это одинаковые языки. Или что запись длины в дюймах то же самое, что запись длины в сантиметрах. Или что полярные координаты это то же самое что и декартовы.


    Мы можем, конечно, себя ограничить и написать формально чисто функциональную программу написанную в императивном стиле, как допустим, мы можем написать объектно ориентированный эмулятор оборудования на C# и писать все на нем (типа processor.Registers.Ax.Move(processor.Registers.Bx)). Но тогда у нас, по крайней мере, будет способ заводить новые чистые функции и они будут отделены от IO/RealWorld.


    Что вы подразумеваете под "чистой ф-ей" в данном случае?

    "В языках программирования, чистая функция, это функция, которая:


    • является детерминированной;
    • не обладает побочными эффектами"
  • Функциональное программирование — это не то, что нам рассказывают
    +1

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


    Это определение относится не к тому, что делает программа, а из чего она собрана — т.е. это некоторый способ соединения частей программы.


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


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

  • Инженер превратил робопылесос в дрон, чтобы он перелетал препятствия
    +10
    трехвинтовой квадрокоптер.

    "Квадро" означает "четыре". Это трикоптер.

  • Я больше не хочу работать, никогда и ни над чем. Но из меня научились выжимать результаты
    0

    Я думаю, это больше зависит от атмосферы в конкретном коллективе. Если люди поверят, что начальству не все равно, то большая часть будет работать на результат, а от остальных можно избавиться.


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

  • Парадигма разработки через комментирование
    0

    На codereview могут указать на неправильную терминологию. А переименовать ее достаточно легко — ide помогут.

  • Функциональное программирование — это не то, что нам рассказывают
    0

    А в каком-нибудь понимании есть?

  • Функциональное программирование — это не то, что нам рассказывают
    0
    С нашим факториалом можно обращаться — распараллеливать рассчеты разных факториалов и вот это все.

    Это иллюстрация того, что можно сделать с чистой функцией. А что можно сделать с чистой программой, что нельзя сделать с нечистой?


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

  • Функциональное программирование — это не то, что нам рассказывают
    0
    С точки зрения D — является

    Там определение чистой функции а не чистой программы.


    У нас есть ваше определение


    Функциональная программа — программа, состоящая из чистых функций.

    По которому не понятно, что значит "состоящей из" и вот например из википедии


    In computer science, purely functional programming usually designates a programming paradigm—a style of building the structure and elements of computer programs—that treats all computation as the evaluation of mathematical functions. Purely functional programming may also be defined by forbidding changing-state and mutable data.

    Purely functional programming consists in ensuring that functions, inside the functional paradigm, will only depend on their arguments, regardless of any global or local state.

    Если под "состоящей из" понимать что там должны быть только определения чистых функций, то непонятно, как им пользоваться. Программа может состоять из одной гигантской чистой функции реализация которой написана императивно и с ее логикой нельзя будет обращаться как композицией чистых функций — распараллеливать автоматически и так далее.


    Что внутри тела, неважно, до тех пор, пока она ссылочно прозрачна.

    Неважно для того, кто вызывает эту функцию, или для программиста который пишет/меняет ее тело?

  • Функциональное программирование — это не то, что нам рассказывают
    –1

    Там про то, почему функция чистая, а не почему программа чисто функциональна. С первым пунктом у меня та же точка зрения, а со вторым нет.


    Если принять ее за черный ящик

    В программе нет никого, кто использует функцию (т.е. принимает за черный ящик), а, наоборот, есть определение и реализация. Реализация определена не только через чистые функции, => программа не является чисто функциональной, хотя функция является.


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

  • Функциональное программирование — это не то, что нам рассказывают
    0

    Итого у нас есть чистая функция с нечистым телом. Ни одного вызова чистой функции в программе нет. Считается ли вся программа чистой в данном случае?


    на практике в данном случае не особо мешает

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

  • Функциональное программирование — это не то, что нам рассказывают
    –1

    что такое "локальный мутируемый стейт"? До какой степени локальный?


    *= совершенно аналогичен функции


    void  MultuiplyBy(ref int accumulator, int multiplier)
    {
         accumulator *= multiplier
    }
    

    acumulator не является локальным состоянием для функции MultuiplyBy но может являться локальным для какого-то скопа сверху.


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


    Нам не важно пишем ли мы чистые функции или нет, важно пользуемся ли мы только ими или нет.


    С моей точки зрения функция, которую вы написали, является чистой, а программа — нет.

  • Функциональное программирование — это не то, что нам рассказывают
    0

    А что такое ХКТ — я по быстренькому не нашел?

  • Функциональное программирование — это не то, что нам рассказывают
    –1
    Так ведь? С одной стороны да. А с другой именно вторая программа в отличие от первой является функциональной.

    Как это? Там есть *= которая не является ссылочно-прозрачной. Функционально чистой была бы программа, которая только бы вызывала эту функцию, но не состояла из ее определения. Например, если бы это была чистая программа эксплуатирующая грязный рантайм с чистым интерфейсом.

  • Нетоксичное лицемерие
    0
    откуда вообще взяться комментариям «этот код — дерьмо»?

    У того, кто пишет и ревьюэра разный критерий дерьма?
    Нарпимер, как я понял, для вас приемлем код похожий на результат обфускации но который работает. А для кого-то, может, наборот — небольшая ошибка — недочет, но если переменные названы непонятно, то дерьмо.

  • Нетоксичное лицемерие
    +1

    Плохо стучать или хорошо зависит от того, кому стучишь. Если власти в целом плохие, то плохо, если власти хорошие, то хорошо. Соответственно в разных обществах разное отношение.