Сторонние библиотеки - быть или не быть?

[Zeroglif]

В свою очередь, склеенные на скорую руку, неоптимальные решения - могут с лёгкостью попасть в массы.

Не могут, а так и происходит.

всё равно больший интерес составляет эта новая абстракция JavaScript и ее новая идеология, а не Си-шная реализация метода

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

[Dmitry A. Soshnikov]

а js-программист видит язык only, доки-спеки языка и фсё, ему исходники движков не нужны, пусть это заботит эксперта из соответствующей области (если только движок не написан на js).

Ну вот проведи параллель с JS -> jQuery и Реализация JS -> JS - получится примерно та же картина:

"а jquery-программист видит "язык" only, доки-спеки jquery и фсё, ему исходники "функций jquery (с легко запоминающимися названиями)" не нужны (ему нужны сами функции), пусть это заботит эксперта из соответствующей области - области JS"

При этом, если по большому счёту - новую библиотеку можно приравнять к новому языку (особенно, если библитека изменяет идеологию языка). И тех, кто подключился к программированию на "JS" (читай jquery) на этом уровне, сам JS может волновать мало. Но, не обязательно. Всё-таки, параллель приблизительная, а не точная, и библиотека, это не новый язык, а библиотека в рамках языка, поэтому какой-то процент jquery-программистов, всё же, будут изучать сам JS.

Не могут, а так и происходит.

Тоже закономерно. Потом (допустим, гипотетически) эту библиотеку напишешь/перепишешь ты, и она уже не будет такой, так? Так (потому что ты видел недочёты и устранил их). Но и потом будут те, кто будет видеть недочёты. Только процент претензий уже будет меньшим (обратно пропорциональным к уровню профессионализма разработчика). Но все же будет. Будут судить, если не о моментах знания самого языка, а докапаются до того, как ты реализовал какой-нибудь алгоритм и т.д. (т.е. до чего-то субъективного, что нельзя будет описать объективно и однозначно).

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

- играет роль уровень профессионализма программиста, использующего библиотеку. Программист может корректировать библиотеку, написать свою и т.д.

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

[Dmitry A. Soshnikov]

Вот, нашёл мой пост на подобную тему годичной давности - Стоит ли пользоваться библиотеками или лучше писать свой код?. В принципе, то же самое. Однако, там я говорю, что "я может жалею". Хотя, я как тогда не использовал сторонние библиотеки (у меня вообще, еще до появления и prototype.js и jquery был написан свой фреймворк), так и сейчас не использую, т.к. сейчас, по долгу службы, занимаюсь хоть и JS, но не в плане web-программирования (а там эти библиотеки не нужны). А когда занимался именно программированием "для браузеров" - использовал свой легковесный фреймворк, который для меня являлся лишь кладезю решений (разработанных мной, а так же - заимствованных из сторонних библиотек).

Но в целом - я не против того, чтобы люди использовали сторонние фреймворки, поскольку, иначе - зачем они пишутся? А пишутся они именно для этого, потому что (тоже уже отмечал) - по большому счёту все задачи можно разделить на два больших раздела:

- задачи на инструментарий (написание языков, фреймворков, виджетов и т.д.);

- прикладные (повседневные), "высокоуровневые" задачи с использованием инструментария из первого пункта.

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

[Zeroglif]

"а jquery-программист видит "язык" only, доки-спеки jquery и фсё, ему исходники "функций jquery (с легко запоминающимися названиями)" не нужны (ему нужны сами функции), пусть это заботит эксперта из соответствующей области - области JS"

Вижу-вижу аццкое противоречие. Область тут одна - javascript (в отличие от реализаций движков), по сему "jquery-программист" и его "jquery-язык" - это 2 инвалида, костыляющих прочь от js-программирования и browser-scripting в целом. Но надо отдать должное - костыляют шустро.

[Dmitry A. Soshnikov]

Вижу-вижу аццкое противоречие.

Да какое противоречие? (да еще и аццкое) Этим самым я хочу показать, что для тех, кто программирует только на jquery, без желания знать JS, jquery становится "чистым языком", а сам JS уже может рассматриваться, как "другая область". И тем самым, сама функция .ruleThemAll() интересна, а вот её внутренняя реализация (на JS) - может и нет.

То, что область физически одна - JS - это понятно, это я сам отмечаю - "Всё-таки, параллель приблизительная, а не точная". Но вот если смотреть на это идеологически - библиотека может въесться в мозг, как "чистый язык". Сам же "чистый язык" может стать "другой областью".

P.S.> я замечу, я не говорю ни "да", ни "нет", ни "за", ни "против". Я лишь анализирую со стороны, как есть.

