Где наша свобода?

[vitus_wagner]

Есть такой анекдот:

Диалог в бюрократическом учреждении:
- Имею ли я право?
- Конечно имеете!
- Так могу ли я?
- Нет, не можете!

Положение дел в области Free Software чем дальше, тем лучше описывается этим анекдотом.
Имею ли я право исправлять глюки и дописывать нужные мне фичи в Mozillу, OpenOffice, ядро Linux, Gimp etc - да сколько угодно. Лицензия позволяет.
Могу ли я? Увы, трудоемкость, необходимая для вникания в большой проект на несколько миллионов строк - соврешенно prohibitive. Даже при наличии квалификации. А протолкнуть свои изменения в upstream - еще сложнее.

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

Еще десять лет назад это было не так. Тогдашние OpenSource проекты были достаточно компактны, лучше документированы, и всё необходимое тайное знание содержалось в коде. Было дело в 99-м году я при каждом новом релизе ядра ветки 2.2 внимательно читал патчи чтобы решить - ставить это срочно на боевой сервер или погодить пока.

Сейчас я пожалуй, не пойму в этих патчах почти ничего. большая часть тайного знания необходимого для написания компонент ядра, из кода без больших усилий не извлекается. А отдельных источников этого знания почти и нет. Ну по ядру еще есть. А попробуйте найти вменяемое описание работы с Bluetooth. Содержащее внятные схемы стэка протоколов, описание общей идеологии и того как это раскладывается на API. Не существует такового в природе.

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

Сейчас reusable компоненты как правило делаются в виде динамических библиотек со сложным API. Где-то это реально необходимо, где-то это явный overkill. Особенно если учесть что с первого раза спроектировать хороший API для рещения любой задачи - весьма нетривиально. Поэтому API у многих opensource библиотек плывут. Совершенствуются. Но это приводит к головной боли при поддержке используещих их программ.

Более того, за последние 10 лет в Open Source пришло множество программистов воспитанных на Visual Basic и прочих изделиях Microsoft, где от программиста не предполагается четкого понимания задачи в целом - это понимание - коммерческая тайна Microsoft.
Вот пример в MSDN, делайте по образу и подобию. Воспринимайте эти слова как магическое заклинание, как ритуал.

Но там хотя бы сидят несколько сот человек, которые это дело документируют.

Заметим что микроядро в Hurd было на самом деле нужно не столько по тем техническим соображениям, которые приводил Таннебаум в споре с Линусом, сколько именно из соображений well-defined interfaces, которые позволили бы множеству независимых разработчиков работать над разными подсистемами ядра. Но ни Таннебаум, ни Столлман этого тогда сфонрулировать не могли. Потому что это на самом деле вопрос социальной психологии а не технологии.

Некторые решения, которые уже фактически приняты сообществом как стандарт, иначе как миной замедленного действия под идею свободного софта я назвать не могу. Ну про CUPS уже Раймонд всё написал. Ага, тот самый Раймонд, который выдумал термин Open Source как менее "страшный" чем "Свобода", чем немало способствовал возникновению данного положения. Еще большей миной замедленного действия я считаю D-Bus. Не то, чтобы плоха была самой идеи общесессионной или общесистемной шины сообщения. Но во-первых, реализация - нету стандартного набора утилит для работы с этим из shell. Не отладочних прибабахов вроде dbus-send и dbus-monitor, а полноценных инструментов для работы класса NetCat. Во вторых, документированность. Уже сколько лет в комплекте bluez, который иначе чем через dbus нынче с пинкодами не работает, идет passkey-agent, написанный настолько криво, что при его завершении libdbus ругается на stderr. И никто не соберется исправить.

К сожалению, в 96-97 году, когда начинались проекты KDE и GNOME не нашлось гения, который бы предложил архитектуру GUI-среды, способную развиватья в условиях Free Software, и при этом оставаться простой и понятной. Впрочем, это как раз был переломнымй момент, когда менялись условия Free Software - вместо немногочисленных, но весьма квалифицированных хакеров 80-х, кончавших одни и те же университеты, и понимавших друг друга с полуслова, повалила толпа любителей, осваивавших программирование на персональных компьютерах самостоятельно.

Как теперь из получившейся ямы вылезать я не знаю. Выкингуть существующие миллионы строк кода просто так не получится. Хотя место большей части этого кода - именно на помойке.

Comments

[gineer.livejournal.com]

//А я использую систему, которую можно улучшить.

Можете оценивать это как максимализм.
Но я все же рассчитываю создать свою систему, максимально соответствующую именно моим теперешним воззрениям на то какой она должна быть, чем расширять уже существующую.

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

