spiff
0
Я бы сказал 5-7% по последним данным:

— Очень много опитизаций было сделано Тревисом в Circe
— В Finch как минимум две вещи помогли сократить разрыв: TooFastString и быстрые ридеры

Но, на удивление, этот тест не использует ни того ни другого. В любом случае оч крутой результат!
spiff
+9
и именно в ЯП со статической типизацией оно может случиться от любого неаккуратного обращения с памятью, и приводит к чему угодно, вплоть до выполнения случайного кода

Вам 70ые звонили, просили книгу K&R вернуть.
spiff
+5
Кстати. Вот пример того как на Shapeless решена задача о башнях Ханое. Что такого? — Скажете вы. А вот что — задача решается пока программа компилируется. Те. Scala компилятор решает ее за вас до того как вы запускаете эту программу!
spiff
+4
Отличный ответ!

Добавлю свои пять копеек. Shapeless — это скорее библиотека не для конечного пользователя а для разработчиков библиотек. Shapeless помогает атворам библиотек избавиться от boilerplate кода и макросов при решении типичных задач. Задач №1, с которой успешно справляется HList: у вас есть два типа A и B как их собрать в месте во что-то с чем вы можете потом работать. Можно собрать из них Scala tuple (A, B) и этого бывает достаточно в большинстве случаев, но когда речь идет о трех, четырех, и тд типов — появляются nested tuples (A, (B, (C, D))) с которыми уже не очень удобно работать как автору библиотек так и ее пользователю. Эта проблема частично решается с помощью некоторго количества boilerplate кода который нужно поддерживать и тестировать. Идея Shapeless (HList в честности) — это как раз дать разработчикам библиотек единый инструмент для решения этой проблемы. Т.е. boilerplate код о которым мы говорили ранее — переносится в Shapeless а значит нам его уже поддерживать не надо.

Еще одна очень интересная особенность Shapeless. При правильном ее использовании автором библиотеки, ее пользователи никогда не догадаются что там где-то в недрах привычного API трудится HList. Примерами таких удачных внедрений я могу назвать scodec, Spray, parboiled2.

На последок, есть отличная презентация от Трэвиса Брауна (#1 Shapeless эксперт на SO) о том как и почему Shapeless был внедрен в Finch.
spiff
0
Можно добавить в список ScalaCheck.
spiff
0
Спасибо! Буду стараться :)
spiff
+1
В основном, пользователи Finch это бывшие пользователи Finatra. Люди жалуются на то, что Finatra почти полностью скрывает Finagle API (даже фильтры), тем самым теряя очень много функционала. Finch — ничего не скрывает а лишь добавляет несколько абстракций поверх finagle-http. И благодаря тому, что слой получается очень тонкий и неизменяемый — производительность Finch очень хороша:

Отзыв одного из инженеров Globo.com:
And speaking of where we are using Finch, we are currently rebuilding our users platform on top of Finagle and Finch. We started with Finatra, but after doing several benchmarks, we decided to stop using it, and moved to Finagle, until I found Finch, which is quite straightforward. It responds 16X faster than Finatra on a simple /healthcheck endpoint, responding “OK”. Crazy isn’t it?
spiff
+2
Еще проще: пост в хабе Scala :)
spiff
+4
Мой скромный совет по именованию методов:
GET http://api.code.re/snippets/{id} — получить сниппет
PUT http://api.code.re/snippets/{id} — обновить сниппет
DELETE http://api.code.re/snippets/{id} — удалить сниппет
GET http://api.code.re/snippets — все сниппеты
GET http://api.code.re/highlights — все схемы подсветки (или schemas)
spiff
0
Господа, но колбэки не компонуются! Это гребаный приговор.


Браво!
spiff
0
А как в этом рюкзаке с отделом под 17 дюймовый ноутбук чувствует себя MB Pro 13''?
spiff
+1
Я даже боюсь представить (в хорошем смысле) что будет со Scala к тому времени как выйдет Java 15.
spiff
+11
Как написал Erik Meijer у себя в твиттере:

Congrats to all my friends at #oracle. Functional programming is now officially mainstream,and my mission complete.


spiff
0
По поводу «парсинга PHP кода» и генерации C++ кода. Не забывайте, что С++ язык со статической типизацией а PHP — нет. И трансляция динамического языка в статический вообще говоря проблема неразрешимая в общем смысле. Приходится применять кучу эвристик чтобы сократить количество типов void* в генерируемом коде. И Facebook и MathWorks делали нечто подобное и насколько мне известно, поле это почти не паханное — серебряной пули нет.

