?

Log in

No account? Create an account

Заповедник репрессивной психиатрии

Entries by category: работа

Доставайте голангистов из гробов
metaclass
Есть вопросы по языку для интеллектуального большинства:
1) Если я форкаю чужую библиотеку, а она унутре себя ссылается на сама себя - как с этим работать? SO советует сначала делать go get оригинальной, затем подключать git remote свою репу и потом править. Т.е. на всех других рабочих местах нужно будет повторять то же самое. По идее, это должен менеджер зависимостей делать в конечном итоге?

2) Что за херня с логгерами и обработкой в этом вашем голанге? В большинстве либ обработка ошибок сводится к log.Println(err) где err - строка в стиле "у вас произошла херня", без объяснений что, где и как, причем способа привязать логгер к пакету я чо-то не нашел.

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

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


Представляю себе требования к вакансии, типа "Знание налоговых и бухгалтерских оперденей, понимание теории категорий, реляционной алгебры, жим лежа не меньше 100 кг".

Ссылка с planet haskell, наследование
metaclass
Reflections on leaving Haskell

Там есть две вещи, которые чувака упарили в хаскеле. Первая - это отсутствие наследования реализации datatype. Я тут немного долбанулся головой в последнее время и забыл зачем вообще нужно наследование реализации.

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

Например, недавняя задача: есть объект типа "датагрид". C ним пользователь сделать три действия: открыть текущую запись-объект на редактирование, воспроизвести из одного из полей текущей записи аудиозапись, открыть из другого поля этой записи большой текстовый документ на редактирование. Это все представляется в виде объекта типа "текущее рабочее место пользователя", содержащей этот грид и методы, замапленные на меню/тулбар. Если бы действия были независимы - сделал бы три наследника базового рабочего места: "с редактором записи", "со звуком", "с редактором текста".
Но дело в том, что эти три действия могут комбинироваться в любых вариациях и вместо наследования тут получается проще сделать некую аггрегацию, собирая из комбинаций типов "рабочее место с гридом", "рабочее место с редактором объекта", "рабочее место со звуком, "рабочее место с редактором текста" итоговый тип рабочего места, склеивая их анонимными делегатами, связывающими текущую запись в гриде и действия с ней из других классов.

И так, если глянуть, почти везде - везде наследование реализации выглядит прибитым гвоздями сбоку. Кроме одного частного случая, как и там по ссылке - когда нужно из двух-трех объектов данных, отражающих частные аспекты, собрать новый. Например "финансовый документ" + "объект, внесенный в определенном филиале по определенной ИМНС" = "финансовый документ с привязкой к подразделению и ИМНС". Хотя тут, по идее аггрегация, тоже бы помогла, наследование тоже выглядит прибитым сбоку.
Tags: