Как решаете кроссплатформенные ограничения? Например, на линуксе создали файл с двоеточиями и звёзодчками в имени, что получится, если такой файл синхронизировать на Windows? И наоборот, если в Windows создать файл с именем в 250 русских символов, что получится на линуксе (у Ext4 ограничение в 255 байт, русские буквы занимают в UTF-8 по два байта, так что не влезет)?
>Но ведь оно для описания действий прекрасно подходить, разве нет?
Возможно, я лишь сказал, что не встречал его в таком значении.
>серфинг в Vim больше сводится к другой области управления (более мелкой или более специфичной)
>микросерфинг и макросерфинг по проекту
Непонятно, что же это такое. Открытие разных файлов и переход между ними? По-моему, это не так полезно, как семантическая навигация.
>О каких средствах идет речь?
Рефакторинг и Quick Fix (автоматическая генерация кода и исправление типичных ошибок), в основном, иногда анализ ресурсов на предмет соответствия коду, как в Android Studio проверка соответствия типа view из XML типу в коде и в Eclipse проверка наличия определения контрола в ui.xml, если он определён в аннотации @UiField (это для UiBinder из GWT). Автоматический рефакторинг позволяет не беспокоиться, что где-то что-то не исправилось как ожидалось, либо изменилось что-то, что не должно было. Возможно, он не идеален и тоже может накосячить, но я с таким пока не сталкивался.
Впервые встречаю это слово в таком значении. В эклипсе для навигации эффективнее использовать и мышь, и клавиатуру. Чаще всего мне требуется найти вызов метода по проекту и перейти к определению. Как опять же писалось тут, сомнительно, что Vim сможет определить правильную перегрузку функции или выбрать правильный метод для объекта, если есть несколько одинаково названных методов в разных классах (например, run() или start()). Когда происходит вызов такого метода, нужно учитывать тип объекта, для которого он вызывается, чтобы найти определение. Для определения типа нужно как минимум распарсить код и найти определение переменной, иногда вывести её тип (как в случае с ключевым словом auto в C++), иногда отрезолвить цепочку typedef'ов. Eclipse справляется с этим без проблем, а что делать в Vim? И это я ещё не трогаю рефакторинг, без которого в большом проекте будет нелегко.
Вопрос в том, так ли важен быстрый набор текста, если отсутствуют средства удобного и надёжного контроля кода? Я понимаю, что вряд ли смогу вам что-то доказать, но может, хоть заставлю задуматься.
Я уже писал здесь, что использую Vim постоянно для задач, которые в нём выполняются лучше всего. Линуксом пользуюсь чуть более восьми лет, Vim'ом примерно столько же. Зачем вы переходите на личности? Мне по-прежнему неочевидна связь сёрфинга и редактора текста. В Emacs есть встроенный браузер, но он, очевидно, не подходит для современных сайтов, ориентированных под Webkit/ES5/Мышь/Тач. Для Vim я ничего такого не видел. Если вы намекаете на Vimperator и Vimium (для Chrome), то они тоже являются лишь дополнениями, но никак не связаны с редактированием текста.
Вот хотелось бы посмотреть на процесс. Не исключено, что я просто тугодум и не умею писать простынями, а вместо этого больше думаю, чем печатаю. Поэтому и скорость набора не является для меня критичной, и поэтому интересно увидеть, как работают другие. Видел стрим на twitch, где разработчик Crea исправлял баг, там собственно ввода было минимум, больше навигации по коду.
У меня Debian. Возможно, реализация встроенного в IDEA SSH неполна, сервер использует нестандартный порт, авторизация идёт по ключу. Просто в эклипсе как-то сразу заработало, поэтому и обратил внимание.
Ух, понятно, довольно бесполезно получается. Такие вот моменты выбивают из «потока» намного сильнее, чем, якобы, перенос руки на мышку и обратно. grep, кстати, хорошо помогает, когда берёшь чужой проект (на любом языке) и хочешь быстро найти нужное место, чтобы исправить/разобраться/найти отправную точку. Это оказывается быстрее, чем ждать полной индексации в IDE, да и поиск по произвольному тексту там обычно не очень удобен.
Справедливости ради, всё это есть и в Eclipse. Пользуюсь сейчас Android Studio, сделанной на базе IDEA, но многое всё же неудобно. Например, работа с VCS, по крайней мере, то, что видно на панелях и в меню. В эклипсе можно формировать частичные коммиты, внося изменения в индекс по кусочкам, а IDEA предлагает проставлять галки сразу для всего файла целиком. Понятно, что полагается сделать фичу, закоммитить, потом делать следующую, но на практике чаще выходит каша, которую хочется разделить на стадии коммитов. И из коробки git push по ssh не работает, надо переключаться на системный ssh, а дополнение и подсветка CSS не работают вовсе (только за деньги, наверно). Ну это так, брюзжание, скорее всего, я просто не разобрался.
Что важно, так это производительность — у обоих IDE она примерно одинаковая. В смысле, тормозят и задумываются время от времени, хотя обычно в этом упрекают исключительно Eclipse. Возможно, в платной версии всё намного лучше. Тем не менее, любые тормоза можно легко простить, ведь тормозит оно с благой целью (аргументы уже высказаны), и сэкономленное время и нервы, а также снижение численности ошибок окупают это с лихвой.
можно переходить от вызова функции к её определению
А вы на каком языке пишете? Я ниже привёл пример с перегрузкой оператора в C++, да и любая перегруженная функция (т.е. группа функций с одним названием, но разными сигнатурами) тоже подойдёт. Как Vim выберет правильную в этой ситуации?
В том и проблема, что Vim не масштабируется. На малых файлах это прикольное и «эффективное» (а скорее, «эффектное») копошение уровня «смотрите, как я умею!», на чём-то более крупном и сложном уже борьба с инструментом. Фанатизм и привычка использовать один инструмент мешают более конкретно очерчивать круг применимости, и это вполне естественно для большинства, ибо лень переучиваться или просто пробовать что-то новое, где не хватает чего-то привычного (а любые плюсы уже не ощущаются после этого).
Попробовать и освоить Vim однозначно стоит, особенно, если вы используете Linux. Для удалённого редактирования или локального в tmux/screen/tty, например, ничего лучше не найти. Просто это не замена для IDE, а совершенно отдельный параллельный инструмент для других задач, слабо связанных с программированием.
Это больше похоже на хвост, виляющий собакой. Может, логичнее в существующие мощные IDE, которые синтаксически и семантически «понимают», что в них пишут программный код, а не набор букв и слов, так вот, в эти IDE прикрутить Vim-like управление? Собственно, это уже сделано, о чём и сам автор статьи упоминает. Всё ж как ни обвешивай текстовый редактор плагинами, он от этого IDE не станет. Будет просто редактор с кучей костылей, потому что он работает не с языком, а с текстом, не с проектом, а с набором файлов.
К слову, буквально на днях обнаружил, что Eclipse CDT понимает даже перегруженные операторы, и по F3 позволяет перейти к их определению. Учитывая, что выбор правильной реализации оператора жёстко привязан к типам аргументов, я не представляю, как эту задачу можно выполнить в Vim. Ну вот есть конструкция вида cout << someObj << endl;. В эклипсе я встаю курсором на << и жму F3, попадаю на реализацию этого оператора, могу прочитать и понять, что там не так. Этот оператор может быть реализован в стандартной библиотеке (за пределами проекта вообще), в сторонней библиотеке, в моём коде; может быть внутри класса, может быть свободной функцией. Выглядит он везде одинаково, <<, как же найти искомый? QtCreator, например, не умеет (пока) находить такие определения. В результате, перегрузки для Qt'шных типов найти либо сложно, либо нереально. А ведь возможность быстрой навигации по коду — это именно то, к чему апеллирует автор. И для программиста Vim именно эту возможность не предоставляет. Он даёт лишь быструю навигацию по тексту, которая довольно бесполезна, ведь программа состоит из множества файлов, классов, функций и библиотек, которые Vim не понимает.
Я пишу все эти аргументы уже не первый раз, потому что в каждой статье от Vim-евангелистов пишется про рай для программистов, тогда как по факту это является неслабым таким преувеличением, мягко говоря. Стоило бы говорить о редактировании небольших текстов типа конфигов или ридмишек, тогда совершенно с этим соглашусь, ибо везде у меня Vim стоит редактором по умолчанию, и это первое, что я ставлю на минимальную систему. Пробовал и Emacs около года (даже как Jabber-клиент!), но в итоге надоело аккорды наигрывать. А фанатичность вообще до добра не доводит.
Первый пример неубедительный. Например, чтобы в Eclipse CDT сгенерировать реализацию методов (в любом количестве) по заголовочному файлу, мне достаточно нажать Alt+Shift+S, Up (Implement Method...), Enter, Enter. При этом, в примере не раскрыта тема C++, где простого копирования мало, надо ещё дописать название класса.
Второй пример также проигрывает эклипсу, выделяем код, который хотим извлечь в переменную, нажимаем Alt+Shift+L, пишем название новой переменной. Тип выводится автоматически, название переменной подставляется в место извлечения. Аналогично можно вытащить фрагмент кода в функцию с автовыводом типов входных параметров и результата.
бывают такие моменты, когда после 30 секундного "взрывного" редактирования вы как-будто "просыпаетесь"
Со стороны это больше похоже на имитацию бурной деятельности, ничего не понятно, грохот клавиш, текст скачет туда-сюда, и вообще всё выглядит круто и по-хакерски. Может, в каких-то случаях именно такое и нужно. В своей практике не встречал.
Мне кажется, именно в примерах со статически типизированными языками Vim наиболее наглядно проигрывает хорошим IDE, а для чего-то типа Python/JS/HTML/CSS или конфигов, конечно, он подходит лучше. С развеиванием разоблачения №5 я лично не согласен: программирование происходит в голове, а написание кода — это лишь небольшая промежуточная стадия между придумыванием кода и запуском его. Улучшать стоит то, что занимает основную часть времени. Если удалось ускорить какую-то операцию в 10 раз, это здорово! Но если она выполняется, скажем, раз в час и занимала 100 мс, а теперь 10 мс, тогда как непосредственно алгоритм отрабатывает по полминуты… это больше похоже на преждевременную оптимизацию ради оптимизации. Вот к скорости набора кода у меня такое же отношение.
лучше бы эта конкуренция существовала в рамках групп, развивающих существующий язык
Увы, языки — штука прикладная, без обширной аудитории не получится сделать хороший язык. В наших силах разве что, как и описано в статье, не покупаться на блестяшки и ждать, пока новый язык повзрослеет, обрастёт инструментами и библиотеками, чтобы можно было перейти или просто попробовать без негативных первых впечатлений. Было бы здорово иметь универсальный фреймворк для быстрого создания IDE под любой язык со всеми фичами уровня Eclipse для Java. Конечно, в самом Eclipse есть что-то для этого, но судя по состоянию поддержки даже JVM-языков (Kotlin, Ceylon), не так-то легко его использовать эффективно. А писать на новом языке без IDE — это совсем не как самурай с мечом, только без меча. Это боль, страдания и беготня в документацию на каждый чих.
внятная билд-система со встроенным пакетным менеджером
Это да, требование времени. В том же C++17 планируются модули, которые дадут возможность создавать пакеты, как я читал. Очень хочется Maven под C++, но пока самым вменяемым остаётся CMake, хотя бы как билд-система. Статическая линковка по-прежнему сложна и обычно требует пересборки библиотек (в моём случае Qt, OpenSSL, libtorrent), а без неё даже между Ubuntu 14.04 и Debian Stretch совместимости не добиться — старый OpenSSL в 14.04.
почти в каждом крупном проекте с нуля создают стандартную библиотеку — это нормально вообще?
Ненормально, но надо смотреть мотивацию. Вообще, хорошо, когда можно сделать даже стандартную библиотеку самостоятельно, т.е. язык это не запрещает и позволяет некоторую гибкость. В UE4 зачем-то сделаны даже свои смартпоинтеры, может, для совместимости с C++98? Большие проекты обычно подразумевают обширное покрытие конфигураций и платформ, так что если по каким-то причинам STL не может такого предоставить, приходится велосипедить.
По-моему, очень хорошо, что появляются новые языки, типа тех же Rust и Go. Это здоровая конкуренция, которая подстёгивает крупных и старых игроков (Java, C++), заставляя их шевелиться. В Java уже ввели лямбды, скоро будет автовывод типов. Надеюсь, async/await тоже не за горами.
В C++17 могут появиться концепты, ограничения и требования для шаблонов, выглядит как невероятно крутая фича, позволяющая описывать требования к типу на метаязыке вместо наследования или интерфейсов. Я не знаю Haskell, может, там есть что-то такое, но из других более-менее мейнстримных языков такого не видел нигде. Ограничения на generics накладываются обычно через иерархию типов (extends/super в Java), но не как тут предлагается, в виде вычисления произвольного выражения.
Интерфейсы в Go считаются, вроде как, самым прогрессивным путём для достижения слабой связанности, позволяя привлекать сторонние подходящие классы, которые не связаны с интерфейсом, кроме как по совпадению сигнатур функций. Концепты же позволяют применять такие классы, которые просто удовлетворяют некоей логике поведения! Как пример: http://en.cppreference.com/w/cpp/concept/SequenceContainer — выразить эту логику с помощью интерфейсов или дженериков, похоже, достаточно сложно.
Стоит отметить, что кошельки с Simple Payment Verification не на 100% надёжны, т.к. такой кошелёк не проверяет правильность всех транзакций в получаемых блоках (и вообще не видит их), сверяет только заголовки блоков, считает надёжность транзакции исключительно по числу блоков, которые были созданы после неё (а не путём проверки входов предыдущих транзакций вплоть до исходного создания монет), в общем, уязвим к направленной подделке блокчейна. Технически это непросто, но проще, чем захват 50% мощностей всей сети. Так что для очень больших транзакций рекомендуется использовать полный клиент, который даёт почти стопроцентную гарантию.
Да, я в курсе истории Литреса. Но если они такие наглые и ничего не платят авторам, почему авторы всё же к ним идут? Или они не идут, а их книги до сих пор просто так «за здорово живёшь» выставляют на продажу? Сомнительно как-то.
Кроме них есть ещё Google Books, как там с роялти? Вроде, западная компания должна быть более честна в вопросах авторских прав. Бумажные книги не покупаю, не хочу захламлять квартиру, т.к. не испытываю никакого трепета по отношению к носителю. Важна лишь информация.
Он и на русскоязычной не специализируется, к сожалению. А модель и правда неплоха (похожа на Humble Bundle, только без бандла?), хотя вот наугад в Fiction ткнул книгу https://leanpub.com/thebeastsoftheearth, и там «This book is 98% complete», «UPDATED OVER 2 YEARS AGO». Как-то не воодушевляюще выглядит.
Возможно, я лишь сказал, что не встречал его в таком значении.
>серфинг в Vim больше сводится к другой области управления (более мелкой или более специфичной)
>микросерфинг и макросерфинг по проекту
Непонятно, что же это такое. Открытие разных файлов и переход между ними? По-моему, это не так полезно, как семантическая навигация.
>О каких средствах идет речь?
Рефакторинг и Quick Fix (автоматическая генерация кода и исправление типичных ошибок), в основном, иногда анализ ресурсов на предмет соответствия коду, как в Android Studio проверка соответствия типа view из XML типу в коде и в Eclipse проверка наличия определения контрола в ui.xml, если он определён в аннотации @UiField (это для UiBinder из GWT). Автоматический рефакторинг позволяет не беспокоиться, что где-то что-то не исправилось как ожидалось, либо изменилось что-то, что не должно было. Возможно, он не идеален и тоже может накосячить, но я с таким пока не сталкивался.
Вопрос в том, так ли важен быстрый набор текста, если отсутствуют средства удобного и надёжного контроля кода? Я понимаю, что вряд ли смогу вам что-то доказать, но может, хоть заставлю задуматься.
Это надо считать только при наборе кода. Между набором непосредственно кода программы много времени уходит на браузер и прокрастинацию, к сожалению.
Так вот интересно, какой текст в больших объёмах набирают поклонники Vim. Романы пишут, что ли? Мне правда интересно.
У меня Debian. Возможно, реализация встроенного в IDEA SSH неполна, сервер использует нестандартный порт, авторизация идёт по ключу. Просто в эклипсе как-то сразу заработало, поэтому и обратил внимание.
Ух, понятно, довольно бесполезно получается. Такие вот моменты выбивают из «потока» намного сильнее, чем, якобы, перенос руки на мышку и обратно. grep, кстати, хорошо помогает, когда берёшь чужой проект (на любом языке) и хочешь быстро найти нужное место, чтобы исправить/разобраться/найти отправную точку. Это оказывается быстрее, чем ждать полной индексации в IDE, да и поиск по произвольному тексту там обычно не очень удобен.
Справедливости ради, всё это есть и в Eclipse. Пользуюсь сейчас Android Studio, сделанной на базе IDEA, но многое всё же неудобно. Например, работа с VCS, по крайней мере, то, что видно на панелях и в меню. В эклипсе можно формировать частичные коммиты, внося изменения в индекс по кусочкам, а IDEA предлагает проставлять галки сразу для всего файла целиком. Понятно, что полагается сделать фичу, закоммитить, потом делать следующую, но на практике чаще выходит каша, которую хочется разделить на стадии коммитов. И из коробки git push по ssh не работает, надо переключаться на системный ssh, а дополнение и подсветка CSS не работают вовсе (только за деньги, наверно). Ну это так, брюзжание, скорее всего, я просто не разобрался.
Что важно, так это производительность — у обоих IDE она примерно одинаковая. В смысле, тормозят и задумываются время от времени, хотя обычно в этом упрекают исключительно Eclipse. Возможно, в платной версии всё намного лучше. Тем не менее, любые тормоза можно легко простить, ведь тормозит оно с благой целью (аргументы уже высказаны), и сэкономленное время и нервы, а также снижение численности ошибок окупают это с лихвой.
А вы на каком языке пишете? Я ниже привёл пример с перегрузкой оператора в C++, да и любая перегруженная функция (т.е. группа функций с одним названием, но разными сигнатурами) тоже подойдёт. Как Vim выберет правильную в этой ситуации?
В том и проблема, что Vim не масштабируется. На малых файлах это прикольное и «эффективное» (а скорее, «эффектное») копошение уровня «смотрите, как я умею!», на чём-то более крупном и сложном уже борьба с инструментом. Фанатизм и привычка использовать один инструмент мешают более конкретно очерчивать круг применимости, и это вполне естественно для большинства, ибо лень переучиваться или просто пробовать что-то новое, где не хватает чего-то привычного (а любые плюсы уже не ощущаются после этого).
Попробовать и освоить Vim однозначно стоит, особенно, если вы используете Linux. Для удалённого редактирования или локального в tmux/screen/tty, например, ничего лучше не найти. Просто это не замена для IDE, а совершенно отдельный параллельный инструмент для других задач, слабо связанных с программированием.
Это больше похоже на хвост, виляющий собакой. Может, логичнее в существующие мощные IDE, которые синтаксически и семантически «понимают», что в них пишут программный код, а не набор букв и слов, так вот, в эти IDE прикрутить Vim-like управление? Собственно, это уже сделано, о чём и сам автор статьи упоминает. Всё ж как ни обвешивай текстовый редактор плагинами, он от этого IDE не станет. Будет просто редактор с кучей костылей, потому что он работает не с языком, а с текстом, не с проектом, а с набором файлов.
К слову, буквально на днях обнаружил, что Eclipse CDT понимает даже перегруженные операторы, и по F3 позволяет перейти к их определению. Учитывая, что выбор правильной реализации оператора жёстко привязан к типам аргументов, я не представляю, как эту задачу можно выполнить в Vim. Ну вот есть конструкция вида
cout << someObj << endl;. В эклипсе я встаю курсором на<<и жму F3, попадаю на реализацию этого оператора, могу прочитать и понять, что там не так. Этот оператор может быть реализован в стандартной библиотеке (за пределами проекта вообще), в сторонней библиотеке, в моём коде; может быть внутри класса, может быть свободной функцией. Выглядит он везде одинаково,<<, как же найти искомый? QtCreator, например, не умеет (пока) находить такие определения. В результате, перегрузки для Qt'шных типов найти либо сложно, либо нереально. А ведь возможность быстрой навигации по коду — это именно то, к чему апеллирует автор. И для программиста Vim именно эту возможность не предоставляет. Он даёт лишь быструю навигацию по тексту, которая довольно бесполезна, ведь программа состоит из множества файлов, классов, функций и библиотек, которые Vim не понимает.Я пишу все эти аргументы уже не первый раз, потому что в каждой статье от Vim-евангелистов пишется про рай для программистов, тогда как по факту это является неслабым таким преувеличением, мягко говоря. Стоило бы говорить о редактировании небольших текстов типа конфигов или ридмишек, тогда совершенно с этим соглашусь, ибо везде у меня Vim стоит редактором по умолчанию, и это первое, что я ставлю на минимальную систему. Пробовал и Emacs около года (даже как Jabber-клиент!), но в итоге надоело аккорды наигрывать. А фанатичность вообще до добра не доводит.
Первый пример неубедительный. Например, чтобы в Eclipse CDT сгенерировать реализацию методов (в любом количестве) по заголовочному файлу, мне достаточно нажать Alt+Shift+S, Up (Implement Method...), Enter, Enter. При этом, в примере не раскрыта тема C++, где простого копирования мало, надо ещё дописать название класса.
Второй пример также проигрывает эклипсу, выделяем код, который хотим извлечь в переменную, нажимаем Alt+Shift+L, пишем название новой переменной. Тип выводится автоматически, название переменной подставляется в место извлечения. Аналогично можно вытащить фрагмент кода в функцию с автовыводом типов входных параметров и результата.
Со стороны это больше похоже на имитацию бурной деятельности, ничего не понятно, грохот клавиш, текст скачет туда-сюда, и вообще всё выглядит круто и по-хакерски. Может, в каких-то случаях именно такое и нужно. В своей практике не встречал.
Мне кажется, именно в примерах со статически типизированными языками Vim наиболее наглядно проигрывает хорошим IDE, а для чего-то типа Python/JS/HTML/CSS или конфигов, конечно, он подходит лучше. С развеиванием разоблачения №5 я лично не согласен: программирование происходит в голове, а написание кода — это лишь небольшая промежуточная стадия между придумыванием кода и запуском его. Улучшать стоит то, что занимает основную часть времени. Если удалось ускорить какую-то операцию в 10 раз, это здорово! Но если она выполняется, скажем, раз в час и занимала 100 мс, а теперь 10 мс, тогда как непосредственно алгоритм отрабатывает по полминуты… это больше похоже на преждевременную оптимизацию ради оптимизации. Вот к скорости набора кода у меня такое же отношение.
Увы, языки — штука прикладная, без обширной аудитории не получится сделать хороший язык. В наших силах разве что, как и описано в статье, не покупаться на блестяшки и ждать, пока новый язык повзрослеет, обрастёт инструментами и библиотеками, чтобы можно было перейти или просто попробовать без негативных первых впечатлений. Было бы здорово иметь универсальный фреймворк для быстрого создания IDE под любой язык со всеми фичами уровня Eclipse для Java. Конечно, в самом Eclipse есть что-то для этого, но судя по состоянию поддержки даже JVM-языков (Kotlin, Ceylon), не так-то легко его использовать эффективно. А писать на новом языке без IDE — это совсем не как самурай с мечом, только без меча. Это боль, страдания и беготня в документацию на каждый чих.
Это да, требование времени. В том же C++17 планируются модули, которые дадут возможность создавать пакеты, как я читал. Очень хочется Maven под C++, но пока самым вменяемым остаётся CMake, хотя бы как билд-система. Статическая линковка по-прежнему сложна и обычно требует пересборки библиотек (в моём случае Qt, OpenSSL, libtorrent), а без неё даже между Ubuntu 14.04 и Debian Stretch совместимости не добиться — старый OpenSSL в 14.04.
Ненормально, но надо смотреть мотивацию. Вообще, хорошо, когда можно сделать даже стандартную библиотеку самостоятельно, т.е. язык это не запрещает и позволяет некоторую гибкость. В UE4 зачем-то сделаны даже свои смартпоинтеры, может, для совместимости с C++98? Большие проекты обычно подразумевают обширное покрытие конфигураций и платформ, так что если по каким-то причинам STL не может такого предоставить, приходится велосипедить.
В C++17 могут появиться концепты, ограничения и требования для шаблонов, выглядит как невероятно крутая фича, позволяющая описывать требования к типу на метаязыке вместо наследования или интерфейсов. Я не знаю Haskell, может, там есть что-то такое, но из других более-менее мейнстримных языков такого не видел нигде. Ограничения на generics накладываются обычно через иерархию типов (extends/super в Java), но не как тут предлагается, в виде вычисления произвольного выражения.
Интерфейсы в Go считаются, вроде как, самым прогрессивным путём для достижения слабой связанности, позволяя привлекать сторонние подходящие классы, которые не связаны с интерфейсом, кроме как по совпадению сигнатур функций. Концепты же позволяют применять такие классы, которые просто удовлетворяют некоей логике поведения! Как пример: http://en.cppreference.com/w/cpp/concept/SequenceContainer — выразить эту логику с помощью интерфейсов или дженериков, похоже, достаточно сложно.
Кроме них есть ещё Google Books, как там с роялти? Вроде, западная компания должна быть более честна в вопросах авторских прав. Бумажные книги не покупаю, не хочу захламлять квартиру, т.к. не испытываю никакого трепета по отношению к носителю. Важна лишь информация.