Здравствуйте, Dair, Вы писали:

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

D> О, да. Я внимательно изучил модели в руби. Сделать там обычный для меня запрос
D> превращается в головную боль.
серьезно? да вроде нет никакой боли, если не использовать ActiveRecords, а коннектиться к базе и говорить ей SELECT.

D> "No, I am not Japanese. I am Canadian."
гм, ну вот для меня в свое время было открытием, что питон можно вызывать нативно из руби и наоборот.

D> У двери, банки и Америки общих предков нет, конечно, но есть общий интерфейс IOpenable.
D> В C++ это выражается чисто абстрактным классом с одним методом open()
а если завтра нам нужен интерфейс, типа щупальца, который говорит "свободен", "занят", "заблокирован застрявшим винни-пухом". а после завтра нужен интерфейс "тревоги" (типа на банке пива сработала сигнализация). у си++ не хватит выразительности языковых средств, чтобы при чтении кода не сорвало крышу. или я просто не умею его готовить...

М>>какое счастье, что от веба я далек как от луны
D>Мне уже интересны твои повседневные задачи, если для тебя важна производительность регекспов в питоне, но с веб это не связано
мои задачи это pattern matching в реальном времени, причем сопоставление нечеткое, что сильно осложняет дело. тут больше математики, чем программирования, тем более, что изначально в мою задачу входило определение _что_ искать, а не _как_ искать, но выяснилось, что первое и второе неразрывно связаны. даже если я знаю, что искать, нужно учитывать возможности существующих движков или допиливать их.

М>логично. рубиновые рельсы на мою винду не встали. когда мне надоело трахаться, я быстро наваял на питоне прямой SQL запрос. работает везде (на любой платформе). и, кстати, абстрагируется от базы. поменяется внутренеее представление (что навряд ли) -- перепишу SQL запрос в скрипте. делов-то. а почему рельсы не встают на винду -- хз.
У меня встали на раз-два вместе с Аптаной. Хотя таргет-платформой был Линукс, где уже крутилась модель базы, с которой предстояло работать.

М>серьезно? да вроде нет никакой боли, если не использовать ActiveRecords, а коннектиться к базе и говорить ей SELECT.
Так это и есть то самое "вручную писать SQL" Вот, так и делал, да.

D>> "No, I am not Japanese. I am Canadian."
М>гм, ну вот для меня в свое время было открытием, что питон можно вызывать нативно из руби и наоборот.
Круто, кстати. Для женитьбы питономодуля и рубимодуля от разных разработчиков может пригодиться.

D>> У двери, банки и Америки общих предков нет, конечно, но есть общий интерфейс IOpenable.
D>> В C++ это выражается чисто абстрактным классом с одним методом open()
М>а если завтра нам нужен интерфейс, типа щупальца, который говорит "свободен", "занят", "заблокирован застрявшим винни-пухом". а после завтра нужен интерфейс "тревоги" (типа на банке пива сработала сигнализация). у си++ не хватит выразительности языковых средств, чтобы при чтении кода не сорвало крышу. или я просто не умею его готовить...
Я нигде не сказал, что С++ — лучший язык в мире. Возможность есть. Удобнее на питоне — пиши на питоне. Никто с пистолетом не заставляет писать на конкретном языке.
В питоне и руби меня доставало каждый раз писать рантаймовую проверку/преобразование типа, потому как иначе оно всё падает в процессе, а не на этапе компиляции, как в C/C++/ObjC/Java.

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

Здравствуйте, Dair, Вы писали:

D>У меня встали на раз-два вместе с Аптаной. Хотя таргет-платформой был Линукс,
D>где уже крутилась модель базы, с которой предстояло работать.
у меня тоже основная платформа линух, под который пишу, но пишу сидя то под виндой, то под маком. догадываюсь, что с рельсами делаю что-то не то или не так, но запросы к базе у меня несложные и мне напрямую работать проще, чем тащить непонятно какие зависимости по библиотекам. тем более, что сейчас переползаю с хрюши 32 на семерку 64. вдруг и там рельсы не встанут?

D> Я нигде не сказал, что С++ — лучший язык в мире. Возможность есть. Удобнее на питоне — пиши на питоне.
да у меня и выбора особого нет. на питоне занимаюсь быстрым прототипированием. расширяемость питона поражает. допустим, моя API Функция возвращает список. списка становится мало и в следующей версии вместо списка у меня словарь. но словаря тоже мало и наконец возвращается объект. и все это без потери совместимости со старым кодом. вот такое legacy. т.е. хочешь работать с возвращенным типом как со списком -- флаг тебе в руки. хочешь юзать его как словарь -- да без проблем. ну а если тебе нужны все-все-все фичи -- юзай это как объект.

это облегчает прототипрование, поскольку типы можно меняь прямо на ходу и старый код об этом даже не подозревает. я уже молчу про то, что на питоне элементарно (в несклько строк) пишется функция, принимающая строку с данными как аргумент или абстрактный объект, реализующий метод read(). просто невероятно удобно. например, нам нужно считать md5. мы передаем либо файловый объект, либо буфер с данными.

> Никто с пистолетом не заставляет писать на конкретном языке.
зависит от работодателя...

D> В питоне и руби меня доставало каждый раз писать рантаймовую проверку/преобразование типа,
D> потому как иначе оно всё падает в процессе, а не на этапе компиляции, как в C/C++/ObjC/Java.
есть же ведь статические верификаторы... кстати, рантаймовая проверка обходится, если наследовать все, что вам нужно от базового класса, где реализованы заглушки на все нужные вам методы, которые возвращают "не реализовано" и сигнализируют об ошибке.

D> Это я читаю как "обработка больших массивов данных". Задача интересная, но мне с ней сталкиваться не приходилось.
да, массивы данных, действительно, большие. 2TB — это микроскопический тестовый набор данных для _быстрой_ проверки не развалилось ли чего. допустим, прототип на питоне. даже с учетом оптимизирующего JIT компилятора на лаптопе эти 2TB обрабатываются очень долго хотя бы в силу того, что диск подключен как сетевой, а гигабитный езернет это очень узкий канал.

вот поэтому интерактивные отладчики на меня действуют как красная тряпка на быка

Здравствуйте, мыщъх, Вы писали:

М>не знаю как в .ru, а в us ситуация обратная. рубисты хотят получать деньги и не хотят работать. стратегия приблизительно следующая -- устраивается рубист на работу. пол-года что-то делает, а потом планирует только багфикс да мелкий допил. причем многие соискатели даже не обрабатывают ситуацию "нет файла" или "нет библиотеки", не говоря уже о том, что логгер в их понятии это функция в несколько строк и у них не возникает вопроса -- что произойдет, если скрипт будет вызыван из 2+ процессов и они оба откроют один и тот же файл на запись. понятно, что они окончили вечерние курсы по руби и на курсах вопросы синхронизации вообще не затрагивались. но даже такие перцы как-то находят работу. не знаю как, но находят.

Может их на курсах не столько программированию учат, а умению продать себя на собеседовании. А уж этот навык он важнее для получения плюшек, многие программисты торговаться не умеют.