(основано на приватной дискуссии в жаббере, слегка отредактировано, просто цитата)

[...] по моему опыту писания на жс там явно не хватает таких вещей:
1. модульность (криво через объекты я умею, нахуй-нахуй),
2. хотя бы тупых вариантных типов данных (через объекты умею),
3. хоть какой-нибудь типизации,
4. closures кривы -- примеры были обсуждены, for (my $i ...), хоть и обходы есть,
5. tail-recursion elimination -- тоже представляю вполне, как это сэмулировать, но в пределах жс общий подход не опишешь, а частные -- уродливы.
Давняя-древняя мечта о роликах таки реализована с материальной стороны. Осталось тушку и дух подтянуть.
В Одессе гораздо больше выбор роликов, в одном только бутике -- в 5 раз больше, чем во всех Бандёрах. Это не новость и не опускалово какое, это "последняя капля". "Здесь и сейчас", потому что иначе -- либо "потом и говно", либо "потом и гемор".
Ну и адекватный продавец, подсказавший кое-какие слишком уж базовые штуки. Про защиту он подтвердил мои догадки -- "те, кто покупает ролики и не покупает защиту, обычно приходят через 2..3 недели за ней".
Итак, аж целых 106$ за приличные китайские ролики и защиту.
Дальше -- лёгкий rtfm в интернетах, и первые упражнения у меня в руках.
Это было вчера. Сегодня же впервые нормально попробовал попользовать ролики.
В первую очередь научился кое-как вставать с пола. Во вторую очередь -- хорошо и качественно падать. Весь цимес в том, чтобы строго вперёд падать. Для этого -- и центр тяжести вперде, и руки желательно держать локтями вниз в первое время, и стараться согнуть ноги в коленях, чтобы на колени упасть. Ибо на хребет/затылок падать -- хуже некуда. На бок либо с распростёртыми конечностями -- просто плохо. А так -- около 5 раз падал сознательно, какое-то новое ощущение от падения. Всё слишком быстро: раз -- и уже на земле. Тут отреагировать (включить моск, сделать движение) сложно, почти невозможно. Надежда на 1. прошивку, 2. тренировку.