P.S[2].> это лишь моё видение.

[Zeroglif]

я не говорю ни "да", ни "нет", ни "за", ни "против"

Тухлое API сожрёт мир. При твоём попустительстве.

[Dmitry A. Soshnikov]

При твоём попустительстве.

О-о, поверь, я вовсе не безучастен. "Ни за, ни против" - имеется в виду моя позиция в текущей беседе. И имеется в виду, что моя позиция не принадлежит ни к лагерю "О, великий фреймворк! Программировать надо только обязательно с стобой!", ни к лагерю "Ни в коем случае нельзя использовать сторонние фреймворки".

По-моему, моя позиция достаточно чёткая? - Я говорю, что я использую, почему я это использую, почему я не использую другое, привожу причины, по которым другие используют это другое и, при этом, анализирую картину в целом (включая частные случаи).

Тухлое API сожрёт мир.

Если принять во внимание, что так было всегда (всегда профи замечали некую "тухлость" некой абстракции), тогда всё может быть "тухлым". Включая JS. Ведь вероятно же, что когда создавался JS, отмечалось (и не раз) о каких-нибудь идиотских моментах, которых не было в другой абстракции.

Ты рассматриваешь лишь одну из сторон - идеологическую. Не забывай, что есть еще и прагматические сенсорные потребители технологии. Их задача - сдать проект клиенту и, как можно быстрее, срубить бабла на этом. Идеология их вообще может не волновать в этот момент (ни jQuery, ни JS). Они-то, уж, тем более, не будут заглядывать внутрь никаких функций, терзаться сомнениями и обсуждать, "ой-ой... как это тухло создатели фреймворка, благодаря которому мы срубаем хорошенько бабло, написали эти функции. Ай-яй-яй...". Вот, кстати, холиворы на всякого рода форумов, часто возникают именно из-за этого - когда встречаются эти два типа программистов - прагматичные потребители и идеологические создатели. Это как истинные работники науки, которые у нас в России работают "за еду", и потребители продуктов этих учёных.

Также, ты не рассматриваешь уровень абстракции, на котором работает программист. Здесь не важно, сам он написал библиотеку или нет, но ему нужно работать с библиотекой, т.к. его программа целиком и полностью состоит из таких абстрактных сущностей, который нет в языке, и написание одной такой сущности - занимает 3000 строк кода. Естественно, её напишут один раз и дальше будут использовать 1000 таких сущностей, показывая окошки, лишь вызовом функции alert(...). Дальше, если сторонняя библиотека начнёт сильно тормозить, здесь уже зависит от уровня профессионализма программиста. Он, либо сядет и заплачет, т.к. не умеет программировать на более низком уровне (на более низкой абстракции), либо напишет свою библиотеку (или доработает существующую стороннюю). Кстати, этот пункт может тесно переплетаться с предыдущим - желанием наиболее эффективно устроить отдачу от того, что делает программист. Но здесь отдача может быть не только материальная, но и идеологическая.

Говорить же просто - "нет, не используйте никакие сторонние фреймворки" (чтобы не допустить "попустительств" ) - нет, я не могу, потому что это означает, что я не учел другие факторы.

Я говорю, это необратимый процесс (мне кажется). На каждом этапе есть люди, которые говорят - "не оптимально; тухло". И они правы. Только это мало, что решит, т.к. есть множество других факторов, нежели лишь идеологический взгляд. Поэтому, прогресс идёт дальше. Потребляя все больше ресурсов, но и, разрабатывая всё новую технику, которая будет выдерживать такое потребление. В итоге, эта "тухлая неоптимальность" сглаживается и дальше уже становится не заметной. Что бы изменилось, если бы эту библиотеку написал тот, кто говорил о неоптимальности? - Она бы, естественно, улучшилась в каких-то идеологических моментах и тоже бы создала прогресс. Но и это, относительно других факторов (не идеологических), было бы не заметно (да и, к тому же, были бы другие, кто говорил бы "неоптимально; тухло", но уже - меньше - обратно пропорционально уровню профессионализма).

[Dmitry A. Soshnikov]

Да и, не дописал вчера. О роли профи-"оценщиков" (в моём видении).

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

Не было бы профи-"оценщиков", возможно, был бы регресс (либо, очень медленный прогресс).

[korzhik]

Ну скажем так. Фреймворки хороши для решения определенных задач, например при написании большого веб-приложения, конечно, при условии понимания программистом принципов его работы
Безусловно, их использование совсем не оправдано, когда используется 2-3 основных функции.

[x-yuri]

Zeroglif, так в чем заключается твоя позиция?