Унаследованый код -- это и преимущество, и баласт.
Тогда как наново написаный -- это только приемущество, хоть и с риском провала.

[besm6.livejournal.com]

Но я все же рассчитываю создать свою систему

А вот это из предыдущих слов не следовало. Или я что-то уже успел забыть. Это, конечно, пожалуйста, но...

Унаследованый код -- это и преимущество, и баласт.
Тогда как наново написаный -- это только приемущество, хоть и с риском провала.

Засада в том, что пока наново написанный код еще не написан, он еще не преимущество, а только риск провала. А как только он написан, он становится унаследованным...

[gineer.livejournal.com]

написал развернутый комент, но при отправке произошла ошибка... хз, может так оно и лучше...

[gineer.livejournal.com]

//А вот это из предыдущих слов не следовало.

Это вроде как рефрен общей темы. "Или этих помыть, или новых сделать"

\\Засада в том, что пока наново написанный код еще не написан, он еще не преимущество, а только риск провала.

ubi nihil nihil... нет кода, нет риска

Проблема не в риске. Гораздо сложнее придумать что-то действительно нетривиальное и стоящее реализации. Зато тривиальных поделок с претензией на иновационность -- пруд пруди.

//А как только он написан, он становится унаследованным...

А это дургой вопрос.
Почему даже только что написанный код превращается в баласт?

И никакие палеативы типа "литературного", "быстрого", модульного или еще какого... ответа на него не дает.

ИМХО, в консерватории нужно что-то менять...

[besm6.livejournal.com]

Гораздо сложнее придумать что-то действительно нетривиальное и стоящее реализации.

Мне кажется, условие "нетривиальное" тут лишнее. Тривиальность сама по себе ничем не плоха, и часто даже наоборот. А вот претензия на инновационность - как раз нехороший признак. Ага, в частности поэтому я предпочитаю учиться не новому, а хорошо развивающемуся старому. Вот правда, слово "хорошо" тут ключевое (emacs, скажем, развивается хорошо, а мозилла - плохо), а четкого определения ему я дать не могу.

Почему даже только что написанный код превращается в баласт?

А вот этого я не утверждал. Унаследованный код является балластом (да, если можно, пишите, пожалуйста, это слово с двумя "л", а то у меня "врожденная грамотность", и я дергаюсь; то же касается слов "паллиатив" и "инновационность") не по определению, а как правило.

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

[gineer.livejournal.com]

//Мне кажется, условие "нетривиальное" тут лишнее. Тривиальность сама по себе ничем не плоха, и часто даже наоборот.

Какраз это главное условие, просто мы видимо поразному понимаем это слово. Для меня тривиальность -- не синоним простоты.

Есть два вида истины - тривиальная, которую отрицать нелепо, и глубокая, для которой обратное утверждение - тоже глубокая истина.(с) Нильс Бор

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

//Унаследованный код является балластом (да, если можно, пишите, пожалуйста, это слово с двумя "л", а то у меня "врожденная грамотность", и я дергаюсь; то же касается слов "паллиатив" и "инновационность") не по определению, а как правило.

"Войну с саламандрами" читали... от дрейфа грамотности в сторону упрощения никуда не деться. :)

Лично я, вижу причину такой ситуации (с кодом) в том, что существует барьер использования в виде бинарного кода, в который компилируется текстовое представление, и который практически не доступен для просмотра и редактирования.

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

[besm6.livejournal.com]

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

от дрейфа грамотности в сторону упрощения никуда не деться. :)

Не вопрос. Но если не слишком сложно, давайте все же не будем торопить события, а подождем, пока она додрейфует до состояния, когда предложенное Вами написание станет грамотным... :-) Тогда моя "врожденная грамотность" тоже туда сдрейфует, и все будет нормально.

Лично я, вижу причину такой ситуации (с кодом) в том, что существует барьер использования в виде бинарного кода, в который компилируется текстовое представление, и который практически не доступен для просмотра и редактирования.

Ну, не знаю... Не далее как сегодня я нашел способ сделать некоторое действие (шорткат для Ctrl-\) в osso-xterm (N800, экранная клавиатура), который сам по себе (то, что исполняется) бинарен. Но у которого есть текстовое представление, и оно доступно. Потребовалось прочесть кусок его кода, найденный грепом, и грепнуть один из хедеров от GTK. В данном случае - типичный пример унаследованного кода, причем в два слоя. Нет, программу менять не надо, она работает. (Ну, при желании можно, там есть еще одно место, которое бы подточить, чтобы тут поглаже было... Подточить, кстати, тоже будет несложно, тормозит меня только необходимость разворачивать sandbox для пересборки) Надо только знать, как она работает. Никаких нетривиальных идей придумывать не надо, все придумано до нас :-)

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

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