Из рабочих моментов -- жопой чуял, но и практикой подтвердилось, что json-static не умеет параметризованные типы. Понятно, что какой-нибудь option 'a он, ясное дело, парсить и не должен, но 1. он не любит типовые параметры даже в случаях фантомных типов и в случае известных типовых параметров, 2. не умеет генерить json по известному параметризованному типу. Пичалька, но попробуем функторы тут. Но, думается, изначально надо было бы делать (не мне, понятно) что-то типа atdgen, но по технологии deriving'а. С другой стороны, atdgen у меня в планах точно, но попозже.
С одной стороны -- халявная поездка на море, в зачотный "дом павловых". С другой стороны -- куча срочной работы. Что делать? Я взял свой сраный нетбук, евдо-модем, а некий "интертелеком", оказывается, предоставляет роуминг для юзеров "интерднестркома" (внезапно молодцы оба-двое шоке шоке). Пусть и по 0.072$/Mb.
Ну и чо, сижу, камлаю. Пусть вид не на море, а на "николаевскую дорогу", но не беда. Надыбать бы удлиннитель, чтобы на веранду вынести всё хозяйство. А ещё под окнами в 20м -- ресторан то ли с живой музыкой, то ли с короокэ, повбывав бы.
И да, пост проплачен тремя организациями.
Все разумные люди знают, что уборка квартиры сама по себе не нужна.
Вещи по квартире рассасываются сами так, как надо, как удобно, как бы выполняя профайлинг доступа к ним методом монтэкарлы.
У меня было даже до состояния самозарождения такой "живности", как "перекати-пол" (так!) из кошачьей шерсти.
Однако, тем не менее, если поддержание чистоты зачем-то нужно (например, просто приятно глазу), есть приём. Не помню, где вычитал, но где-то в жыжыцэ.
Квартира делится на "зоны", уборка которых занимает не больше 15 минут (одна из зон -- пропылесосить ковро, другая -- помыть немного посуды, третья -- помыть пол в коридоре), и вот, во время перерыва между сеансами мысленной деятельности вполне можно заняться чем-то, что не занимает моск, способствует отдыху, но -- чётко контролируемое время, не больше. Главное тут не отключить моск напрочь и не заработаться, иначе физическая усталость, чувство потраченного зря времени и отвращение к процессу. Вплоть до того, что можно будильник заводить, как я периодически делаю, работая по схеме "20 минут работы + 10 минут отдыха" -- ну, типа, "помидорки". (кстати, оказалось, по такой схеме я могу работать порядка 16 часов без перерыва на сон. Потом, правда, отходняк пару дней).
А ещё можно воспользоваться приёмами "автофокуса" -- бытовуху записать на бумажку, на видное место её, и, когда есть настроение, пробежаться глазами по ней, выбрать нужное дело, зачёркивать его наполовину (в случае, если дело периодическое -- дописывать снизу бумажки сразу же, чтобы не потерять его), и идти делать это дело. Дозачеркнуть по исполнении, опционально дописать снизу новые обнаруженные дела. Заодно, в качестве контроля за относительной периодичностью дел -- стараться выбирать дела откуда-то с начала списка. Заодно, в качестве "результата своей деятельности" будете видеть бумажки с полностью зачёркнутыми делами.
Так-то!
Покатался на такси туда и обратно. 14 часов трипа в прямом смысле слова. Ночью-то понятно, поспатки это в пределах нормы, а вот что с утра рубило спать -- "это печально", кое-что пропустил, так как пейзажи (поля, небо, лиман) были охуенными. Эдакое "тру лето", но без адовой жары.
Взял нетбук в надежде поколбасить, но он сдох на 5ой секунде работы. Подленький и маленький.
Понял, что большинство моих проёбов и лишних затрат времени вызваны откровенно хуёвым планированием. Проанализировав частные случаи, пришёл к выводу, что мне нужны 3 штуки.
Read more... )
Так-то. Однако увязать это воедино -- не знаю, как. Всё сложно. А это говорит о том, что такая система будет либо неудобной, либо нестройной, либо сложной в использовании.
У меня была необходимость разобрать записи, получаемые от реляционки (от постгреса в моём случае), в окамле, который строго типизирован.
Read more... )
Если начальник говорит, что "от твоего отпуска вся работа умрёт!", значит эта работа была хуёво поставлена и он жалеет свою жопу. Или Вы действительно незаменимый, по крайней мере в ближайшие несколько дней.
Если подчинённый действительно незаменим для Вас, то Вы хуёвый начальник и обязаны чем-нибудь прикрыть свою жопу в случае, если работник (по мере возрастания серьёзности) умрёт, уволится, заболеет, или, хуже того, уйдёт в отпуск (это самое серьёзное).
Придумался пункт в план работ:
  • Освоение фонда заработной платы
Придумалось новое "правило карликов".
(9:16:26) Ivanych: Мне очень так видится, что можно сделать backend для базок данных.
И одновременно, язычок-backend.
(9:22:18) gdsfh: про backend -- не знаю, просто данные сложить можно, и даже не ёбаный пиздец [в плане сложности реализации], но 1. дубовая структура "таблицы->строки->столбцы" -- фи. 2. транзакции делать -- гемор адский.
(9:22:48) Ivanych: Естественно, что этот быкенд должен поддерживать не только таблички.
(9:29:29) Ivanych: Конечно не такая дубовая структура!
Надо сделать, чтобы в каждом row могли быть разные типы!
(9:29:58) gdsfh1: лололо
(9:30:13) Ivanych: И разное их количество и типы разные, да!
(9:31:28) gdsfh1: беспорядочно содомирующие друг друга!
(9:31:39) Ivanych: ;-) ;-) Exactly!

Правило проверено пока только эмпирически и имеет нестрогий вид: "Если про элементы сложной системы можно сказать 'бегающие по арене и беспорядочно содомирующие друг друга', то, вероятно, система является либо переусложнённой (overengineered), либо логически нестройной, либо слишком расслабленной в плане получаемых от неё гарантий".
Разгрыз аппликативные функторы. Лучше поздно, чем никогда. И не просто в теории, но и на практике тоже.
Хорошая штука для своих применений, главное из которых -- эмуляция "функции с переменным количеством аргументов".
В моём конкретном примере, имея некое окружение (заданное статически пока что, в виде [("a", String "str"); ("b", Int 123); ("c", Bool True)]), код

