June 5th, 2012

Gen.Turgidson

Посмотрел на камля с батарейками

Вот все-таки удивительные люди бывают - из всего джаву сделать норовят - большая и неплохая библиотека, люди долго работали, и полезность ее сокращается до близкой к ну не нулю, но сугубо нишевой и все только из-за того, что с какого рожна вставили зависимость в runtime от наличия внешнего происхождения хламовника с файлами.

Вроде можно и решить вопрос - но ради пары удобных функций на фиг такое надо.

Также как и любитеи ради хранения конфига sql сервер присобачивать всегда удивляли.

Единственное, что жаль - это потраченного на уяснение этого факта времени - потому как надо выкидывать пока не поздно.a
Gen.Turgidson

Камлево-программерское:

Такая - общая довольно проблема в этих всех делах - это

1) непонимание, как продукт вообще используется (точнее то, что об этом не задумываются)
2) попытки сделать из него то, чем он не является и что сделать не удастся:

То есть caml - очень удобный инструмент для написания standalone программок, которые работают с довольно сложными структурами данных. Попытки сделать из него Java в смысле библиотек - во-первых не очень-то нужны: скорее бы не помешало на уровне компилятора поддержать например средства отладочной печати этих структурок etc - причем именно на уровне компилятора, а не препроцессора - потому что тут надо, чтобы как минимум:
a) работало сразу
b) было у всех и одинаковое и не тянуло дополнительного софта (camlp4 при всех его достоинствах сам по себе уже не является общепринятым тулом)

То же самое надо от базовых библиотек - если нет общепринятого репозитория пакетов - извините - то, чего нет в стандартных сборках лучше без нужды не юзить.

Идея же устраивать россыпь либ, которые надо собирать из сорцов, часто подпиливая что-то "по месту" с кучей плохо согласованных версий - это неюзабельно. Лучше сделать меньше, но аккуратно и без зависимостей.

При этом надо понимать, что Жаба-то чуть не главным достоинством имеет то, что у нее куча библиотек входит в стандартный JRE и работает более или менее одинаково на всех платформах - а не посредством распаковки 10 архивов, сборки каждого из них ручками прописывания переменных окружения etc.

Понятно, конечно, почему сами разработчики подобных либ это плохо воспринимают - у них уже отставлено все, что им нужно для работы, прописаны все нужные им пути и версии стоящего у них софта согласованы друг с другом просто исторически. Ну и они неплохо знают потроха и в документации не нуждаются.

Мысль о том, что при отчуждении софта установка и настройка всего этого превращается в проблему - уже сама по себе не близка. Тем не менее - превращается и это imho чуть не главная причина, что большая часть таких либ невостребуется.

В крайнем случае - взять те же батарейки - если мне очень понадобится оттуда допустим batString.ml - команду cp никто не отменял. А что-то сложное брать себе дороже.

PS: Противоположность - это подход "наш продукт уже умеет все, что вам нужно" - та же Java. Все конечно не умеет - но таки да - имеет право на существование. Ну там свои грабли есть - но это как минимум для крупных и централизованных в достаточной степени разработок - и по инструменту и по назначению.