М>дело не в языке, конечно. но кому-то приходится делать грязную работу в стиле "принять запрос", "дернуть базу", "мяукнуть в ответ".
Это 70% моей работы

M>если архитектурно база инкапсулирована в библиотеку на руби и ее внутреннее представление может меняться
Это как секс у подростков — чаще говорят, чем делают. Вот кто в здравом уме будет перепиливать всерьёз структуру боевой базы?

M>то прямые SQL-запросы, очевидно, делать смерти подобно и потому приходится юзать руби, который популярен в стартапах, которые в какой-то момент выходят на рынок и начинают расти. и кого они нанимают в первую очередь? правильно — рубистов, а их на всех не хватает (учитывая относительную молодость языка).
О, да. Я внимательно изучил модели в руби. Сделать там обычный для меня запрос

SELECT Q.CYCLE_ID AS ID, C.KEY AS TICKER, C.NAME AS NAME, Q.PRICE AS QUOTE, Q.TRADE_LIMIT AS TRADE_LIMIT, Q.NPCS_BUY AS NPCS_BUY FROM STOCK_COMPANY C LEFT OUTER JOIN STOCK_QUOTE Q ON (C.KEY = Q.COMPANY_KEY AND Q.CYCLE_ID IN (SELECT MAX(ID) FROM STOCK_CYCLE))

превращается в головную боль.

D>> которые я встречал. Остальное есть в stackoverflow
М>а когда вы используете регулярные выражения вы отдаете себе отчет, что библиотека re2 рвет стандартную re как грелка тузика?
Все те полтора раза, когда мне надо было использовать регекспы, мне было искренне пофиг на производительность, ибо это был масс-парсинг сорцов.

M>и что если нужна производительность, то ее следует искать совсем в другом месте. а если нам нужен нечеткий поиск, то это тема отдельного разговора. а если еще и семантику хочется прикрутить, то нужно знать в каком направлении рыть, иначе вообще ничего найти невозможно. уже не говоря о таких мелочах, что некоторые вещи дешевле купить в железе, чем пытаться переоткрыть колесо и построить паровой двигатель на его основе, когда нормальные люди уже летать начали.
Это правда. Гугл в помощь, как обычно.

М>это ты называешь громким словом фреймворк?
М>http://www.jython.org/jythonbook/en/1.0/JythonAndJavaIntegration.html
М>тут чтения минут на полчаса. и тут описаны целых два фреймворка, работающие по разному принципу (вызов через скриптинг и нативный вызов с компиляцией питона в JVM), кстати, питон может вполне нативно вызывать Java.
Круто, чо, спасибо, буду знать.
Но на моей прошлой работе в Джире был один из "эпиграфов": "The very last thing you'll ever need to learn how to say in Arabic:"لا، أنا لست ياباني أنا كندي" "No, I am not Japanese. I am Canadian."

М>смотря насколько глубоко рыть. например, чем в питоне генератор от итератора отличается? нет, это неправильный ответ. правильный ответ искать нужно в другом месте, т.к. различия проявляются при отказе от стандартного тормозного интерпретатора. а независимые аналоги полнотой поддержки не страдают. и начинаешь себя ругать -- на кой ляд я пытался сделать "элегантно" и "красиво"?! теперь приходится все переделывать взад.
Опять же. Задачи у нас разные, решения, соответственно, тоже.

М>эти же самые типы влекут за собой тепловоз, называемый полиморфизмом, потому что нельзя тупо передать функции foo объект obj, реализующий все необходимые ей методы, если obj не в той иерархии классов. и потому наследование появляется там, где оно не подкреплено никаким здравым смыслом. на питоне (и многих других языках) функции foo можно передать объект "дверь", "окно", "банка пива" и функция foo дернет метод 'открыть' и все довольны. а теперь вопрос на засыпку -- что нужно курить, чтобы построить систему классов, в которой у банки пива и двери есть общий предок?

У двери, банки и Америки общих предков нет, конечно, но есть общий интерфейс IOpenable. В C++ это выражается чисто абстрактным классом с одним методом open()

М>и ведь это не надуманный пример. пусть нам по ходу дела нужно читать данные. читать их можно из чего угодно, был бы только метод read(). общих предков иметь необязательно. общие предки нужны только там, где в базовый класс можно вынести 90% функционала, а наследники реализуют вариации на тему. например, если у нас есть класс "абстрактное хранилище", которым может быть SQL, ассоциативный массив в памяти и файловая система. нужно ли им всем иметь общего предка? а зачем? ведь базовый класс будет пустышкой по сути. а вот если мы реализуем библиотеку работу со строками, то 90% функционала таки в базовом классе, а в производных -- работа с национальными кодировками, например, для сравнения символов без учета регистра.
Вопрос философский. Можно так, можно так. Одно другого вроде как ничем не хуже. Питон позволяет обойтись без общего предка? Отлично, тогда и фиг ты с ним. C#/Java/C++ не позволяет? Вот, интерфейс.

D>> С вебом хуже, фреймворков действительно десятки.
М>какое счастье, что от веба я далек как от луны
Мне уже интересны твои повседневные задачи, если для тебя важна производительность регекспов в питоне, но с веб это не связано