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

[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]

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

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

Так вот... первое что меня заинтересовало в эмаксе -- это поддержка подсветки синтаксиса, но покамест то что я увидел не показалось мне конкурентно лучшим.

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

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

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

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

ЗЗЫ Хотя, я возможно был бы и не против оказатся на вашем месте. :) Изменения иногда утомляют.

[besm6.livejournal.com]

как ответите не следующий вопрос

Вопрос-то в чем? Можно ли увидеть цвет шрифта интерактивно? M-x customise-face RET. Если курсор стоит на нужном месте, он сам предложит соответствующий face. Палитру он показывать, правда, все же не умеет, насколько я понимаю (оно все-таки рассчитано на работу и в терминале тоже). Но умеет показать результат. Подробности - в его info (C-h r s Face Customization RET RET).

Коде-фолдинг бывает в зависимости от языка, на котором документ. Для некоторых есть, для некоторых не написали. Подсветка парной скобки в комплекте. По умолчанию, правда, кажется, выключено. C-h r s show-paren RET, и читать весь раздел (он небольшой, при моем 50-строчном экране умещается в один экран).

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

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

А про консерватизм и застревание - это Ваша фантазия, Вы с ней и спорьте...

[gineer.livejournal.com]

ок, посмотрел то что вы указали

конечно не так все просто и интуитивно, но все же есть, и вроде в полном объеме... похоже ответ положительный, где-то процентов на 70-80... интерактивность все же очень желательная, а не опциональная функция... так же как и интуитивная простота -- все же я нашел сию функцию только после вашей подсказки... это не есть + ИМХО.

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

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

[besm6.livejournal.com]

все же я нашел сию функцию только после вашей подсказки

Которую из двух? customize-face? customize-face is on (Сиречь Menu -> Options -> Customize Emacs -> Specific Face...) show-paren-mode? В том же Options второй пункт, Paren Match Highlighting

[gineer.livejournal.com]

Все же опцию находящуюся на четвертом уровне меню, сложно назвать легко доступной и просто находимой. :)

Универсальность тоже имеет свои недостатки.

[besm6.livejournal.com]

Все же опцию находящуюся на четвертом уровне меню,

На третьем. Это у меня, при принудительно выключенном menu-bar, она на четвертом. А у Вас-то меню наверняка присутствует.

сложно назвать легко доступной и просто находимой. :)

Путь к ней вполне очевиден. Я, натурально, начал настройку емакса, когда ему учился, именно оттуда - с Options->Customize.

Сейчас, став поопытнее, я уже представляю себе принцип именования команд, и начинаю с M-x и использую Tab completion. Получается удобнее, особенно в терминале (а на N800 emacs приходится в терминале использовать).

[gineer.livejournal.com]

третий тоже не сильно доступен, учитывая что используемая терминология непонятна.
например в том же нотепаде++ такая опция находится на втором (Опции->Определение стилей)
И дальше открывается диалоговое окно, где и настройки лучше структурированы, и цвета из палитры...

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

[besm6.livejournal.com]

Вот только не надо путать понятное с привычным... Мне априори "Определение стилей" ничем не понятнее "Customize Face". У меня задача-то не стиль определять, а цвет текста изменить...

а не полагатся на вроде бы реализацию с использованием универсальных...

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

А что до "с использованием универсальных" - можно я Вам Ваше же возражение верну? Если я настраиваю emacs в иксах, у меня есть палитра. Называется xcolorsel. Я на ней посмотрю цвет, посмотрю его название, и впишу. В терминале с палитрами вообще проблемы. В виндах палитра другая и названия цветов другие. Вы предлагаете сделать универсальную палитру, работающую во всех трех случаях, или все же можно воспользоваться специализированными? А почему? А почему тут так, а там - по-другому?

На самом деле отсутствие палитры в емаксе объясняется всего лишь тем, что такого виджета для него никто пока не сделал. Сделаете - будет, кто б возражал? Я, кстати, даже подозреваю, почему не сделано. Потому что тем, кто может, оно нафиг не надо, у них есть куда более интересные задачи, чем по часу в день рихтовать цвета шрифтов. А раз в полгода можно и xcolorsel рядышком запустить, все равно любая стандартная палитра для цвета шрифта, в отличие от цвета фона, малопригодна - разница между полем и тонкой линией...