value () = run &
  (fun f -> f <$> string "a" <*> int "b" <*> bool "c")
  (Printf.printf "a=%S b=%i c=%b")
;


выводит ожидаемое:
a="str" b=123 c=true


Мне эти функторы пригодятся для обработки значений с типом sql_t = [ `Null | `String of string | `Binary of string | ... ].

Конкретику ищите в репке "amall", если представляете, что это.
Уже долго прикидываю так и эдак, но не могу до конца сообразить.
Есть мой dumbstreaming -- протокол для передачи строк, который планирую расширить так, чтобы он позволял передавать не одну строку в одном пакете, а несколько строк сразу.
Конечно, я изобретаю tnetstrings, но у меня преимущество: типы известны заранее (а именно, строки), а не указываются в конце сообщения, сразу известно количество и объём каждой строки, ну и разделители помогают надёжности. Эти преимущества позволят обрабатывать всё потоковым образом.
Для этого у меня есть iteratees.
Задача парсинга разбивается явно на два слоя: 1. парсер потока, которым передаются списки строк, работа с длинами и количествами строк, разделителями -- собственно, дело библиотеки, и 2. парсер непосредственно строк, для каждой строки в теории свой итерат.
Пока единственное, что получилось, это
value read : (stringscount:int -> list (iteratee char 'a)) -> iteratee char (list 'a)
То есть, пользовательская функция получает количество строк в пакете и возвращает список результатов.
Ещё есть идейки позаигрывать с fold:
value read : (stringscount:int -> 'a -> iteratee char 'a) -> 'a -> iteratee char 'a
-- функция получает количество строк в пакете (на всякий случай), текущее значение аккумулятора и возвращает итерат, который будет применён к потоку и который возвратит следующий аккумулятор для следующей строки в пакете.
Однако, весь цимес итератов как раз состоит в замене fold для ввода-вывода. То есть, жопой чувствую, тут может получиться всё решить вложенными(?) итератами. Но как -- не могу сообразить. В общем, простой bind итератов меня бы устроил, было бы (it1 >>= fun v1 -> it2 >>= fun v2 -> return v1 + v2), но фишка в том, что it1 и it2 должны не трогать поток за пределами того, что им выделено, то есть, если в терминах итератов, должно было бы быть что-то типа ((join & take len1 it1) >>= fun v1 -> (join & take len2 it2) >>= fun v2 -> return v1 + v2), и не представляю, как это сделать.
После того, как описал, чуть-чуть прояснился вопрос (а именно, попробовать пойти так же, как из fold получились итераты первого уровня), но, всё равно, как-то непонятно.

UPD2.
"Давай по-новой, Миша, все хуйня."

value read : (ntotal -> npart -> nbytes -> iteratee char 'i)
          -> iteratee 'i 'a
          -> iteratee char 'a

первый аргумент -- пользовательская функция, на основании количества кусков, номера куска и количества байтов в куске выдающая итерат, который будет кушать байтики этого куска и возвращать значение с типом 'i. Второй аргумент -- итерат, который будет кушать значения с типом 'i и возвращать результат с типом 'a. И функция read родит итерат, который применяем к потоку байтов и имеем результат с типом 'a.
Почему преобразование 'i -> 'a и почему не возврат list 'i? Потому что это простым образом делается из текущей схемы, передавая стандартный итерат stream2list, который как раз iteratee 'i (list 'i).
Кто там объекты-классы-методы не любит? Покритикуйте и предложите вариант получше:
Read more... )

wannawrite

Apr. 28th, 2011 02:30 pm
Надо бы написать монографию иллюстрированную с примерами, рабочее название "Лепесток розы и продвижение по карьерной лестнице".
я тут кратенько изложил концепции парвела, чтобы перед глозаме была общая картина того, что же я делаю. https://bitbucket.org/gds/parvel/wiki/concepts_rus
Чем плохо, когда нет леди (будь то временно или постоянно)? Лично для меня -- тем, что все фейлы в cs/it отражаются напрямую: "не получилось придумать такую-то штуку -- я тупой", "не получилось сделать такую-то штуку -- у меня руки из жопы".
А когда леди есть (да и вообще, когда есть разные люди), оказывается так, что кроме этого вашего сраного cs/it есть ещё какие-то вещи, тоже очень хорошие и приятные, где и нужно другое, и критерии оценки другие, и оно вклинивается так, что всё в тему, гармонично, и отвлекаюсь от пристального разглядывания задач, и оказывается так, что фоновая обдумывалка кое-как помогает.
Если суммировать, пользу в других людях я вижу в смещении фокуса самооценки с профессиональных областей на более общие, тоже доставляющие удовольствие и имеющие критерии оценки, и в смещении внимания на совершенно другие вещи, не задрачивающие мозг, и тем самым позволяющие эксплуатировать его в надёжном режиме.
а у меня -- интересное. Впрочем, вытекающее из стиля разработки парвела. Захотел параллельно-запускающиеся процессы с ограничением количества -> захотел следить за выходящими процессами тоже, не только за "серверами" -> понадобилось что-то типа эрланговского monitor -> (куча сломанных/изменённых типов) -> понадобилось сообщение процессам типа `Exited of что-то and process_exit_status -> понадобилась обработка сообщения другими, уже написанными процессами-серверами, причём кое-где даже сознательная, например в "диспетчере", который по ключу и соответствиям "ключ => процесс" определяет, кому отправить сообщение -> понадобилось вычёркивать процессы, чей ключ ничему более не соответствует -> понадобилось идентифицировать процессы -> понадобился pid. Вот так. Статическая типизация заставила меня ввести пиды, хочу я того или не хочу.
Предупреждение: вопрос глупый. Слабонервным не читать.

Мы с коллегой проектируем протокол общения двух программ. Общение состоит в том, что одна программа пишет в stdin/пайп/сокет для другой программы сообщение, являющееся валидным json (в строгом смысле слова -- либо массив, либо объект, то есть, self-delimited), другая программа читает, обрабатывает и отсылает ответ обратно, тоже json.
Запросов и ответов может быть много в одном потоке, они идут последовательно, на каждый запрос один ответ. И есть варианты, как это всё писать в один сплошной поток байтов.

1. Писать как есть, а парсер json'а разберётся, где заканчивается массив-объект (тупым подсчётом скобочек, исключая содержимое строк, например; либо средствами json-парсера),
2. Генерировать json так, чтобы он не содержал пустых строк (последовательности байтов 0x0A 0x0A), писать его в поток и разделять разные сообщения пустой строкой,
3. Писать сначала длину сообщения в байтах в десятичном представлении, затем перевод строки, затем само сообщение, содержащее ровно указанное количество байт.
4. Взять протокол наподобие http, имеющий возможность как слать сообщения с указанной длиной, так и сообщения в чанках, так и сообщения "до закрытия канала".

(соответственно, конец общения различать в соответствующих случаях так: 1. просто закрытый на отсылку поток (eof), 2. eof либо пустая строка вместо json, 3. eof либо сообщение длиной 0, 4. закрытие канала по канонам rfc2616.)

У нас возникли разногласия о том, как же это сделать, и я решил узнать общественное мнение.
Какой бы формат выбрали вы?

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

MapM

Apr. 18th, 2011 11:20 am
Abstract:
В данной статье я расскажу вам про отображающие функции вида map, включающие в себя сайд-эффекты. Тем, кому известен хаскель, эти функции известны как mapM и подобные.
Далее, будет показано, что хаскель, будучи самым распространённым языком из тех, где используются монады (ну, кроме C#/linq и Scala), является непрактичным из-за отсутствия сайд-эффектов. Раньше мне без сайд-эффектов было всего лишь просто неудобно использовать хаскель (требовалось городить лишний код), теперь же я понимаю, что есть некоторые вещи, где с чистотой не получится клёво использовать монады в одном из их применений.
Также будет показано, что тайпклассы -- это не гибко, потому что у одного тайпкласса и у одной функции (например, "функция sequence в монаде IO") может быть только одна реализация, и будет показано, где именно это не гибко.

Read more... )

Кроме того, видел сегодня клёвую статью Modules Matter Most. Она тут упомянута потому, что в ней тоже необоснованно гонят на хаскель, но сама статья хорошая и правильная.
Page generated Apr. 25th, 2017 10:13 pm
Powered by Dreamwidth Studios