и именно в ЯП со статической типизацией оно может случиться от любого неаккуратного обращения с памятью, и приводит к чему угодно, вплоть до выполнения случайного кода
Кстати. Вот пример того как на Shapeless решена задача о башнях Ханое. Что такого? — Скажете вы. А вот что — задача решается пока программа компилируется. Те. Scala компилятор решает ее за вас до того как вы запускаете эту программу!
Добавлю свои пять копеек. 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.
В основном, пользователи 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?
Мой скромный совет по именованию методов: 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)
По поводу «парсинга PHP кода» и генерации C++ кода. Не забывайте, что С++ язык со статической типизацией а PHP — нет. И трансляция динамического языка в статический вообще говоря проблема неразрешимая в общем смысле. Приходится применять кучу эвристик чтобы сократить количество типов void* в генерируемом коде. И Facebook и MathWorks делали нечто подобное и насколько мне известно, поле это почти не паханное — серебряной пули нет.
Так вот. Теперь представьте ОПП во всей его красе (sub-type полиморфизм как минимум) и все становится еще печальнее.
C++, как и любой другой язык программирования не более чем инструмент. Я не говорю, что его вообще не надо изучать. Изучение конкретных инструментов должно протекать в контексте решения конкретных задач. Например: учим ИИ, пишет лабораторные на С++ (или любом другом языке). Для этого хватит и базового владения языком. Остальное (как и другие инструменты) можно изучить уже в рабочей среде и по мере необходимости. Кажется это называется «опыт».
— Очень много опитизаций было сделано Тревисом в Circe
— В Finch как минимум две вещи помогли сократить разрыв: TooFastString и быстрые ридеры
Но, на удивление, этот тест не использует ни того ни другого. В любом случае оч крутой результат!
Вам 70ые звонили, просили книгу K&R вернуть.
Добавлю свои пять копеек. 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.
Отзыв одного из инженеров Globo.com:
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)Браво!
Так вот. Теперь представьте ОПП во всей его красе (sub-type полиморфизм как минимум) и все становится еще печальнее.
У нас в Новосибирске тоже есть Scala тусовка: www.meetup.com/ScalaNsk/. Успели провести 5 встреч: 40-50 человек участников в среднем.