Так значит "или этих помыть, или новых сделать" -- с чего все начиналось, чтобы продолжать в контексте
Aku-Aku
мысли) результат послежних дискусий,
моих и человека под ником ЖЖ -- besm6 в разделе "Где наша свобода?"
http://vitus-wagner.livejournal.com/289017.html
besm6
2008-07-10 07:51 am UTC
\\"Я же постоянно меняю системы, нахожусь в поиске более лучших, и
пусть даже текущий мой выбор не удовлетворяет меня полностью"
А я использую систему, которую можно улучшить. Не поменять на другую,
с ее достоинствами и недостатками, а именно улучшить - устранить
недостаток, сохранив достоинства.
gineer
2008-07-10 01:28 pm UTC
Все же опцию находящуюся на четвертом уровне меню, сложно назвать
легко доступной и просто находимой. :)
Универсальность тоже имеет свои недостатки.
gineer
2008-07-11 06:41 am UTC
Всетаки -- это специальизированная задача, и решать её лучше
специальными средствами, а не полагатся на вроде бы реализацию с
использованием универсальных... а вы как думаете?
besm6
2008-07-11 10:41 am UTC
На самом деле отсутствие палитры в емаксе объясняется всего лишь тем,
что такого виджета для него никто пока не сделал. Сделаете - будет,
кто б возражал? Я, кстати, даже подозреваю, почему не сделано. Потому
что тем, кто может, оно нафиг не надо, у них есть куда более
интересные задачи, чем по часу в день рихтовать цвета шрифтов. А раз в
полгода можно и xcolorsel рядышком запустить, все равно любая
стандартная палитра для цвета шрифта, в отличие от цвета фона,
малопригодна - разница между полем и тонкой линией...
gineer
2008-07-11 12:56 pm UTC
Так что это какраз вы путаете... привычное вам, с понятным любому.
Это какраз илюстрация к тому о чем я говорил.
Эффект второй системы... когда человек вростает в среду, которая вроде
бы удовлетворяет все его потребности (может и правда удовлетворяет, но
вопрос не в этом), но с другой стороны исподволь, незаметно, приучает
к некоторому конкретному взгляду на вещи, просто потому что с одной
стороны возможности, а с другой ограничения... и хотя последние и
обоснованы могут быть, но с течением времени они просто становятся
унаследованными ограничениями, тормозящими дальнейшее развитие.
И что касается цвета шрифтов конкретно... вот вы сделали оговорочку
"часу в день рихтовать цвета шрифтов", а я вам продемонстрирую что она
значит.
По час в день -- это только потому что в этой системе именно эта
задача достаточно сложная, трудоемкая и действительно может
потребовать часа в день, а то и больше.
Но вот в той системе о которой говорю я -- нотепад++.
Это все очень просто и интуитивно, и потому я могу не то что
специально настраивать (игратся с цветом шрифтов), а даже просто по
ходу работы, зайти в диалог и поменять, что хочу и так, как ИМЕННО
СЕЙЧАС мне кажется удобным/нужным.
Вы понимаете что это значит?
У меня появляется дополнительная степень свободы, когда не я завишу от
системы, от её унаследованных ограничений, а наоборот, могу свободно
использовать её приимущества.
“границы моего языка – это границы моего мира” Витгенштейн
besm6
2008-07-11 09:48 pm UTC
"У меня появляется дополнительная степень свободы, когда не я завишу
от системы, от её унаследованных ограничений, а наоборот, могу
свободно использовать её приимущества."
Э, нет. Если Вы выбираете notepad++ вместо emacs, вы вместе с
преимуществами получаете и недостатки этого перехода - теряете кучу
возможностей emacs. Да, сейчас, пока Вы emacs только что увидели, Вы
еще не знаете, что это за возможности, не говоря о том, что не
привыкли ими пользоваться. А я уже привык. Я в случае такой замены их,
натурально, потеряю. А чтобы иметь и то, и другое, мне надо дописать
недостающую функциональность либо в notepad++, либо в emacs. Второе,
прямо скажем, на порядки проще, поскольку и требуется меньше, и сама
функциональность проще, и способ расширения куда более продуман (что и
является причиной того, что у emacs эта самая функциональность есть).
Другое дело, что для меня функциональность палитры не настолько ценна,
чтобы потратить пару часов на изучение того, как ее туда будет
наиболее правильно встроить, и еще полчаса на ее создание. У меня есть
более интересные задачи.
gineer
2008-07-10 09:49 am UTC
Можете оценивать это как максимализм.
Но я все же рассчитываю создать свою систему, максимально
соответствующую именно моим теперешним воззрениям на то какой она
должна быть, чем расширять уже существующую.
Всетаки проблема невозможности дальнейшей модернизации в виду
несовместимости её с существующими техническими решениями -- это не
такая простая проблема.
Унаследованый код -- это и преимущество, и баласт.
Тогда как наново написаный -- это только приемущество, хоть и с риском
провала.
besm6
2008-07-10 12:11 pm UTC
\\"Унаследованый код -- это и преимущество, и баласт.Тогда как наново
написаный -- это только приемущество, хоть и с риском провала."
Засада в том, что пока наново написанный код еще не написан, он еще не
преимущество, а только риск провала. А как только он написан, он
становится унаследованным...
gineer
2008-07-10 01:56 pm UTC
//А вот это из предыдущих слов не следовало.
Это вроде как рефрен общей темы. "Или этих помыть, или новых сделать"
\\Засада в том, что пока наново написанный код еще не написан, он еще
не преимущество, а только риск провала.
ubi nihil nihil... нет кода, нет риска
Проблема не в риске. Гораздо сложнее придумать что-то действительно
нетривиальное и стоящее реализации. Зато тривиальных поделок с
претензией на иновационность -- пруд пруди.
//А как только он написан, он становится унаследованным...
А это дургой вопрос.
Почему даже только что написанный код превращается в баласт?
И никакие палеативы типа "литературного", "быстрого", модульного или
еще какого... ответа на него не дает.
ИМХО, в консерватории нужно что-то менять...
besm6
2008-07-10 04:22 pm UTC
\\"Гораздо сложнее придумать что-то действительно нетривиальное и
стоящее реализации."
Мне кажется, условие "нетривиальное" тут лишнее. Тривиальность сама по
себе ничем не плоха, и часто даже наоборот. А вот претензия на
инновационность - как раз нехороший признак. Ага, в частности поэтому
я предпочитаю учиться не новому, а хорошо развивающемуся старому. Вот
правда, слово "хорошо" тут ключевое (emacs, скажем, развивается
хорошо, а мозилла - плохо), а четкого определения ему я дать не могу.
"Почему даже только что написанный код превращается в баласт?"
А вот этого я не утверждал. Унаследованный код является балластом (да,
если можно, пишите, пожалуйста, это слово с двумя "л", а то у меня
"врожденная грамотность", и я дергаюсь; то же касается слов
"паллиатив" и "инновационность") не по определению, а как правило.
Но - да, пожалуй, как правило таки сразу. И даже до того, как будет
дописан. Потому что если его там достаточно немалое количество, он
успевает показать проблемы в архитектуре еще в процессе его написания.
gineer
2008-07-11 06:54 am UTC
//Мне кажется, условие "нетривиальное" тут лишнее. Тривиальность сама
по себе ничем не плоха, и часто даже наоборот.
Какраз это главное условие, просто мы видимо поразному понимаем это
слово. Для меня тривиальность -- не синоним простоты.
Есть два вида истины - тривиальная, которую отрицать нелепо, и
глубокая, для которой обратное утверждение - тоже глубокая истина.(с)
Нильс Бор
Лично я, вижу причину такой ситуации (с кодом) в том, что существует
барьер использования в виде бинарного кода, в который компилируется
текстовое представление, и который практически не доступен для
просмотра и редактирования.
Ну а что до проблем в архитектуре -- это общее место, не суть
проблемы. Опять же, проблема в сложности... и существующие средства
практически никак не помагают с нею боротся, особенно на таком
архитектурно-абстрактном уровне.
besm6
2008-07-11 10:20 am UTC
Ой, боюсь Бора Вы зря привели. Насколько я понимаю, к его пониманию
тривиальности мое гораздо ближе, чем Ваше... Не могу, к сожалению,
сказать, что я понял, что Вы понимаете под тривиальностью, но
высказыванию Бора Ваши слова отчетливо противоречат.
\\"Опять же, проблема в сложности... и существующие средства
практически никак не помагают с нею боротся, особенно на таком
архитектурно-абстрактном уровне."
Ну нет, помогают. Чем выше уровень языка, тем меньше дистанция между
задачей и мозгом. Мне скорее представляется, что проблема не в
сложности задач, а в неопределенности базовых понятий. Вплоть до того,
что человек может четко сформулировать, чего он хочет, но не может
этого понять. В результате после выполнения сформулированной задачи
выясняется, что нужно было не это.
gineer
2008-07-11 01:28 pm UTC
Мне нравится тот тон который преобрела наша дискусия. Если бы она еще
была чуточку поконкретнее, мы кажется могли бы дойти здесь и до каких-
то важных, стоящих выводов.
Все же не хотелось бы чтобы это осталось в рамках напоминающих
холиварные, что вы мне доказываете как хорош Эмакс (не сомневаюсь --
хорош), а я по-ламерски вам противоречу и навязываю что-то свое.
Не хотелось бы продолжать ТОЛЬКО на таком уровне.
//Ой, боюсь Бора Вы зря привели.
Это не новость. (по крайней мере для меня)
Что когда дискусию ведут образованные люди, то разночтения идут не в
использовании слов/терминов, а на гораздно более глубоком уровне
оттенков их понимания.
Потому я не думаю что мы уж так поразному понимаем слово
"тривиальность".
Для меня же это высказывание Бора, это дифиницыя отличия обыденной
логики и здравого смысла и научной, рациональной.
Скажем как илюстрация к выссказыванию.
"Солнце встает на востоке" -- тривиальная обыденная истина.
"Земля вращается вокруг Солнца" -- уже глубокая, неочевидная, дающая
нетривиальные вывод от её осмысления.
Из за того, что между исходным и реально работающим бинарным кодом
существует много промежуточных слоев, затрудняющих в конечном счете, а
не упрощающих работу с низкоуровневым,
получается что вся сложность и негибкость оседает на более низких
уровнях, и консервируется там.
Тут уже хозяин блога, Витус. Упоминал о ТРИЗ (теории решения
изобретательских задач) где-то.
А в ней есть один метода решения задач -- ИКР -- поиском Идеального
Конечного Результата.
Так вот в нашем случае за такой конечный результат можно взять какраз
описанную вами историю, когда вы без использования дополнительных
высокоуровневых средств, смогли найти и сделать то что вам нужно.
Но согласитесь -- это не есть обычный способ действия. В этом-то и
проблема.
Работа напрямую с бинарным представлением, для сколь-нибудь сложных
задач -- нетривиальна.
И наоборот, работа с тривиальными, простыми для представления
(текстовыми) средставми, приводит к нетривиальным проблемам на пути их
последовательного преобразования в бинарные -- расстояние до ИКР
получается очень большое, и потому результат заведомо неэффективный.
//Чем выше уровень языка, тем меньше дистанция между задачей и
мозгом.
Я понима о чем вы говорите -- это достаточно распространенное
мнение.Есть еще синонимичное, ИМХО, "любую задачу можно решить на
любом языке".
Но тем не менее считаю что оно ошибочное -- уводит от решения реальных
задач в страну ничем не связанных, ничем не ограниченных абстрактных
фантазий. Среда обитания "архитектурных астронавтов".
//Мне скорее представляется, что проблема не в сложности задач, а в
неопределенности базовых понятий.
Ооо... это уже мы с вами возвращаемся к тому с чего начали. К спору
Бора с Эйншетйном.
Тогда Альберт тоже предлагал определить базовые понятия.
В таком случае я использую хрестоматийный ответ Нильса, чтобы ответить
вам... думаю нет нужды его цитировать.
besm6
2008-07-12 03:52 am UTC
Здесь тривиальной истиной названа эмпирическая, а нетривиальной -
полученная в результате более чем одноуровневого осмысления эмпирики.
(Відповісти)(Рівнем вище)(Гілка)
gineer
2008-07-12 11:25 am UTC
//(порезано на несколько комментов, а то не лезет)
да, мы как-то много здесь нафлудили :)
возможно стоит поменячть место дислокации?
//Начнем с того, что "рацио" - это ученое название для здравого
смысла, и противопоставление их выглядит несколько странно...
обыденному, обывательскому здравому смыслу, тому который позволяет
верить в возможность вечного двигателя и не верить в движение Земли
вокруг Солнца -- противостоит.
//Здесь тривиальной истиной названа эмпирическая, а нетривиальной -
полученная в результате более чем одноуровневого осмысления эмпирики.
Это уже философские изыски. Мышей абстрактных дефиницый можна делить
до любых желаемых приделов, отыскивая все более и более "глубокие"
градации и дихотомии.
Я просто привел конкретизирующий мое понимание пример.
besm6
2008-07-16 03:06 pm UTC
Если такой смысл называть здравым, то да. Но тогда надо вернуться на
пару циклов назад и начать с уточнения терминологии.
besm6
2008-07-12 03:53 am UTC
Я как раз сделал это без использования низкоуровневых средств. К
низкому уровню (работающему бинарному коду) я результат применил, и он
сработал. Это важная разница.
\\Из за того, что между исходным и реально работающим бинарным кодом
существует много промежуточных слоев, затрудняющих в конечном счете, а
не упрощающих работу с низкоуровневым,
С имеющимся низкоуровневым кодом затрудняет работу несоответствие
существующей компьютерной архитектуры человеческой интуиции, а вовсе
не промежуточные слои. Если бы низким уровнем была не машина Тьюринга,
а лисп-машина, работать с ним было бы куда легче. Практически в любой
лисповской программе непосредственно применяют пять из шести
низкоуровневых функций (eval не в любой). Потому что они достаточно
близки к интуиции, чтобы над ними не приходилось делать надстроек. Все
надстройки - проблемно-ориентированы, т.е. соответствуют декомпозиции
задачи.
\\И наоборот, работа с тривиальными, простыми для представления
(текстовыми) средставми, приводит к нетривиальным проблемам на пути их
последовательного преобразования в бинарные -- расстояние до ИКР
получается очень большое, и потому результат заведомо неэффективный.
Прежде чем сказать слово "неэффективный", хорошо бы привести хотя бы
параметры, по которым измеряется эффективность, не говоря уже о
критериях. Когда я пользуюсь языком высокого уровня (нет, не "object-
oriented assembly language" C++, а высокого), с моей кочки зрения
расстояния от текстового представления до результата почти нет. Меня
бинарное не интересует. Я беру язык с интроспекцией, и вижу
представление в терминах этого же языка. С моей кочки зрения язык с
интроспекцией не переводит программу на машинный язык, а преобразует
машину Тьюринга в лисп-машину, перл-машину, питон-машину, смоллток-
машину и т.п. Существует очень узкое количество мест, где у меня есть
основания спуститься уровнем ниже. Я тогда спускаюсь, пишу расширение
языка, которое поднимает это место до уровня абстракции моей машины, и
снова забываю, что железо у меня полупроводниковое :-) Кстати, да, Вы
же низким уровнем называете отнюдь не работу с энергетическими
уровнями электронов, а вовсе даже нечто уровней на пять повыше... А
почему на пять, а не на семь?
Получается достаточно эффективно в доступных условиях. Кстати, вопреки
распространенному мнению, программа на языке типа перла или питона
зачастую куда эффективнее аналога на C/C++. Просто потому что
нижележащие алгоритмы и их реализации вылизаны куда более умными
людьми, чем тот маньяк, который прикладную программу на C (и тем более
на C++) писать пытается. Не путать прикладную программу с
низкоуровневой библиотекой. Низкий уровень у нас на C писан, с
фрагментами (собственно шифрование и длинная арифметика) на
ассемблере.
gineer
2008-07-12 12:09 pm UTC
//К низкому уровню (работающему бинарному коду) я результат применил,
и он сработал. Это важная разница.
Ну вы же не набивали напрямую биты с байтами.
Думаю понятно что под низким уровнем я здесь имел в виду самые простые
средства представления и работы с информацией.
//С имеющимся низкоуровневым кодом затрудняет работу несоответствие
существующей компьютерной архитектуры человеческой интуиции, а вовсе
не промежуточные слои.
А какая соответствует?
Это вас снова потянуло на "эзотерику", в сторону от серьозного
разговора.Можна сколько угодно спорить с пеной у рта, какая
архитектура лучше, правильные, эзотеричней.
Но это будет уход от темы в дебри иделизированных абстракций --
рассуждения о сферическом коне. С игнорированием того, что ВСЕ
архитектуры, ограниченны здесь и сейчас возможностями технологии и
законами реального мира.
И именно преодоление этих ограничений и есть ТА важная задача, которую
нужно решать... а спорить об идеальных материях будем потом, когда в
следствие развития технологий и интелекта сможем представить и
замоделировать любого сферического коня на выбор... :)
//Если бы низким уровнем была не машина Тьюринга, а лисп-машина,
работать с ним было бы куда легче.
Если бы, да кабы...
Думаю вы и сами понимаете, что совсем не спроста получила развитие
именно такая архитектура как сейчас. Кстати, и машину Тьюринга она
напоминает весьма приблизительно, с многими упрощениями и соглашениями
навязанными технологией, а не размышлениями об идеальном.
Вспомнипте Дийкстру -- как не крути, а все ж он не прав.
besm6
2008-07-16 03:24 pm UTC
\\Ну вы же не набивали напрямую биты с байтами.Думаю понятно что под
низким уровнем я здесь имел в виду самые простые средства
представления и работы с информацией.
Непонятно. Более того, стало совсем непонятно.
\\А какая соответствует?
Ну вот лисп-машина, скажем, соответствует гораздо лучше. При ровно тех
же выразительных возможностях.
Я даже не про то, что лисп-машину человеку понять легче, чем машину
Тьюринга. Ровно наоборот. Но лисп-машиной человеку проще
воспользоваться для решения своих задач. Ну, выходящих за пределы
замены компьютером счет. Система понятий, в которых человек об этих
задачах рассуждает, ближе к лисп-машине.
Есть еще smalltalk-машина. Все более близкое к задачам, видимо, будет
уже проблемно-ориентированным.
И я бы сказал, что проблема не в том, что железо у нас такое, какое
есть. Проблема в том, что людей учат в парадигме этого железа. В то
время как (уметь) мыслить в этой парадигме нужно очень немногим - тем,
кто на этом будет реализовывать лисп-машину или смоллток-машину. Ну,
или там перл-машину или хотя бы юникс-машину. Ан нет, лемминги учат
object-oriented assembly language C++ вместо того, чтобы учиться хотя
бы понимать постановки задач. Ага, потому что C++ слишком сложен для
того, чтобы программист им пользовался, и в результате язык пользуется
программистом - программист способен лишь стандартным образом
комбинировать стандартные шаблоны, и понимать задачи ему становится
только вредно, поскольку готовых шаблонов под настоящие задачи у него
нет. И результатом является то, что изложено в посте...
besm6
2008-07-12 03:53 am UTC
\\//Чем выше уровень языка, тем меньше дистанция между задачей и
мозгом.
\\Я понима о чем вы говорите -- это достаточно распространенное
мнение.Есть еще синонимичное, ИМХО, "любую задачу можно решить на
любом языке".
Ой, нет, не понимаете... Это не синонимичное, это прямо
противоположное... Решение любой задачи можно свести к выражению на
любом (Тьюринг-полном, если мы о программировании) языке. Готовое
решение. Но не решить.
\\/Мне скорее представляется, что проблема не в сложности задач, а в
неопределенности базовых понятий.
\\Ооо... это уже мы с вами возвращаемся к тому с чего начали. К спору
Бора с Эйншетйном.
\\Тогда Альберт тоже предлагал определить базовые понятия.
\\В таком случае я использую хрестоматийный ответ Нильса, чтобы
ответить вам... думаю нет нужды его цитировать.
И совершенно зря. Потому что Бор сталкивался с реальной сложностью
природы, а у нас задача стоит в том, чтобы результат был понятен
человеку (чтобы человек мог пользоваться системой для решения своих
задач). Человек в принципе может решать только такие задачи,
постановку которых он может понять. Т.е. в человекопонятных терминах
постановка задачи проста. Как правило (исключения мне известно два -
великая теорема Ферма и проблема четырех красок; понятно, что их может
быть больше, но это нетипично) у просто поставленной задачи решение
тоже сравнительно простое. Если понятийный аппарат, привлекаемый к
решению, соответствует задаче и человеческому мышлению.
Ну и не надо путать определенность с фиксацией аксиоматики...
Определенность - это "мы понимаем, с чем работаем", а фиксация
аксиоматики - "мы догматизируем то, с чем работаем". Тут в другой
ветке комментов (или уже все-таки по выделении в другой пост, не
помню) Витус приводил яркий пример непонимания современным
разработчиком поставленной задачи. В результате чего оный разработчик
пытается решать НЕ ТУ задачу. Он видит в постановке задачи знакомые
слова, по ассоциации хватается за уже известный ему шаблон, и
предлагает его в качестве решения. На большее он оказывается не
способен. Ну ладно, Витус заказчик IT-грамотный, он эту булочку кушал
уже не раз и способен сходу увидеть разницу между двумя задачами -
своей и решаемой шаблоном... Но беда-то в том, что ни один из
разработчиков, якобы владеющих инструментом, не смог предложить ему
решения его задачи... Причем только один, кажется, признал, что в
такой мере инструментом не владеет (но он как раз и не утверждал, что
этот инструмент позволяет все необходимое достаточно легко). Остальные
просто понять задачу не смогли. А уж куда проще задача-то...
gineer
2008-07-12 02:35 pm UTC
//Ой, нет, не понимаете...
Пожалуй я действительно неудачно написал.
Но все равно не ваша правда. Это мы влезли уже в такую область где
нужно много осторожнее и покорректнее высказыватся. А мы пока рубим
друг другу аргументы с плеча.
Вот у вас и у меня тут многое намешано, давайте разделять.
1) Нет низкого и высокого уровня языка, а есть: соответствует ли он
проблемной области? достаточно ли он мощный и выразительный?
для КАЖДОЙ отдельной задачи нужно определятся с обеими этими
вопросами.
Если не них не отвечать -- попадаеш в ловушку некорректного обобщения.
Начинаеш некртично переносить наработки в одной области в другую.
2) Возможность решить данную задачу вообще. Вы ведь знаете что далеко
не все задачи решаемы, и очень много задач тяжело решаемых.
Плюс то несомненое, что не учитывается в машине Тьюринга -- нам нужно
не только чтобы задача теоритически решалась, но и могла быть реально
просчитана на компютерах современной мощности, а не за время до
охлаждения белого карлика. :)
3) Вопрос который присутствует неявно. Програмирование это не только
математика, но еще и инженерия. И тут тоже еще очень много чего неясно
и очень сложно.
Можна продолжать и дельше... но сами видите, к чему может привести
излишнее углубюление в дефиниции и класификации...
Давайте говорить О ГЛАВНОМ.
//Потому что Бор сталкивался с реальной сложностью природы, а у нас
задача стоит в том, чтобы результат был понятен человеку (чтобы
человек мог пользоваться системой для решения своих задач).
А челоек что, уже не часть Природы???
И разве задачи стоящие перед програмистом не суть одно из проявлений
самой природы?
//Человек в принципе может решать только такие задачи, постановку
которых он может понять.
Не пойдет.
С таким успехом мы сейчас еще и в когнитивную психологию залезем,
пробуя установить как же человек понимает...
Это дебри, это болото, это какраз то что происходит когда пытаются
решить очень сложные фундаментальные задачи В ЛОБ, используя
стереотипные методы, понадеявшись на их "мощность" и всеядность...
Вместо того, чтобы отойти в сторонку и подумать, постаратся осмыслить,
обобщить задачу, подойти у другой стороны.
Нет. Делабт как всегда и... или обявляют задачей нерешаемой или
неактуальной, неинтересной (как вы например сделали с вопросом о
палитре)
Или же зарываются в частности.
besm6
2008-07-16 03:53 pm UTC (посилання)
\\А челоек что, уже не часть Природы???И разве задачи стоящие перед
програмистом не суть одно из проявлений самой природы?
Нет. Сложность задач, стоящих перед программистом, в норме по крайней
мере на порядок ниже сложности задач, стоявших перед Нильсом Бором.
Ибо это - задачи, понятные обычному человеку, а вовсе не задачи,
которые перед ним как перед частью Природы, могут стоять.
\\или обявляют задачей нерешаемой или неактуальной, неинтересной (как
вы например сделали с вопросом о палитре)
А что, задача о палитре должна была стать мне интересной просто по
факту того, что Вам хочется палитру?
С неактуальными - другой вопрос. "Не актуально" обычно означает "я не
готов потратить на эту задачу то количество ресурсов, в которое я
оцениваю ее решение". Часто даже не "в которое я оцениваю", а "менее
чем которым точно не отделаться", что обычно куда правдоподобнее, и от
чего "отойти в сторонку и подумать" не спасает - действительно не
отделаться.
\\С таким успехом мы сейчас еще и в когнитивную психологию залезем,
пробуя установить как же человек понимает...
Я бы сказал, что с этого надо начинать, если серьезно браться за
задачу. А Вы хотите закончить, туда не залезая...
Aku-Aku
> природы, а у нас задача стоит в том, чтобы результат был понятен
> человеку (чтобы человек мог пользоваться системой для решения своих
> задач). Человек в принципе может решать только такие задачи,
> постановку которых он может понять. Т.е. в человекопонятных терминах
> постановка задачи проста. Как правило (исключения мне известно два -
> великая теорема Ферма и проблема четырех красок; понятно, что их может
> быть больше, но это нетипично) у просто поставленной задачи решение
> тоже сравнительно простое. Если понятийный аппарат, привлекаемый к
> решению, соответствует задаче и человеческому мышлению.
>
"человек может понять только просутую задачу", "простая задача может
быть решена".
Вокруг понятия "простоты" которое вы нигде не упоминаете и не
определяете.
Это пример порочной логики, на которой как праило и строятся догматизм
и обывательский здравый смысл.
Готовый отвечать на все вопросы "а опчему так? -- а потому что так" и
не видеть того что ответом здесь и не пахнет.
> Ну и не надо путать определенность с фиксацией аксиоматики...
> Определенность - это "мы понимаем, с чем работаем", а фиксация
> аксиоматики - "мы догматизируем то, с чем работаем".
>
автоматизма, но и очень мощный инструмент творения нового.
Например та же компютерная технология невозможна без аксиоматики
заложенной в её основу, той же машины Тьюринга и т.п.
>
> besm6
> 2008-07-16 03:53 pm UTC (посилання)
> \\А челоек что, уже не часть Природы???И разве задачи стоящие перед
> програмистом не суть одно из проявлений самой природы?
>
> Нет. Сложность задач, стоящих перед программистом, в норме по крайней
> мере на порядок ниже сложности задач, стоявших перед Нильсом Бором.
> Ибо это - задачи, понятные обычному человеку, а вовсе не задачи,
> которые перед ним как перед частью Природы, могут стоять.
>
Я вот могу наоборот утверждать -- что сложнее, потому как Бору не
приходилось самому конструировать предмет своих исследований,
заботится о его повторяемости (безглючной работк),
интеграции с другими элементами природы. Представляете себе
програмиста програмирующего электрон. :)
> \\или обявляют задачей нерешаемой или неактуальной, неинтересной (как
> вы например сделали с вопросом о палитре)
>
> А что, задача о палитре должна была стать мне интересной просто по
> факту того, что Вам хочется палитру?
>
естественна. И почему у человека-разработчика не должно быть
стремления к чему-то еще более удобному?
Почему, как получается, вы считаете что текстовая консоль, хоть и
несколько усовершенствованная, является предельной и идеальной
реализацией интерфейса пользователя?
> \\С таким успехом мы сейчас еще и в когнитивную психологию залезем,
> пробуя установить как же человек понимает...
>
> Я бы сказал, что с этого надо начинать, если серьезно браться за
> задачу. А Вы хотите закончить, туда не залезая...
проблемы. Покамест ИМХО ничего такого не видно.
Artem Chuprina
>> И совершенно зря. Потому что Бор сталкивался с реальной сложностью
>> природы, а у нас задача стоит в том, чтобы результат был понятен
>> человеку (чтобы человек мог пользоваться системой для решения своих
>> задач). Человек в принципе может решать только такие задачи,
>> постановку которых он может понять. Т.е. в человекопонятных терминах
>> постановка задачи проста. Как правило (исключения мне известно два -
>> великая теорема Ферма и проблема четырех красок; понятно, что их
>> может быть больше, но это нетипично) у просто поставленной задачи
>> решение тоже сравнительно простое. Если понятийный аппарат,
>> привлекаемый к решению, соответствует задаче и человеческому
>> мышлению.
A> Какраз не все так однозначно. Это у вас получается замкнутый круг из
A> "человек может понять только просутую задачу", "простая задача может
A> быть решена".
A> Вокруг понятия "простоты" которое вы нигде не упоминаете и не
A> определяете.
A> Это пример порочной логики, на которой как праило и строятся догматизм
A> и обывательский здравый смысл.
A> Готовый отвечать на все вопросы "а опчему так? -- а потому что так" и
A> не видеть того что ответом здесь и не пахнет.
А вот можно, чтобы предметно, пример сложной задачи для программиста? В
процессе просьба не путать "сложное" с "муторным"... Сложность должна
быть именно на уровне алгоритма (но можно, скажем, с условием
"real-time"). И при этом она должна быть задачей для программиста, а не
для математика (задачи взлома шифров и систем с открытым ключом, к
примеру - математические, программисту на нынешнем этапе там ловить
нечего) или другого специалиста в совершенно другой области.
Я понимаю, что задал тем самым задачу с плохим критерием решения, но все
же. Хотелось бы примера для дальнейшего размышления.
>> Ну и не надо путать определенность с фиксацией аксиоматики...
>> Определенность - это "мы понимаем, с чем работаем", а фиксация
>> аксиоматики - "мы догматизируем то, с чем работаем".
A> Как по мне, аксиоматика -- это не только понимание доведенное до
A> автоматизма, но и очень мощный инструмент творения нового. Например
A> та же компютерная технология невозможна без аксиоматики заложенной в
A> её основу, той же машины Тьюринга и т.п.
Еще как возможна... Тому примером будет, скажем, объектная парадигма
как таковая - ведь это методика решения задач, для которых
математический аппарат не разработан, и аксиоматики нет. Если б ее еще
не пытались использовать для задач, которые лень подумать...
Там, собственно, полезна была не аксиоматика (компьютерная архитектура,
заметим, хорошо отображается вовсе не на машину Тьюринга, а на конечный
автомат), а идея четкого определения понятия "как сделать". Каковых
определений было сделано несколько, и все работают. А аксиоматика нужна
всего лишь для доказательства эквивалентности - т.е. по сути для того,
чтобы была уверенность в том, что мы определили именно то, что хотели
определить.
На практике же аксиоматика - инструмент не творения нового, а развития
и/или укрепления достигнутого. Понимания, кстати, не требующий, такой
вот парадокс...
>> \\А челоек что, уже не часть Природы???И разве задачи стоящие перед
>> програмистом не суть одно из проявлений самой природы?
>>
>> Нет. Сложность задач, стоящих перед программистом, в норме по
>> крайней мере на порядок ниже сложности задач, стоявших перед Нильсом
>> Бором. Ибо это - задачи, понятные обычному человеку, а вовсе не
>> задачи, которые перед ним как перед частью Природы, могут стоять.
A> Не согласен. По какому-такому критерию сложности?
A> Я вот могу наоборот утверждать -- что сложнее, потому как Бору не
A> приходилось самому конструировать предмет своих исследований,
A> заботится о его повторяемости (безглючной работк),
A> интеграции с другими элементами природы. Представляете себе
A> програмиста програмирующего электрон. :)
Ой, вот не надо. Конструировать предмет - не приходилось (зато
приходилось конструировать измерители пока-неизвестно-чего), а все
остальное - в полный рост. Причем повторяемости (результатов
эксперимента) ему приходилось добиваться в условиях, когда неизвестно,
что еще может повлиять. Программисту все же известно, другое дело, что
этого "что еще" может быть больше, чем он способен окинуть сознанием. А
вот нефиг писать на языках с побочными эффектами, тогда будет проще :-)
И кстати, об интеграции с другими "элементами природы" заботятся очень
немногие программисты. Это тоже большая и больная тема, и ее Витус тоже
нежно любит.
>> \\или обявляют задачей нерешаемой или неактуальной, неинтересной (как
>> вы например сделали с вопросом о палитре)
>>
>> А что, задача о палитре должна была стать мне интересной просто по
>> факту того, что Вам хочется палитру?
A> С точки зрения той же когнитивной психологии -- да. Она более удобна и
A> естественна. И почему у человека-разработчика не должно быть
A> стремления к чему-то еще более удобному?
Это не с точки зрения когнитивной психологии, а Вам так кажется. Я там
недаром обратил внимание на разницу между площадной фигурой и тонкой
линией... Все палитры - площадные, и глядя на них, представление о том,
как будет выглядеть тонкая линия, всегда ошибочно. Вот если бы были три
_физические_ ручки (нет, не RGB, а либо LAB, либо HSB - RGB не
соответствует человеческому восприятию цвета) и сэмпл, причем сэмпл в
контексте - это да, это было бы "с точки зрения когнитивной психологии".
Правда, LAB'у при этом надо было бы учить - интуитивно схватывается
только HSB, он намного лучше соответствует "сознательной" части
восприятия цвета (LAB - "рецепторной"). Зачем физические ручки? Чтобы
можно было крутить две одновременно, но с разной скоростью (и, вероятно,
в разные стороны) - обычно это яркость и насыщенность либо насыщенность
и тон.
A> Почему, как получается, вы считаете что текстовая консоль, хоть и
A> несколько усовершенствованная, является предельной и идеальной
A> реализацией интерфейса пользователя?
А кто Вам сказал, что я так считаю? Я считаю, что для работы с
_текстом_ она - лучшее, что сейчас есть. Нет, не думаю, что идеал. Но
она пригодна для работы с текстом лучше, чем все распространенные на
данный момент компьютерные интерфейсы для работы с графикой. Текстовая
консоль превзошла перо и бумагу, а интерфейсы работы с графикой до
уровня карандаша и бумаги пока не доросли. При том, что по
_возможностям_ редактирования изображения средства работы с графикой
карандаш и бумагу превзошли куда сильнее, чем текстовая консоль - перо и
бумагу. Но вот вменяемого интерфейса для фотошоповских кривых, скажем,
я себе представить пока не могу.
>> \\С таким успехом мы сейчас еще и в когнитивную психологию залезем,
>> пробуя установить как же человек понимает...
>>
>> Я бы сказал, что с этого надо начинать, если серьезно браться за
>> задачу. А Вы хотите закончить, туда не залезая...
A> Да, но только если будет видно что именно там находится решение
A> проблемы. Покамест ИМХО ничего такого не видно.
Не, решение не там. Там - необходимые для создания решения сведения.
Начального уровня...
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: r...@jabber.ran.pp.ru
Реляционная база данных - это не единственный способ сделать дурацкий поиск.
Victor Wagner
Aku-Aku
Это какраз вотчина програмиста, и его хрест.
//Сложность должна быть именно на уровне алгоритма (но можно, скажем,
с условием "real-time").
Построение алгоритма на данный момент уже не является основной задачей
програмиста. Конечно это один из главных приемов его работы, но так же
как и у инженера, у него теперь еще и куча других задач: применение
стандартов, использование сложных типизированных компонентов,
поддержание работоспособности сложных прикладных и специализированных
сред.
>
> Еще как возможна... Тому примером будет, скажем, объектная парадигма
> как таковая - ведь это методика решения задач, для которых
> математический аппарат не разработан, и аксиоматики нет. Если б ее еще
> не пытались использовать для задач, которые лень подумать...
>
И все равно, если подумать то объекты -- это аналог используемого в
математике понятия множество.
> А аксиоматика нужна
> всего лишь для доказательства эквивалентности - т.е. по сути для того,
> чтобы была уверенность в том, что мы определили именно то, что хотели
> определить.
>
Язык если хотите. Ведь и алгоритмические языки програмирования ведут
свой род от Планклюаля Тьюринга.
> На практике же аксиоматика - инструмент не творения нового, а развития
> и/или укрепления достигнутого. Понимания, кстати, не требующий, такой
> вот парадокс...
>
>
> Это не с точки зрения когнитивной психологии, а Вам так кажется. Я там
> недаром обратил внимание на разницу между площадной фигурой и тонкой
> линией...
В нотепад++ изменения цвета *непосредственно* отображаются в видимый
результат, и не просто в каком-то превью, а именно в том тексте с
которым вы сейчас работаете, так же как и размер и начертание шрифта.
Вот видите, опять у вас оговорка происходящая именно из вашей практики
работы, именно с Эмаксом.
Я это подчеркиваю не ради флейма, а только для того чтобы более
наглядна и понятна была мысль, что МЫ все зависим от того инструмента
который используем, настолько, что иногда начинаем воспринимать его
совершенно локальные достоинства и ограничения, как к
общеопределяющие.
Ну а кликакть все равно удобнее в площадную палитру.
Или будете утверждать что набивать название цвета текстом удобнее? :)
Artem Chuprina
>> А вот можно, чтобы предметно, пример сложной задачи для программиста?
A> Пример? Просто --> ИИ.
A> Это какраз вотчина програмиста, и его хрест.
ИИ не существует :-)
A> //Сложность должна быть именно на уровне алгоритма (но можно,
A> скажем, с условием "real-time").
A> Построение алгоритма на данный момент уже не является основной
A> задачей програмиста. Конечно это один из главных приемов его работы,
A> но так же как и у инженера, у него теперь еще и куча других задач:
A> применение стандартов, использование сложных типизированных
A> компонентов, поддержание работоспособности сложных прикладных и
A> специализированных сред.
Ой, вот не надо путать... В перечисленном списке есть один момент,
который таки да, частая задача (если сформулировать аккуратно и
понадеяться, что Вы именно это и имели в виду), один - специфическая, и
один - вообще не задача.
>> Еще как возможна... Тому примером будет, скажем, объектная парадигма
>> как таковая - ведь это методика решения задач, для которых
>> математический аппарат не разработан, и аксиоматики нет. Если б ее еще
>> не пытались использовать для задач, которые лень подумать...
A> Ну, не все сразу.
A> И все равно, если подумать то объекты -- это аналог используемого в
A> математике понятия множество.
Ой, нет... Отобразить объекты на множества можно, но при этом придется
выкинуть девять десятых парадигмы. В ООП ключевое понятие - "send
message", более известное как "call method", аналога которого в теории
множеств нет. На теорию множеств худо-бедно ложится типизация.
>> А аксиоматика нужна
>> всего лишь для доказательства эквивалентности - т.е. по сути для того,
>> чтобы была уверенность в том, что мы определили именно то, что хотели
>> определить.
A> Не только. Она еще и дает терминологию. Базу для понимания. Язык
A> если хотите. Ведь и алгоритмические языки програмирования ведут свой
A> род от Планклюаля Тьюринга.
Алгоритмические языки могут вести свой род от модели, но никак не от
аксиоматики (нескольких утверждений про модель).
>> На практике же аксиоматика - инструмент не творения нового, а развития
>> и/или укрепления достигнутого. Понимания, кстати, не требующий, такой
>> вот парадокс...
A> Хочет человек понимать или нет, от аксиоматики не зависит.
Это еще не все. Местами не зависит и может ли он делать утверждения, в
том числе нетривиальные. Насколько может, обычно уже зависит, но все же.
>> Это не с точки зрения когнитивной психологии, а Вам так кажется. Я там
>> недаром обратил внимание на разницу между площадной фигурой и тонкой
>> линией...
A> Вы уже благополучно забыли с чего начался вопрос о палитре.
A> В нотепад++ изменения цвета *непосредственно* отображаются в видимый
A> результат, и не просто в каком-то превью, а именно в том тексте с
A> которым вы сейчас работаете, так же как и размер и начертание шрифта.
А вот что текст в контексте, было не очевидно. И кстати, название
пункта меню при этом - то, что у американцев называется misleading.
Заводит не туда.
A> Вот видите, опять у вас оговорка происходящая именно из вашей практики
A> работы, именно с Эмаксом.
Не только с емаксом. Если нотепад++ сделал один шаг в правильном
направлении - что ж, это хорошо. Может, и в емаксе со временем
сделают... Или даже сделаем, если я начну курить траву и меня по
обкурке пробьет на подкрутку цветов по часу в день...
A> Я это подчеркиваю не ради флейма, а только для того чтобы более
A> наглядна и понятна была мысль, что МЫ все зависим от того инструмента
A> который используем, настолько, что иногда начинаем воспринимать его
A> совершенно локальные достоинства и ограничения, как к
A> общеопределяющие.
Пример неудачен. То есть, свойство такое действительно есть, но в
данном случае роляет не оно.
A> Ну а кликакть все равно удобнее в площадную палитру.
A> Или будете утверждать что набивать название цвета текстом удобнее? :)
Как удобнее - я уже написал. И если делать как удобнее - то начинать
надо с этого, а не с того, чтобы результат отображался в контексте.
"Оптимизировать следует сначала самое узкое место".
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: r...@jabber.ran.pp.ru
Нужны две программы - одна с интерфейсом, а другая чтобы работу делала.
Victor Wagner в <aut24i$gct$1...@wagner.wagner.home>
Aku-Aku
On 24 Лип, 17:38, Artem Chuprina <r...@ran.pp.ru> wrote:
> Aku-Aku -> Wash or make? @ Fri, 18 Jul 2008 10:54:42 -0700 (PDT):
>
Ясный красный, что не существует.
Пока не существует. Нужно создать. И кому как не програмистам этим
заниматся?
> Ой, нет... Отобразить объекты на множества можно, но при этом придется
> выкинуть девять десятых парадигмы. В ООП ключевое понятие - "send
> message", более известное как "call method", аналога которого в теории
> множеств нет. На теорию множеств худо-бедно ложится типизация.
Что ж... раз математики этим еще не занялись, значит задача еще не
стала настолько сложной и критичной.
> Алгоритмические языки могут вести свой род от модели, но никак не от
> аксиоматики (нескольких утверждений про модель).
Что мои слова о алг. языках низкопробные, просто непродуманное
сиюминутное суждение. ("поток сознания" как вы говорите)
Что ваши об аксиоматике.
Аксиоматика -- это аксиоматика -- формально-абстрактная самосвязная
структура.
Скажем тот же принцып виртуально-машинности, какраз проистекает из
понятия аксиоматики.
Спецификация виртуальной машины -- это и есть аксиоматика,
установленная для данного прикладного решения.
> Не только с емаксом. Если нотепад++ сделал один шаг в правильном
> направлении - что ж, это хорошо. Может, и в емаксе со временем
> сделают... Или даже сделаем, если я начну курить траву и меня по
> обкурке пробьет на подкрутку цветов по часу в день...
Artem Chuprina
>> ИИ не существует :-)
A> Ясный красный, что не существует. Пока не существует. Нужно
A> создать. И кому как не програмистам этим заниматся?
Я тут, наконец, сформулировал... ИИ не существует в смысле "ему
невозможно дать определение в привычном понимании этого слова".
Определять его надо в смысле "какие задачи он должен решать?" То, что
решает эти задачи и не является при этом естественным интеллектом, и
называется ИИ.
При этом, конечно, у каждого получится свой критерий, и остается лишь
надеяться на высокую корреляцию. И не забывать сознательно забивать на
пограничные случаи.
>> Ой, нет... Отобразить объекты на множества можно, но при этом придется
>> выкинуть девять десятых парадигмы. В ООП ключевое понятие - "send
>> message", более известное как "call method", аналога которого в теории
>> множеств нет. На теорию множеств худо-бедно ложится типизация.
A> Да, о подобной теории динамически изменяемых множеств я не слышал.
A> Что ж... раз математики этим еще не занялись, значит задача еще не
A> стала настолько сложной и критичной.
Тут более вероятно другое. Математическая логика, начиная с 20-х гг. 20
века и по сей день (в полный рост - по 60-е гг., но и сейчас тоже
ничего) известна как "наука отрицательных результатов". Примерно
наполовину, если не больше, эти отрицательные результаты сводятся к
"задача неразрешима" или "задача практически неразрешима"
(т.е. "сложность разрешения превосходит осмысленные величины").
Формализация и изучение почти чего угодно (единственное, кажется,
исключение - положительный фрагмент логики первого порядка, лежащий в
основе Пролога, но он выразительно очень слаб) приводит к такому
результату. Я думаю, что полная формализация ОО будет иметь те же
проблемы.
>> Алгоритмические языки могут вести свой род от модели, но никак не от
>> аксиоматики (нескольких утверждений про модель).
A> Не, так рассуждать толку мало.
A> Что мои слова о алг. языках низкопробные, просто непродуманное
A> сиюминутное суждение. ("поток сознания" как вы говорите)
A> Что ваши об аксиоматике.
A> Аксиоматика -- это аксиоматика -- формально-абстрактная самосвязная
A> структура.
A> Скажем тот же принцып виртуально-машинности, какраз проистекает из
A> понятия аксиоматики.
A> Спецификация виртуальной машины -- это и есть аксиоматика,
A> установленная для данного прикладного решения.
Давайте все же постараемся употреблять слова в принятом значении. Ну
хорошо, слово "модель" в этом контексте правильно понятно только тому,
кто этим занимался. Но слово "аксиоматика" все же значит нечто
совершенно иное. То, что Вы называете аксиоматикой, у тех, кто с
аксиоматиками работает, может называться моделью, грамматикой, в
отдельных случаях набором правил - но не аксиоматикой.
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: r...@jabber.ran.pp.ru
... и углупился в свои мысли
Кнышев
Aku-Aku
> невозможно дать определение в привычном понимании этого слова".
> Определять его надо в смысле "какие задачи он должен решать?" То, что
> решает эти задачи и не является при этом естественным интеллектом, и
> называется ИИ.
То что написано, вполне соответствует тесту Тьюринга. И лаконичнее, и
понятнее.
> результату. Я думаю, что полная формализация ОО будет иметь те же
> проблемы.
> Давайте все же постараемся употреблять слова в принятом значении. Ну
> хорошо, слово "модель" в этом контексте правильно понятно только тому,
> кто этим занимался. Но слово "аксиоматика" все же значит нечто
> совершенно иное. То, что Вы называете аксиоматикой, у тех, кто с
> аксиоматиками работает, может называться моделью, грамматикой, в
> отдельных случаях набором правил - но не аксиоматикой.
новое.
Я отдаю себе отчет, что несколько вольно используя термины я могу
сказать что-то некорректное.
Но я все же предпочитаю попробовать, и посмотреть к каким новым
смысловым асоциациям может привести такое использование.
Например аналогия между математическим понятием системы аксиом
(аксиоматики) и виртуальной машиной какжется мне интересной.
Artem Chuprina
>> Я тут, наконец, сформулировал... ИИ не существует в смысле "ему
>> невозможно дать определение в привычном понимании этого слова".
>> Определять его надо в смысле "какие задачи он должен решать?" То,
>> что решает эти задачи и не является при этом естественным
>> интеллектом, и называется ИИ.
A> Классики в этом отношении лучше. То что написано, вполне
A> соответствует тесту Тьюринга. И лаконичнее, и понятнее.
Вот боюсь, что нет. Потому что программа, способная пройти тест
Тьюринга, может оказаться неспособной решать собственно нужные задачи.
>> результату. Я думаю, что полная формализация ОО будет иметь те же
>> проблемы.
A> Такая формализация уже не будет ОО. Это будет что-то другое.
Это будет формализация ОО, разумеется. Чтобы разработать мат. аппарат,
нужна формальная модель.
>> Давайте все же постараемся употреблять слова в принятом значении. Ну
>> хорошо, слово "модель" в этом контексте правильно понятно только тому,
>> кто этим занимался. Но слово "аксиоматика" все же значит нечто
>> совершенно иное. То, что Вы называете аксиоматикой, у тех, кто с
>> аксиоматиками работает, может называться моделью, грамматикой, в
>> отдельных случаях набором правил - но не аксиоматикой.
A> Кгм... используя по-старому, старые термины, можно ли сказать
A> что-то новое.
Можно. Старость термина не означает, что про обозначаемую им сущность
всем все известно...
A> Я отдаю себе отчет, что несколько вольно используя термины я могу
A> сказать что-то некорректное. Но я все же предпочитаю попробовать, и
A> посмотреть к каким новым смысловым асоциациям может привести такое
A> использование. Например аналогия между математическим понятием
A> системы аксиом (аксиоматики) и виртуальной машиной какжется мне
A> интересной.
А можно раскрыть эту аналогию более подробно? Так, чтобы если где-то
какие-то термины употреблены некорректно, соседними высказываниями
корректировалось их понимание? А то может, она и интересна, только я
аналогии не вижу, и, следовательно, не могу воспользоваться своим опытом
в работе с аксиоматиками применительно к виртуальным машинам. Ну,
исключая стандартное "докажем, что это эквивалентно этому, исходя из
небольшого количества определений и свойств".
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: r...@jabber.ran.pp.ru
Intel - тоже Сильмарилл. Только сделанный не так...
Aku-Aku
> Тьюринга, может оказаться неспособной решать собственно нужные задачи.
А в реализации там подходят те же оговорки что и у вас.
Я просто хотел показать, что то что вы попытались сказать своими
словами, уже давно сформулированно.
> A> Кгм... используя по-старому, старые термины, можно ли сказать
> A> что-то новое.
>
> Можно. Старость термина не означает, что про обозначаемую им сущность
> всем все известно...
Что-то в нашем разговоре присутствует очень мало сути.
Все идет о всяких околичностях.
Оно конечно тоже неплохо, в результате дает лучше понимать друг друга,
но все же...
> А можно раскрыть эту аналогию более подробно? Так, чтобы если где-то
> какие-то термины употреблены некорректно, соседними высказываниями
> корректировалось их понимание? А то может, она и интересна, только я
> аналогии не вижу, и, следовательно, не могу воспользоваться своим опытом
> в работе с аксиоматиками применительно к виртуальным машинам. Ну,
> исключая стандартное "докажем, что это эквивалентно этому, исходя из
> небольшого количества определений и свойств".
они накладываются,
если вести речь о виртуальных машинах.
Или например неполнота... тоже интересно.
Ведь и в реальной виртуальной машине возникают такие задачи, которые
невозможно решить в рамках самой машины.
> Intel - тоже Сильмарилл. Только сделанный не так...