[gineer.livejournal.com]

//Вот только не надо путать понятное с привычным... Мне априори "Определение стилей" ничем не понятнее "Customize Face".

Фэйс -- тоже не воспринимается с первого раза, без подготовки как относящийся к цвету текста.
Да и привычка тут непричем.
Настройка "Определение стилей" находится прямо под пунктом меню "Опции", в котором в свою очередь всего еще два пункта "Preferences" и "Горячие клавиши".
Так что не найти сложно...

Так что это какраз вы путаете... привычное вам, с понятным любому.

//И что именно Вы понимаете под "это специализированная задача"? А то что-то мне подсказывает, что Вы под этим понимаете совсем не то, что я...

Вот есть задача "открыть файл"... и практически в любой системе ГУИ существует простой и стандартный способ вызова такого диалога.

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

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

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

По час в день -- это только потому что в этой системе именно эта задача достаточно сложная, трудоемкая и действительно может потребовать часа в день, а то и больше.
Но вот в той системе о которой говорю я -- нотепад++.
Это все очень просто и интуитивно, и потому я могу не то что специально настраивать (игратся с цветом шрифтов), а даже просто по ходу работы, зайти в диалог и поменять, что хочу и так, как ИМЕННО СЕЙЧАС мне кажется удобным/нужным.

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

“границы моего языка – это границы моего мира” Витгенштейн

[besm6.livejournal.com]

//Вот только не надо путать понятное с привычным... Мне априори "Определение стилей" ничем не понятнее "Customize Face".

Фэйс -- тоже не воспринимается с первого раза, без подготовки как относящийся к цвету текста.

А я и не утверждал, что "Customize Face", в свою очередь, понятнее. Нет, если знать, что такое face (а это вопрос терминологии, т.е. привычности - просто слово "стиль" в этом контексте Вы уже знаете, а "face" еще нет), то глагол-то понятнее как раз у емакса. Да, уровней получается чуть больше. Но. На первом уровне ровно то же самое (ну, с точностью до того, что слово Options англоязычному человеку понятно, а слово "опции" русскоязычному - не очень). На втором - у емакса просто Customize. Мы сюда что делать пришли? to customize, натурально. Наводим мышку на это слово - нажимать уже не надо, менюшка сама выезжает, и там можно выбрать, что именно customize. Телодвижений чуть больше, но не могу сказать, чтобы они были менее понятны без подготовки.

Настройка "Определение стилей" находится прямо под пунктом меню "Опции", в котором в свою очередь всего еще два пункта "Preferences" и "Горячие клавиши".

И вот я бы без подготовки не сходу сообразил бы, что цвет шрифта надо править в определении стилей, а не в Preferences... Это при том, что я - профессиональный программист и в прошлом админ, и на подобных штуках собаку съел и кошкой закусил.

Вот есть задача "открыть файл"... и практически в любой системе ГУИ существует простой и стандартный способ вызова такого диалога.

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

я могу не то что специально настраивать (игратся с цветом шрифтов), а даже просто по ходу работы, зайти в диалог и поменять, что хочу и так, как ИМЕННО СЕЙЧАС мне кажется удобным/нужным.

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

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

Э, нет. Если Вы выбираете notepad++ вместо emacs, вы вместе с преимуществами получаете и недостатки этого перехода - теряете кучу возможностей emacs. Да, сейчас, пока Вы emacs только что увидели, Вы еще не знаете, что это за возможности, не говоря о том, что не привыкли ими пользоваться. А я уже привык. Я в случае такой замены их, натурально, потеряю. А чтобы иметь и то, и другое, мне надо дописать недостающую функциональность либо в notepad++, либо в emacs. Второе, прямо скажем, на порядки проще, поскольку и требуется меньше, и сама функциональность проще, и способ расширения куда более продуман (что и является причиной того, что у emacs эта самая функциональность есть).

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

[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]

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

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

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

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

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

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

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

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

[besm6.livejournal.com]

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

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

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

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

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

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

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