Так вот. Теперь представьте ОПП во всей его красе (sub-type полиморфизм как минимум) и все становится еще печальнее.
spiff
+6
О. Тогда прошу прощения :) Деревня я — не слышал про Твитч, думал вы так Твиттер искаверкали.
spiff
–1
Твиттер работает на Scala стеке.
spiff
+2
Забавно обыгран логотип!

У нас в Новосибирске тоже есть Scala тусовка: www.meetup.com/ScalaNsk/. Успели провести 5 встреч: 40-50 человек участников в среднем.
spiff
0
C++, как и любой другой язык программирования не более чем инструмент. Я не говорю, что его вообще не надо изучать. Изучение конкретных инструментов должно протекать в контексте решения конкретных задач. Например: учим ИИ, пишет лабораторные на С++ (или любом другом языке). Для этого хватит и базового владения языком. Остальное (как и другие инструменты) можно изучить уже в рабочей среде и по мере необходимости. Кажется это называется «опыт».
spiff
+5
Если фундаментальное образование будет включать годовой курс по С++ то это, простите, финиш.
spiff
0
Вот например его легендарный PhD Guide.
spiff
+1
Я бы позвал Мета Майта для курса компиляторов/ФП. Давно читаю его блог и твиттер. Отличный пример современного ученого.
spiff
+3
Оставлю свои пять копеек по поводу того как нужно нанимать людей. Контора SlamData (специализируется на Scala и является работадателем очень известных Scala гуру таких как Daniel Spiewak) предлагает такой подход: вы присылаете pull-request в их флагманских продукт Precog и за это сразу-же получаете либо job-offer либо чек с оплатой потраченного времени.
spiff
0
Ну ваш пример слегка вычурный. Это действительно два разных инженера (Electrical Engineering и Машиностроение?). Эти ребята разве что на языке математики и физики будут договариваться. Мой поинт в том, что формально мы все люди из одной сферы и занимаемся одним и тем-же — «при помощи текстовых файлов говорим компьютерам что делать ».
spiff
+9
Я согласен с тем, что никакие тулы не отменяют необходимости думать головой и понимать, что именно ты делаешь. Я как человек из мира системного программирования (в данный момент разработка компиляторов) пишу как раз 10-20 строк в день и вполне обхожусь Vim, Makefile и grep. В этом плане я Джо поддерживаю. С другой стороны у меня есть Java OSS проект c которым без супер-соврменной IDE работать почти невозможно. Я конечно, знаю там каждую строку и даже могу на коленке (в Notepad) написать какой-нибудь патч, но я предпочитаю использовать Intellij IDEA для этого.

Мне в словах Джо вот, что приглянулось. Последний абзац. У нас действительно проблема. Мы все говорим на разных языках. Да, 40 лет назад любой программист понимал любого другого с полуслова. Но сейчас — у нас уже куча специализаций, кланов если хотите. Я не говорю, что это плохо. Это прогресс, скорее всего. Но я за то, чтобы хоть как-то сохранить связи и иметь в наличии язык на котором мы сможем говорить. И я зык этот дожен быть не тулом а чем-то более глобальным. Я глубоко надеюсь, что то что называется Computer Science и есть этот самый универсальный язык. И его нужно стараться сохранять и учить независимо от того в какой области вы работаете — веб или системного программирования.
spiff
0
Отличное решение!

Сколько времени ушло на него?
spiff
+1
Задача на backtracking. Из каждой позиции у коня восемь возможных ходов. Делам каждый из восьми ходов — если это было _безопасно_ идем дальше. Безопасно — значит (а) мы не ушли за пределы доски (б) мы тут еще не были.
Примерный скетч алгоритма за экспоненциальное время O(8^n)
void step(int x, int y) {
  if (safe(x, y)) {
    // красим ячейку
    fill(x, y);
    // шагаем дальше
    step(x + 1, y - 2);
    step(x + 2, y - 1);
    // и остальные шесть ходов
  }
}

void main() {
  clearTable();
  step(0, 0);
}

spiff
0
Хайзенебргу нельзя отказывать. Потому, что он "… the one who knocks".
spiff
+1
Не соглашусь. Может конечно у вас побольше опыта в получении приглашений на интервью. Мой опыт говорит мне — что это один из сложнейших этапов. Поэтому как это немалые затраты для компании — оплатить перелет и тому подобное.

ЗЫ: Был на он-сайт интервью в ARM (1 интервью + тестовое задание перед приглашением на сайт). Сейчас готовлюсь к он-сайт в одной компании из США (8 phone-screen интервью перед приглашением).
spiff
0
Интересно просто. Я сам бывший мотоциклист. Продал мотоцикл потом-что очень заморочено его держать, без гаража и с мотосезоном в три с половиной месяца. Хотя жалею немного.
spiff
0
Странно все это. Я тут немедни прошел несколько интервью. Даже не несколько — а сколько. Никто никогда не спрашивал меня о хобби. Все только и разговоров что о проектах и задачках на бумажках.

