Слишком мощный язык программирования

[metaclass]

I saw this 10 years ago when looking for a GUI to my Lisp. No problem, there were 9 different offerings. The trouble was that none of the 9 were properly documented and none were bug free.

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

Comments

[darkdrip.livejournal.com]

зачем переходить на "правильные" языки программирования, если за тот же пхп платят столько же?

[jau-23.livejournal.com]

Но это таки не значит что у "не-мощных" языков библиотеки хорошо документированы и bug-free :3

[lionet.livejournal.com]

На мощном языке ты набросал либу, и она у тебя работает.

На немощном языке ты взял либу, и пилишь её до скончания света.

[swizard.livejournal.com]

Ага, согласен. Но на это можно смотреть как с отрицательной точки зрения, так и с положительной.

[ex0_planet]

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

[dev-zzo.livejournal.com]

>> and none were bug free.

Вот это доставило больше всего.

Часто с женой говорим на тему тестирования продуктов (она у меня спец по QA софта), и чем чаще говорим, тем сильнее я убеждаюсь, что bug-free софт -- это чуть ли не миф какой-то. Потому что всегда находится какая-то хитровыпендренная конфигурация железа, особо мудрый пользователь или великий хакер, который умудряется софт сломать. Потому что к правильному результату приводит одна комбинация "ручек", а к баглу -- все остальные. И вот с ростом количества этих ручечек всё сложнее ловить левые варианты. Особенно, если ручечки не сами по себе, а как-то связаны. Особенно, если ты в системе не один, а ещё есть пачка другого кода, который писал не ты.

Читал книжку о параноидальном программировании. Основная идея -- не доверяй никому, и себе тоже. Но если сесть и посчитать, то методичное применение этого подхода выливается в титанические затраты производительности -- полезной работы выполняется меньше, чем проверок. Что с этим делать -- я, если честно, не знаю. Юнит-тесты не спасают, всегда есть варианты о которых я не подумал, а если думать о них всех -- у меня жизни не хватит дописать хотя бы одну программу более-менее приличного размера.

зацените, какая трава

[nealar.livejournal.com]

http://www.haskell.org/haskellwiki/MetaHDBC
Кажется, это как раз по части Вашего раввината?