[gineer.livejournal.com]

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

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

Не хотелось бы продолжать ТОЛЬКО на таком уровне.


//Ой, боюсь Бора Вы зря привели.

Это не новость. (по крайней мере для меня)
Что когда дискусию ведут образованные люди, то разночтения идут не в использовании слов/терминов, а на гораздно более глубоком уровне оттенков их понимания.

Потому я не думаю что мы уж так поразному понимаем слово "тривиальность".

Для меня же это высказывание Бора, это дифиницыя отличия обыденной логики и здравого смысла и научной, рациональной.

Скажем как илюстрация к выссказыванию.
"Солнце встает на востоке" -- тривиальная обыденная истина.
"Земля вращается вокруг Солнца" -- уже глубокая, неочевидная, дающая нетривиальные вывод от её осмысления.

//Ну, не знаю...

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

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

Тут уже хозяин блога, Витус.
Упоминал о ТРИЗ (теории решения изобретательских задач) где-то.
А в ней есть один метода решения задач -- ИКР -- поиском Идеального Конечного Результата.

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

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

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


//Чем выше уровень языка, тем меньше дистанция между задачей и мозгом.

Я понима о чем вы говорите -- это достаточно распространенное мнение.Есть еще синонимичное, ИМХО, "любую задачу можно решить на любом языке".
Но тем не менее считаю что оно ошибочное -- уводит от решения реальных задач в страну ничем не связанных, ничем не ограниченных абстрактных фантазий. Среда обитания "архитектурных астронавтов".

//Мне скорее представляется, что проблема не в сложности задач, а в неопределенности базовых понятий.

Ооо... это уже мы с вами возвращаемся к тому с чего начали. К спору Бора с Эйншетйном.
Тогда Альберт тоже предлагал определить базовые понятия.
В таком случае я использую хрестоматийный ответ Нильса, чтобы ответить вам... думаю нет нужды его цитировать.

[besm6.livejournal.com]

(порезано на несколько комментов, а то не лезет)

Для меня же это высказывание Бора, это дифиницыя отличия обыденной логики и здравого смысла и научной, рациональной.

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

"Солнце встает на востоке" -- тривиальная обыденная истина.
"Земля вращается вокруг Солнца" -- уже глубокая, неочевидная, дающая нетривиальные вывод от её осмысления.

Здесь тривиальной истиной названа эмпирическая, а нетривиальной - полученная в результате более чем одноуровневого осмысления эмпирики.

[gineer.livejournal.com]

//(порезано на несколько комментов, а то не лезет)

да, мы как-то много здесь нафлудили :)
возможно стоит поменячть место дислокации?

//Начнем с того, что "рацио" - это ученое название для здравого смысла, и противопоставление их выглядит несколько странно...

обыденному, обывательскому здравому смыслу, тому который позволяет верить в возможность вечного двигателя и не верить в движение Земли вокруг Солнца -- противостоит.

//Здесь тривиальной истиной названа эмпирическая, а нетривиальной - полученная в результате более чем одноуровневого осмысления эмпирики.

Это уже философские изыски. Мышей абстрактных дефиницый можна делить до любых желаемых приделов, отыскивая все более и более "глубокие" градации и дихотомии.

Я просто привел конкретизирующий мое понимание пример.

[besm6.livejournal.com]

возможно стоит поменячть место дислокации?

Ну, может Витусу интересно? Он пофилософствовать под настроение тоже не дурак.

//Начнем с того, что "рацио" - это ученое название для здравого смысла, и противопоставление их выглядит несколько странно...

обыденному, обывательскому здравому смыслу, тому который позволяет верить в возможность вечного двигателя и не верить в движение Земли вокруг Солнца -- противостоит.

Если такой смысл называть здравым, то да. Но тогда надо вернуться на пару циклов назад и начать с уточнения терминологии.

[gineer.livejournal.com]

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

если согласны с таким перемещением, отпишите и я перенесу ваши и мои коменты в свой раздел.

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

ЗЫ Если хотите, можете и у себя разместить, конечно. Главное чтобы продолжать дискусию было удобно.

[besm6.livejournal.com]

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

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

Я могу попробовать создать под эту дискуссию группу в Гугле (заодно хоть посмотрю, как они устроены).

[gineer.livejournal.com]

Ну, резюмировать все равно где-то надо, да и с тематикой определятся.

Вот для этого я и предложил мой ЖЖ. Выложу там свое резюме как его понимаю, а вы откоментируете с чем не согласны -- вот и будет рестарт, точнее стартовая точка. Согласны?