Неправильные конторы какие-то я выбираю. Мда.
spiff
0
Ну и какой? Сколько жрет? Сколько прет?
spiff
+1
Я попробую ответить. Для меня лично, это тоже больное место — эта терминология. В умных книжках, все эти моменты ненавязчиво опускаются (т.к. видимо являются чем-то сверхэлементарным для авторов, не требующим пояснений). Что для нас — перфекционистов — является большим испытанием. Я для себя решил разграничить эти вещи следующим образом:

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

Неизменяемость — свойство объекта/структуры запрещяющее его любые изменения. Понятно, что неизменяемая структура после модификации представляет собой копию предыдущей версии + конкретные изменения (например новый элемент). При этом, неизменяемые объекты всегда персистентны (т.е. версию которую мы когда-то создали мы не можем изменить/удалить). Такие структуры тоже есть в императивном мире, например java.lang.String (моя любимая коллекция). Неизменяемость — это ограничение функционального мира (т.е. отсутствие деструктивных апдейтов). Может ли неизменяемая структура быть построена на изменяемом внутреннем состоянии? Я думаю да. Есть такое понятие как локализация мутации. Отличный пример такой мутации Паша Павлов рассказывает в этом видео на примере очереди банкиров. Т.е. формально коллекция неизменяемая (по набору элементов), но во внтуренней структуре есть некоторые места, которые подвержены мутациям, т.е. нельзя сказать, что такие структуры всегда без сайд-эффектов.

ЧФСД — это класс структур без сайд-эффектов. Баста.
spiff
+3
Спасибо за фидбек!

По делу. Во-первых, не совсем понятно что имеется ввиду под «обычные персистентные структуры». Не секрет, что ЧФСД можно реализовать и в императивной среде (например на Java), но там они не очень популярны, потому как выглядят чужеродными. Другое дело функциональные языки, где мутации, как правило, физически не-возможны — тут и выбора то большого нет. Во-вторых, эта терминология очень скользкая дорожка. Часто говоря «персистентная структура (persistent)» подразумевают ЧФСД (purely functional) и на оборот. Более того, есть еще одно смежное определение «неизменяемая структура (immutable)», которое часто используется вместо двух предыдущих. Пример. Есть совершенно идентичная реализация чисто-функционального вектора (bit-mapped vector trie) в Scala и Сlosure. В Scala он называется "immutable.Vector", в Closure — "PersistentVector".
spiff
+1
Круто-круто. Я в 12 лет на мопеде Карпаты по лужам катался и шифер на костре взрывал.
spiff
+80
На фото малыш возмущен: «Как нет множественного наследования?!».
spiff
+4
Еще история про рекрутеров. Из твиттера Nathan Marz (автор Storm):

Just got a recruiter email asking for 7+ years of Clojure experience. Too bad Clojure has only been available for 6 years.
spiff
+15
Мне кажется, тут даже Brainfuck курит.
spiff
+2
Согласен! Читал CLRS (Кормена) в универе. Сейчас взялся за Скиену. Книга затягивает как роман. Читать ее на английском сложнее чем CLRS, но дает она намного больше. Она более практическая что-ли, с глубокими фундаментальными основами. Например, в Кормене много станиц уделяется доказательствам алгоритмов (что, вообще говоря непонятно зачем нужно). В Скиене очень много страниц уделяется байкам «из жизни» про применение алгоритмов и структур а также, вопросам и пузырям «Остановись и подумай!», которые помогают очень глубоко понять материал. Там конечно очень многое опускается. Я бы сказал, что Скиену нужно читать после Кормена (нужен бекграунд). В этом плане книга выглядит сложнее. Но как только начинаешь понимать стиль письма автора и те действительно темные углы и комнаты в которые он заглядывает (туда куда ни Кормен ни Вирт не заглядывали) становится жутко интересно.

Не на правах рекламы.
spiff
+2
Лучший отдых от умственного труда – это спорт (нет, очкарик, не шахматы!). Займись бегом, боксом, качай тяжести – двигайся!


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

Можно сравнить это с написанием программы, если хотите. Ты составляешь программу тренировок (дизайн будущей программы = основные алгоритмы + иерархия классов). Ты занимаешься день за днем (программируешь будущую программу). И потом ты наслаждаешься результатом (компилируешь и запускаешь программу).

Занимайтесь спортом, коллеги!
spiff
+2
Тема очень важная. Спасибо за статью и особенно за ссылки.