А так... попробовать гугль групы я тоже не против.

[besm6.livejournal.com]

Сделал группу wash-or-make@googlegroups.com. Подписываетесь письмом на wash-or-make-subscribe@googlegroups.com, подтверждаете подписку, и вперед.

Веб-адрес - http://groups.google.com/group/wash-or-make

[gineer.livejournal.com]

мне даже проще, имея гугл-акаунт

значит что, размещать там резюму того что наобсуждали? наверное так

[besm6.livejournal.com]

Ага.

с моей стороны

[gineer.livejournal.com]

Все... резюма :) есть.

Всем кому интересно прошу дальше следить за дискусией здесь -- http://groups.google.com/group/wash-or-make

Re: с моей стороны

[gineer.livejournal.com]

Или здесь

http://gineer.livejournal.com/728.html

[besm6.livejournal.com]

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

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

Я как раз сделал это без использования низкоуровневых средств. К низкому уровню (работающему бинарному коду) я результат применил, и он сработал. Это важная разница.

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

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

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

Прежде чем сказать слово "неэффективный", хорошо бы привести хотя бы параметры, по которым измеряется эффективность, не говоря уже о критериях. Когда я пользуюсь языком высокого уровня (нет, не "object-oriented assembly language" C++, а высокого), с моей кочки зрения расстояния от текстового представления до результата почти нет. Меня бинарное не интересует. Я беру язык с интроспекцией, и вижу представление в терминах этого же языка. С моей кочки зрения язык с интроспекцией не переводит программу на машинный язык, а преобразует машину Тьюринга в лисп-машину, перл-машину, питон-машину, смоллток-машину и т.п. Существует очень узкое количество мест, где у меня есть основания спуститься уровнем ниже. Я тогда спускаюсь, пишу расширение языка, которое поднимает это место до уровня абстракции моей машины, и снова забываю, что железо у меня полупроводниковое :-) Кстати, да, Вы же низким уровнем называете отнюдь не работу с энергетическими уровнями электронов, а вовсе даже нечто уровней на пять повыше... А почему на пять, а не на семь?

Получается достаточно эффективно в доступных условиях. Кстати, вопреки распространенному мнению, программа на языке типа перла или питона зачастую куда эффективнее аналога на C/C++. Просто потому что нижележащие алгоритмы и их реализации вылизаны куда более умными людьми, чем тот маньяк, который прикладную программу на C (и тем более на C++) писать пытается. Не путать прикладную программу с низкоуровневой библиотекой. Низкий уровень у нас на C писан, с фрагментами (собственно шифрование и длинная арифметика) на ассемблере.

[gineer.livejournal.com]

//К низкому уровню (работающему бинарному коду) я результат применил, и он сработал. Это важная разница.

Ну вы же не набивали напрямую биты с байтами.
Думаю понятно что под низким уровнем я здесь имел в виду самые простые средства представления и работы с информацией.


//С имеющимся низкоуровневым кодом затрудняет работу несоответствие существующей компьютерной архитектуры человеческой интуиции, а вовсе не промежуточные слои.

А какая соответствует?
Это вас снова потянуло на "эзотерику", в сторону от серьозного разговора.
Можна сколько угодно спорить с пеной у рта, какая архитектура лучше, правильные, эзотеричней.
Но это будет уход от темы в дебри иделизированных абстракций -- рассуждения о сферическом коне. С игнорированием того, что ВСЕ архитектуры, ограниченны здесь и сейчас возможностями технологии и законами реального мира.
И именно преодоление этих ограничений и есть ТА важная задача, которую нужно решать... а спорить об идеальных материях будем потом, когда в следствие развития технологий и интелекта сможем представить и замоделировать любого сферического коня на выбор... :)


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

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

Вспомнипте Дийкстру -- как не крути, а все ж он не прав.

[besm6.livejournal.com]

//К низкому уровню (работающему бинарному коду) я результат применил, и он сработал. Это важная разница.

Ну вы же не набивали напрямую биты с байтами.
Думаю понятно что под низким уровнем я здесь имел в виду самые простые средства представления и работы с информацией.

Непонятно. Более того, стало совсем непонятно.

//С имеющимся низкоуровневым кодом затрудняет работу несоответствие существующей компьютерной архитектуры человеческой интуиции, а вовсе не промежуточные слои.

А какая соответствует?

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

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

Есть еще smalltalk-машина. Все более близкое к задачам, видимо, будет уже проблемно-ориентированным.

И я бы сказал, что проблема не в том, что железо у нас такое, какое есть. Проблема в том, что людей учат в парадигме этого железа. В то время как (уметь) мыслить в этой парадигме нужно очень немногим - тем, кто на этом будет реализовывать лисп-машину или смоллток-машину. Ну, или там перл-машину или хотя бы юникс-машину. Ан нет, лемминги учат object-oriented assembly language C++ вместо того, чтобы учиться хотя бы понимать постановки задач. Ага, потому что C++ слишком сложен для того, чтобы программист им пользовался, и в результате язык пользуется программистом - программист способен лишь стандартным образом комбинировать стандартные шаблоны, и понимать задачи ему становится только вредно, поскольку готовых шаблонов под настоящие задачи у него нет. И результатом является то, что изложено в посте...

[besm6.livejournal.com]

//Чем выше уровень языка, тем меньше дистанция между задачей и мозгом.

Я понима о чем вы говорите -- это достаточно распространенное мнение.Есть еще синонимичное, ИМХО, "любую задачу можно решить на любом языке".

Ой, нет, не понимаете... Это не синонимичное, это прямо противоположное... Решение любой задачи можно свести к выражению на любом (Тьюринг-полном, если мы о программировании) языке. Готовое решение. Но не решить.

/Мне скорее представляется, что проблема не в сложности задач, а в неопределенности базовых понятий.

Ооо... это уже мы с вами возвращаемся к тому с чего начали. К спору Бора с Эйншетйном.
Тогда Альберт тоже предлагал определить базовые понятия.
В таком случае я использую хрестоматийный ответ Нильса, чтобы ответить вам... думаю нет нужды его цитировать.

И совершенно зря. Потому что Бор сталкивался с реальной сложностью природы, а у нас задача стоит в том, чтобы результат был понятен человеку (чтобы человек мог пользоваться системой для решения своих задач). Человек в принципе может решать только такие задачи, постановку которых он может понять. Т.е. в человекопонятных терминах постановка задачи проста. Как правило (исключения мне известно два - великая теорема Ферма и проблема четырех красок; понятно, что их может быть больше, но это нетипично) у просто поставленной задачи решение тоже сравнительно простое. Если понятийный аппарат, привлекаемый к решению, соответствует задаче и человеческому мышлению.

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

[gineer.livejournal.com]

//Ой, нет, не понимаете...

Пожалуй я действительно неудачно написал.

Но все равно не ваша правда. Это мы влезли уже в такую область где нужно много осторожнее и покорректнее высказыватся. А мы пока рубим друг другу аргументы с плеча.

Вот у вас и у меня тут многое намешано, давайте разделять.

1) Нет низкого и высокого уровня языка, а есть: соответствует ли он проблемной области? достаточно ли он мощный и выразительный?
для КАЖДОЙ отдельной задачи нужно определятся с обеими этими вопросами.
Если не них не отвечать -- попадаеш в ловушку некорректного обобщения. Начинаеш некртично переносить наработки в одной области в другую.

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

3) Вопрос который присутствует неявно. Програмирование это не только математика, но еще и инженерия. И тут тоже еще очень много чего неясно и очень сложно.

Можна продолжать и дельше... но сами видите, к чему может привести излишнее углубюление в дефиниции и класификации...

Давайте говорить О ГЛАВНОМ.


//Потому что Бор сталкивался с реальной сложностью природы, а у нас задача стоит в том, чтобы результат был понятен человеку (чтобы человек мог пользоваться системой для решения своих задач).

А челоек что, уже не часть Природы???
И разве задачи стоящие перед програмистом не суть одно из проявлений самой природы?


//Человек в принципе может решать только такие задачи, постановку которых он может понять.

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

Это дебри, это болото, это какраз то что происходит когда пытаются решить очень сложные фундаментальные задачи В ЛОБ, используя стереотипные методы, понадеявшись на их "мощность" и всеядность...

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

Нет. Делабт как всегда и... или обявляют задачей нерешаемой или неактуальной, неинтересной (как вы например сделали с вопросом о палитре)
Или же зарываются в частности.

[besm6.livejournal.com]

//Потому что Бор сталкивался с реальной сложностью природы, а у нас задача стоит в том, чтобы результат был понятен человеку (чтобы человек мог пользоваться системой для решения своих задач).

А челоек что, уже не часть Природы???
И разве задачи стоящие перед програмистом не суть одно из проявлений самой природы?

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

или обявляют задачей нерешаемой или неактуальной, неинтересной (как вы например сделали с вопросом о палитре)

А что, задача о палитре должна была стать мне интересной просто по факту того, что Вам хочется палитру?

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

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

Я бы сказал, что с этого надо начинать, если серьезно браться за задачу. А Вы хотите закончить, туда не залезая...