март 2000
From: Martin Hargreaves
Возвращаясь к обсуждению R, вот как, по-моему, все это должно сложиться:
Программирование - это деятельность
картостроителей, не так много людей (по
сравнению со всем обществом) им занимаются,
и картостроение делает программирование
забавным и,
в некоторых случаях, возможным. Эта истина
не зависит от операционной системы.
Интерфейс командной строки Unix (CLI):
хотя его трудно преобразовать в "пакеты знаний" и
документировать процедурно, становится
экспоненциально более мощным и простым в
использовании по мере совершенствования
карты системы. Не "интуитивен", пока у
вас нет карты системы. Предоставляет много
способов автоматизировать повторяющиеся
задачи. Не использует метафору из "реального
мира" - предполагается, что вы понимаете
систему.
Графические интерфейсы пользователя (GUI - windows, windows-подобные
интерфейсы Unix, Macs):
Более простая среда (меньшее пространство
состояний), действия легко документируются
и легко преобразуются в пакеты знаний. Система
не становится мощнее по мере
создания вашей карты системы. Система
использует привычные многим пользователям
метафоры.
Графический интерфейс пользователя удобен
для тех, кто просто работает с каким-то приложением и не хочет/не нуждается/не
способен создавать карту системы. Это
справедливо для большинства пользователей,
"паковщиков" или "картостроителей",
у которых отсутствует интерес к
компьютерам.
Командная строка unix в значительной степени
является расширением пользовательской
карты системы. Если у вас есть большая и
детальная карта системы, то командная
строка предоставляет вам доступ к любой
функции, которую вы поняли. Если ваша карта
маленькая, или у вас подавлена способность
создавать/модифицировать свою карту, то
командная строка загадочна, и ее нелегко изучить
накапливая пакеты знаний. Очевидно,
командная строка не для всех.
Если вы привыкли к системе, где лишь ваше
понимание накладывает ограничения на то,
что вы можете делать, то переход к системе,
которая принуждает к выполнению простых
легко понимаемых вещей, наверняка
разочарует.
Обратное тоже верно, большинству людей
операционная система не интересна и они не
хотят ее понимать. Что вполне справедливо.
Хотя любознательным картостроителям это
интересно, поэтому рост Linux может служить
индикатором роста иммунитета/свободы от M0 в
обществе.
Я здесь вообще не говорю о программистах,
разработчиках операционных систем,
создателях интерфейсов пользователя и т.п.
в связи с M0. Только о продуктах.
Будет ли это примером мышления
Призрачного НЕ:
Нет разницы между пользователем Unix и
сисадмином Unix. Быть сисадмином Unix трудно,
поэтому быть пользователем Unix трудно. Быть
пользователемWindows легко, но быть
пользователем Unix трудно, поэтому Windows проще
в использовании, чем Unix.
Отрицание отрицания: Но если я использую Linux,
то я должен быть сисадмином, поэтому верно,
что быть пользователем - значит быть
сисадмином.
Или это:
Пользователи должны уметь выполнять мощные
сложные вещи и менять что угодно. Windows (графические
интерфейсы пользователя - GUIs) не дают им
такой возможности, поэтому они изначально
уступают (inherently
inferior) интерфейсу командной строки Unix (CLI).
Отрицание отрицания: Они могут и не хотеть
настраивать стек IP, загружать
альтернативные планировщики (schedulers) и т.п.
сейчас, но по мере изучения наверняка
захотят, а им не дают такой возможности.
Поэтому GUI плохие.
Я не уверен, что очень хорошо выразил второй
случай, но оба построения показывают, что
суть теряется, и говорящий не может ни
понять, что суть потеряна, ни понять другую
точку зрения. Этот недостаток
взаимопонимания приводит к "религиозным
войнам" (advocacy newsgroups).
From: Bill Kress
На самом деле очень правильно. Ты прав, что
[где-то] в обсуждении я поставил знак
равенства между пользователем Linux и
сисадмином, поскольку если я решил ее
использовать, то мне требуется выполнять
обе эти работы, и это действительно
единственная точка зрения, из которой я
исходил.
Хотя ты упустил еще одну очевидную инверсию:
если я не хочу научиться системному
администрированию Unix и поблизости нет
сисадмина, то я не смогу запустить Linux.
Проблема в том, что она мне действительно
нравится. Она быстрая, отзывчивая, и раз уж
она заработала, то с ней можно замечательно
поиграть! Мне просто противно проводить
часы над простыми вещами.
From: Martin Hargreaves
Bill Kress wrote:
Хотя ты упустил еще одну очевидную
инверсию: если я не хочу научиться
системному администрированию Unix и
поблизости нет сисадмина, то я не смогу
запустить Linux.
Да. Пока разработчики Linux не смогут создать
интерфейс, который скроет все эти [грязные
кишки | гордость] операционной системы, но
по-прежнему позволит ей функционировать -
это будет оставаться правдой. В некоторых
будущих итерациях Linux это могут исправить,
но я не стал бы предсказывать - когда, или на
что это будет похоже.
Проблема в том, что она мне действительно
нравится. Она быстрая, отзывчивая, и раз уж
она заработала, то с ней можно замечательно
поиграть! Мне просто противно проводить
часы над простыми вещами.
А поддержка? Существуют компании, которые заполняют эту нишу, просто позвони им, когда тебя заклинит...
From: James Vandenberg
Martin Hargreaves wrote:
[Крутые вещи о CLI GUI и M0]
Отрицание отрицания: Но если я использую Linux, то я должен быть сисадмином, поэтому верно, что быть пользователем - значит быть сисадмином.
Пользователь Windows == Сисадмин Windows
следовательно
Пользователь Unix == Сисадмин Unix (2)
Легкость(Сисадмин Unix) =
Высокая // = HIGH
следовательно
Легкость(Пользователь Unix) = Высокая // (из 2)
Linux == Unix
следовательно
Легкость(Пользователь Linux) = Высокая // (из 2)
Переупрощение в начале вывода (2) вывернуло
все наизнанку. Это и может оказаться точкой GN
(местом приложения Призрачного НЕ).
Пользователи должны уметь выполнять
мощные сложные вещи и менять что угодно. Windows
(графические интерфейсы пользователя - GUIs)
не дают им такой возможности, поэтому они
изначально уступают ( inherently
inferior) интерфейсу командной строки Unix (CLI).
Пользователи должны уметь достигать любого
возможного состояния.
Unix это позволяет
Windows не позволяет
Unix > Windows
Windows.ВозможныеСостояния == Пользователи.ТребуемыеСостояния
сейчас
следовательно
Windows.ВозможныеСостояния < Пользователи.ТребуемыеСостояния
вскоре
Нужна ли настройка стека IP, чтобы сделать
мои шрифты наклонными (for italicising my fonts)?
предположение:
Ограничение пространства состояний -
изначально плохо (inherintly bad).
Я не уверен, что очень хорошо выразил
второй случай, но оба построения показывают,
что суть теряется, и говорящий не может ни
понять, что суть потеряна, ни понять другую
точку зрения. Этот недостаток
взаимопонимания приводит к "религиозным
войнам" ( advocacy newsgroups).
Если у говорящего нет обратной связи, то он не может увидеть пробелы в своем понимании ситуации. "Группы новостей защиты [чего-то там]" неумолимо деградируют в фестивали чокнутых (wank-fests) со стрельбой во все стороны. Сообщения пишутся по шаблону: "Мне тут пришлось использовать компьютер с Windows бяка бяка, поэтому я установил Linux ура ура". Затем ты наблюдаешь, как прогрессирует самоудовлетворение (когда они делают то же, что и в фильмах "дети до 16 не", но соло).
From: Zach Gold
На самом деле спор здесь ведется вокруг
того, что впервые ввела Apple как принципы
интерфейса пользователя, и чему
противопоставляется то, что делала Unix лет
за 10 до того. Apple использовала парадигмы
реального мира, чтобы сделать операционную
систему доступной без опыта. Структура Unix
совершенно абстрактная и может достигать
невероятных уровней полезности, когда
интегрирована в чью-то карту.
Но кто сказал, что нам не нужно то и другое? Я
не думаю, что должным образом реализованный
GUI в стиле Apple - это паковка. Это просто
использование парадигм, которые общество
уже поместило в карты паковщиков. Хотя
лучше создать новую, вы не можете
предполагать, что паковщики ее воспримут.
То, что пытаются сделать OSX и
linux - интегрировать то и другое [GUI и CLI].
Другая проблема состоит в том, что, возможно,
используемая в Unix парадигма устаревает. Мне
всегда казалось, что языки можно разделить
на две категории, ориентированные на
эффективность исполнения (performance-oriented), типа C, и
ориентированные на простоту (ease-oriented) типа
чистого OOP. Я думаю, что Reciprocality больше ориентирована на простоту.
Суть ориентированных на простоту языков в
парадигмах, которыми легко манипулировать
в уме, не смотря на то, что их, как может
оказаться, трудно реализовать
высокоэффективно на уровне компилятора (Эту проблему могут решить
"компиляторы
на лету" (runtime
compilers)). Как мы
знаем, язык оказывает сильное влияние на
дизайн операционной системы. Unix всегда
поддерживал плоскую, обычно не-ОО,
структуру.
Задумайтесь над этим секунду. Я знаю, что я
могу описать синтакс моего совершенного
языка, но сейчас его не реализуешь
эффективно. Можно избавиться от
прототипов и типов переменных, реализовать
автоматический сбор мусора, простой
объектный механизм - подобно пакетам Perl
плюс виртуальные объекты, полностью
параметрическое программирование - а не
слабая поддержка шаблонов (templates) в C++, и
способность описывать и манипулировать
целыми объектными структурами.
From: Chistopher Marshall
Zach Gold wrote:
Другая проблема состоит в том, что, возможно, используемая в Unix парадигма устаревает. Мне всегда казалось, что языки можно разделить на две категории, ориентированные на эффективность исполнения (performance-oriented), типа C, и ориентированные на простоту ( ease-oriented) типа чистого OOP. Я думаю, что reciprocality больше ориентирована на простоту. Суть ориентированных на простоту языков в парадигмах, которыми легко манипулировать в уме, не смотря на то, что их, как может оказаться, трудно реализовать высокоэффективно на уровне компилятора (Эту проблему могут решить "компиляторы на лету" (runtime compilers)). Как мы знаем, язык оказывает сильное влияние на дизайн операционной системы. Unix всегда поддерживал плоскую, обычно не-ОО, структуру.
Ну, я думаю, что сказать, что
используемая в Unix парадигма устаревает -
это все равно, что сказать, что устаревает
алгебраическая нотация. Я не думаю, что "старение"
в этом смысле - плохо. В любой парадигме,
которая имеет возможность "стареть" в
такой быстро развивающейся индустрии,
как компьютерная, прежде всего должно
содержаться нечто невероятно правильное.
Я думаю, что одно из различий между
прямолинейным (straight) C-подобным
программированием и высокоуровневым OO
программированием (о котором ты, похоже,
говоришь) подобно тому, что можно
обнаружить в языке S, ОО языке очень
высокого уровня; там больше нет возможности
найти корреляцию, даже в принципе, между
написанным кодом и шагами, которые
выполняет машина для исполнения этого кода.
Я думаю, что Cи - бесспорно лучший язык,
назначение которого - позволить написать
код умеренно высокого уровня и тем не менее
полностью понять, как машина будет
исполнять этот код. По моему мнению, C++ -
неудачная попытка увязать противоречивые
цели, что в результате дает не просто язык
без философии, но язык с анти-философией.
Я не думаю, что писать
ядро на ОО языке очень высокого уровня - это
хорошая идея, не
важно насколько эффективен компилятор,
поскольку задача ядра - быть максимально
быстрым И гибким, насколько это
возможно, и программисту нужно понимать,
как компьютер исполняет код, чтобы иметь
хоть какой-то шанс этого добиться.
Место ОО языков очень высокого уровня - в
приложениях, и Unix поддерживает эти языки,
как и любая другая операционная система, и
гораздо лучше, чем некоторые.
Задумайтесь над этим секунду. Я знаю, что я
могу описать синтакс моего совершенного
языка, но сейчас его не реализуешь
эффективно. Можно избавиться от
прототипов и типов переменных, реализовать
автоматический сбор мусора, простой
объектный механизм - подобно пакетам perl
плюс виртуальные объекты, полностью
параметрическое программирование - а не
слабая поддержка шаблонов (templates) в C++, и
способность описывать и манипулировать
целыми объектными структурами.
Возникает вопрос. Совершенный язык для
чего? Для написания приложений, щекочущих
воображение? Или для написания драйвера
устройства или ядра?
Я не думаю, что можно получить язык,
совершенный во всех областях.
From: Bill Kress
Chistopher Marshall wrote:
Я не думаю, что можно получить язык, совершенный во всех областях.
Я не согласен. По мере того, как
компиляторы становятся более
интеллектуальными, нет причины, по которой Cи
даст лучший исполнимый код, чем Ada -- на самом
деле, при использовании языков очень
высокого уровня доступно гораздо больше
информации для интеллектуального
оптимизирующего компилятора. Если
вычистить из кода неиспользуемые элементы
языка и фрагменты, к которым никогда не
обращаются, то VB, ADA или Java выдадут не больше
нескольких сотен байт для программы типа "Hello, world".
Сейчас, если превыше всего поставить
способность любого из этих языков работать
с операционной системой, то не окажется
ничего, что можно сделать только с помощью Cи
или ассемблера.
Cи, как оказывается, прекрасно работает с
сегодняшними операционными системами,
написанными на Cи. Если завтрашние
операционные системы будут написаны на Java,
то Java будет прекрасно с ними работать.
From: Zach Gold
Chistopher Marshall wrote:
Я не думаю, что можно получить язык, совершенный во всех областях.
С точки зрения Perl, проблема с Cи в том, что он
принуждает кодировать определенным
образом. Ответ состоит в том, что Cи - лучший
язык для проектирования ОС, и для других
задач стоит использовать другие языки.
Другие языки просто заставляют кодировать
другими методами. Программирование должно
взять урок у естественных языков. В их
случае не язык влияет на мышление, влияет
культура. Все языки совместно используют
некую центральную нить, и этот
теоретический язык - язык на котором думают
кодировщики. Что если бы мы
действительно создали такой язык, и для
различных задач было бы возможным
использовать различные его подмножества.
И да, я думаю, что по мере совершенствоания
компиляторов станет вполне приемлемым и
логичным написать ядро на языке типа Ada или
Java. Теперь, вероятно, мы могли бы завязать
дискуссию о Призрачном НЕ в современных
компиляторах.
From: Alan Carter
Zach Gold wrote:
Но кто сказал, что нам не нужно то и
другое? Я не думаю, что должным образом
реализованный GUI в стиле Apple - это паковка.
Это просто использование парадигм, которые
общество уже поместило в карты паковщиков.
Хотя лучше создать новую, вы не можете
предполагать, что паковщики ее воспримут.
То, что пытаются сделать OSX и
linux - интегрировать то и другое [GUI и CLI].
Это очень хорошая мысль. В конце концов, в Linux
есть xfm(1). Я действительно утверждаю, что
продукты Microsoft спроектированы в рамках, и
кажутся естественными для людей в
состоянии, сознания M0, в то время как UNIX -
это великолепный способ избавить от НЕ
большие куски вашего ума.
Со стороны Microsoft мы получаем исключающее
противопоставление: GUI против UNIX. Это ложное
противопоставление. В UNIX у нас есть командная
строка и графический интерфейс
пользователя, и вопрос заключается в том,
насколько качественным продуктом является
графический интерфейс пользователя от Microsoft.
Я утверждаю, что GUI в
Mac гораздо лучше!
Другая проблема состоит в том, что,
возможно, используемая в Unix парадигма
устаревает. Мне всегда казалось, что языки
можно разделить на две категории,
ориентированные на выполнение (performance-oriented),
типа Cи, и ориентированные на простоту (ease-oriented)
типа чистого OOP. Я думаю, что
reciprocality больше ориентирована на простоту.
Суть ориентированных на простоту языков в
парадигмах, которыми легко манипулировать
в уме, не смотря на то, что их, как может
оказаться, трудно реализовать
высокоэффективно на уровне компилятора (Компиляторы
на лету (runtime
compilers) могут эту проблему решить). Как мы
знаем, язык оказывает сильное влияние на
дизайн операционной системы. Unix всегда
поддерживал плоскую, обычно не-ОО,
структуру.
Если вы когда-нибудь программировали в среде ParcWorks SmallTalk, то видели замечательный пример того, о чем здесь говорит Zach.
From: Zach Gold
Alan Carter wrote:
Это очень хорошая мысль. В конце концов, в Linux есть xfm(1). Я действительно утверждаю, что продукты Microsoft спроектированы в рамках, и кажутся естественными для людей в состоянии, сознания M0, в то времяя как UNIX - это великолепный способ избавить от НЕ большие участки вашего ума.
Я соглашусь, что unix полезна для ума. Пару дней назад я прислушался к чьему-то совету (Alan?) и написал программу hello world в vi и затем откомпилировал ее из командной строки. Я должен сказать, что на меня произвело впечатление, насколько просто оказалось создать эту программу, кроме того это оказалось гораздо быстрее, чем с помощью Borland C++ Builder (мой первый компилятор). Но нужно признать, что единственная причина, почему я это сделал за разумное время - до этого я также использовал DJGPP под windows. Хотя использование VIM и g++ быстрее. Тем не менее, на меня произвела сильное впечатление простота интерфейса командной строки, когда я немного в ней разобрался. У меня есть желание продолжить изучение :)
Другое примечание - я думаю, что частично привлекательность графического интерфейса пользователя кратко можно выразить как ИГРУШКИ!ПРИМОЧКИ!НАВОРОТЫ!КРУТО! :)
Со стороны Microsoft мы получаем исключающее противопоставление: GUI против UNIX. Это ложное протипоставление. В UNIX у нас есть командная строка и графический интерфейс пользователя, и вопрос заключается в том, насколько качественным продуктом является графический интерфейс пользователя от Microsoft. Я утверждаю, что GUI в Mac гораздо лучше!
В Microsoft угробили парадигму и, хуже того,
они к тому же заразили
Apple. Парадигма замечательно работала, когда
не так много людей владели "компьютерной
грамотностью", но теперь они впали в
создание парадигм внутри парадигм.
Подумайте над парадигмой "окна картинки"
("picture window") от Microsoft, которую они
позаимствовали из браузеров. Есть надежда,
что в aqua вернутся к прежним яблочным
ценностям (the old apple inginuity). Интересно,
возможно ли это одновременно с появлением
разноцветных коробок ["ягодная" серия
iMac - С.К.]. Более того, почти все
попытки в unix, которые я видел, еще больше
исказили эту идею. Некоторым
картостроителям может оказаться трудно
увидеть выгоду от "заразных идей" (memes -
мемов) паковщиков. Подумайте о R6 как проекте
интерфейса пользователя.
Если вы когда-нибудь программировали в
среде ParcWorks SmallTalk, то видели замечательный
пример того, о чем здесь говорит Zach.
Я знаю, что ты имеешь в виду. Приложения типа Morphic в Squeak - ближе всего к истинно ОО абстрактному интерфейсу пользователя.
From: Chistopher Marshall
Bill Kress wrote:
Я не согласен. По мере того, как компиляторы становятся более интеллектуальными, нет причины, по которой Cи даст лучший исполнимый код, чем Ada
Языки Java и Ada (в противоположность их
библиотекам) не выше уровнем, чем Cи, если
посмотреть с той точки зрения, которой я
придерживаюсь.
И в Ada, и в Cи, существует гораздо более
сильная связь между тем, что означают
строки кода, и тем, как компьютер/компилятор
собирается их исполнить, чем в таком гораздо
более высокоуровневом языке как S, в
котором вовсе ничего нельзя сказать
уверенно о том, как код отображается на
действия компьютера, и потребуется в 100 раз
более высокая производительность для
повышения элегантности и выразительности,
что замечательно иногда, но не всегда.
Cи, как оказывается, прекрасно работает с
сегодняшними операционными системами,
написанными на Cи. Если завтрашние
операционные системы будут написаны на Java,
то Java будет прекрасно с ними работать.
Есть большая разница между оптимизацией
программы "hello world" и кода модулей ядра,
которые обеспечивают управление памятью (memory mapping
scheme), например.
Ты сказал так, будто "интеллектуальный"
компилятор может принимать решения,
оптимизирующие алгоритмы высокого уровня.
Если бы он это делал, программирование не
было бы такой сложной работой, а он ведь
этого не
делает.
Поймите меня правильно, я большой любитель Java
и S. Фактически большую часть своей работы я
делаю на Java. И изучение Python - следующая
задача в моем списке связанных с Linux
приключений. Но Java и т.п. даже не близко не
подходят к требованиям написания ядра или
драйвера устройства.
Я не думаю, что для их ниш есть равный Cи язык,
или равная
Unix операционная система. Они прибили к
стене свои проблемные области гораздо
крепче, чем Java или Ada прибили свои
проблемные области.
From: Alan Carter
Chistopher Marshall wrote:
Ты сказал так, будто "интеллектуальный" компилятор может принимать решения, оптимизирующие алгоритмы высокого уровня. Если бы он это делал, программирование не было бы такой сложной работой, а он ведь этого не делает.
Это глубокий момент, который в нашем
обществе понимается неправильно, и это один
из путей, каким M0 создает общество, не
способное к программотехнике.
Я только что написал критичный к
быстродействию кусок кода, что потребовало
нескольких вечеров чтения Кнута до того,
как я попытался увидеть лучший способ
достичь своей цели. Я писал весь этот код
зная, что gcc -O3 ведет себя разумно (intelligently),
если я везде использую индексирование
массивов вместо указателей, и поэтому писал
так, чтобы сохранить четкость своего
алгоритма. Но нет такого способа, чтобы
простое скармливание программы моему другу
дало бы мне увеличение быстродействия в 600
раз, которое получается после некоторого
размышления. Причина в том, что имея дело с
индексированными массивами, компилятор
знает, что он делает со всеми регистрами,
поэтому знает, какие операции выполняются с
их использованием, и может оптимизировать.
Но он не знает предназначения (intentionality) моего
алгоритма в целом. У него нет идей, какими
будут данные на входе, или как исходя из них
программный конечный автомат будет
проходить по своему пространству состояний.
Сложность сложна. Разнообразие
разнообразно. Намерение != Действие. Let X = X.
Ом.
From: Bill Kress
Chistopher Marshall wrote:
Есть большая разница между оптимизацией
программы "hello world" и кода модулей ядра,
которые обеспечивают управление памятью ( memory mapping
scheme), например.
Ты сказал так, будто "интеллектуальный"
компилятор может принимать решения,
оптимизирующие алгоритмы высокого уровня.
Если бы он это делал, программирование не
было бы такой сложной работой, а он ведь не
делает.
Вовсе нет -- я исходил из противоположного. Ты можешь реализовать алгоритм на любом языке, и пусть компилятор выдает один и тот же код. У языка Cи нет преимущества. Не существует, - хорошо, существует мало причин - по которым Java не может компилировать в ассемблер, и если вы уже так делали, то нет причины, по которой такое ассемблирование не может быть идентично ассемблированию из Си с идентичным кодом.
На деле способность Java оптимизировать
программу на уровне p-кода во время
компиляции на лету теоретически может
сделать ее быстрее программы на Си.
Представим вызов простой функции
операционной системы в очень компактном
цикле. Компилятор понимает, что вы хотите, и
вставляет (inline) код из библиотеки ОС в ваш
цикл во время динамической компиляции.
Я не думаю, что для их ниш есть равный Cи
язык, или равная
Unix операционная система. Они прибили к
стене свои проблемные области гораздо
крепче, чем java или ada прибили свои
проблемные области.
У Cи есть в точности одно огромное преимущество -- и он великолепно для этого приспособлен. Cи - это наилучший из возможных язык для портирования Unix и самого себя на новое "железо". Именно для этого его создавали, и именно это он делает. Он хорош для написания драйверов Unix и т.п., поскольку Unix была написана на Cи. Если бы Unix была написана на APL -- Я Сомневаюсь, что это физически возможно, но если бы это получилось, то я бы предположил, что APL стал бы совершенным языком для ее (ОС) расширения.
From: granitor
Bill Kress wrote:
Вовсе нет -- я исходил из противоположного.
Ты можешь реализовать алгоритм на любом
языке, и пусть компилятор выдает один и тот
же код. У языка Cи нет преимущества. Не
существует - хорошо, существует мало причин,
по которым Java не может компилировать в
ассемблер, и если вы уже так делали, то нет
причины, по которой такое ассемблирование
не может быть идентично ассемблированию с
Си с идентичным кодом.
Разовьем эту идею дальше, ты мог бы
написать только алгоритм и позволить
компилятору сгенерировать код на любом
языке, которые есть в системе.
Кодирование чего-либо нетривиального
включает информацию, сопоставимую по
объему с небольшой (а то и не совсем
небольшой) энциклопедии, что
само по себе может быть забавным, но может и не
показаться забавным тому, кто скорее
фокусируется на "что?", а не "как?".
Исторически, существовал ряд причин, почему
это было невозможно, затем непрактично,
затем нежизнеспособно из коммерческих
соображений... теперь, возможно, это просто
слишком неопределенная и трудная цель.
Однако, было бы здорово открыть (или создать)
метапрограммирование как полный диапазон
взаимодействия (точно также, как
программирование может быть хобби,
коммерческим, академическим и т.д.), и
сэкономить время на начальном этапе
изучения языка.
From: Alan Carter
Bill Kress wrote:
Вовсе нет -- я исходил из противоположного. Ты можешь реализовать алгоритм на любом языке, и пусть компилятор выдает один и тот же код. У языка Cи нет преимущества. Не существует - хорошо, существует мало причин, по которым Java не может компилировать в ассемблер, и если вы уже так делали, то нет причины, по которой такое ассемблирование не может быть идентично ассемблированию из Си с идентичным кодом.
Существуют языки, в которых скрытое
управление памятью (memory management) - важная
черта, которая делает их удобными для
некоторых видов работы. В других языках
политика управления памятью не заложена.
Поэтому программист может спроектировать
управление памятью как интегральный аспект
своего алгоритма, что может дать разницу
между решением O(N^2) и решением O(log N). Ах, да - я
как раз написал одно такое в прошлые
выходные!
Идея, что все языки должны генерировать
один и тот же код показывает неправильное
понимание природы создания ПО, которое
возвращает нас назад через информатику (computer
science), теорию вычислимости (computability theory) и
комбинаторику (combinatorics) в точку, где может
быть достигнуто соглашение и/или
разрешение спора. Если компилятор сможет
получить знание о намерении программиста
из действий в программе, а затем определить
оптимальный алгоритм для выполнения этого
намерения, то это будет крупное достижение
в математике, поскольку походя решит
проблему останова (Halting Problem).
Нет никакого конечного множества известных
устоявшихся алгоритмов, которое задает
программист, а компилятор потом выбирает.
Этот способ просто не работает. Вера, что он
работает (что, как я утверждаю, - заблуждение M0),
происходит из веры, что программирование -
это нетворческая черная работа по
сравнению с постоянно извергаемой
маркетоидной чушью.
Эй - интересно, есть ли какая-то сила в идее,
что общество M0 основано на вере, что
проблемы останова не существует? Что все
задачи можно решить детерминистски за
неполиномиальное время? Я думаю, что это -
истина общества M0. Интересно, как можно
использовать тот факт, что они в этом
ошибаются?
На деле способность Java оптимизировать
программу на уровне p-кода во время
компиляции на лету теоретически может
сделать ее быстрее программы на Си.
Представим вызов простой подпрограммки
операционной системы в очень компактном
цикле. Компилятор понимает, что вы хотите, и
вставляет (inline) код из библиотеки ОС в ваш
цикл во время динамической компиляции.
Вы когда-нибудь набирали:
$ man gcc
и смотрели, что делает опция -O3? Как вообще
компилятор может сделать работу лучшую, чем
заурядная сортировка, без каких-либо
ограничений? Какие свойства компилятора на
лету (runtime compiler) могли бы это сделать? Да
никакие, насколько я понимаю.
У
Cи есть в точности одно огромное
преимущество -- и он великолепно для этого
приспособлен. Cи - это наилучший из
возможных язык для портирования Unix и самого
себя на новое "железо". Именно для
этого его создавали, и именно это он делает.
Он хорош для написания драйверов Unix и т.п.,
поскольку Unix была написана на Cи. Если бы Unix
была написана на APL -- Я Сомневаюсь, что это
физически возможно, но если бы это
получилось, то я бы предположил, что APL стал
бы совершенным языком для ее (ОС) расширения.
На самом деле к этому можно лобавить еще
кое-что. Cи и UNIX эволюционировали вместе, в
выдающихся мозгах ken и dmr [Кернигана и Ричи]. Сейчас можно
заявлять, что выживание языка Си - это
просто сговор с UNIX, но как
UNIX умудряется в рамках своей модели
непрерывно в течение 30 лет справляться с
экспоненциальным технологическим ростом?
Потому что лежащая в основе системы UNIX
модель реально ухватывает суть фон-неймановской
архитектуры в потрясающе необходимой и
достаточной манере. Cи делает то же для
процессора. Никакой другой язык не обладает
такой широкой областью применимости, как Си.
Я сомневаюсь, что Страуструп (Stroustrup) сделал
явно законным Duff's Device в
C++, говоря о нем в серой книге, из порочных
соображений [о конструкции Тома Даффа можно
почитать в Jargon File - С.К.].
Никого не вынуждают уважать кругозор,
поскольку делать по-другому - допускать
уверенность в своем следующем шаге или
признаться, сколько они потратили времени
на то, чтобы его тошнило. Уважение, которое к
нему испытывают очень многие люди, знающие
о многих архитектурах и подходах, -
следствие пути, который он так очень
правильно выбрал много лет назад.
Аналогично, люди, которые не знают, о чем
они говорят, шумят о том, какой Билл Гейтс (Bill Gates)
неописуемо выдающийся гений, производящий
системы невообразимой сложности. Люди,
которые действительно знают, о чем они
говорят, считают Дейва Катлера (Dave Cutler)
серьезным способным проектировщиком ОС,
который в NT реализовал систему большой мощи
и разумной простоты. Это путь M0 маркетоидов.
Шум об изъянах, как будто они величайшие
достижения на все времена, и никогда
никакого упоминания о реальных вещах.
Поскольку они выявляют чушь.
Внимательное изучение Cи и UNIX действительно
может научить очень и очень многому о том,
как думать о компьютерах. Здесь больше
жизни, чем культурного релятивистского
месива.
From: Alan Carter
granitor wrote:
Исторически, существовал ряд причин, почему это было невозможно, затем непрактично, затем нежизнеспособно из коммерческих соображений... теперь, возможно, это просто слишком неопределенная и трудная цель. Однако, было бы здорово открыть (или создать) метапрограммирование как полный диапазон взаимодействия (точно также, как программирование может быть хобби, коммерческим, академическим и т.д.), и сэкономить время на начальном этапе изучения языка.
Что касается последнего, великий Вив
Стеншелл (Viv Stanshall) снял фильм "Sir Henry at
Rawlinson's End". Каждое утро сэр Генри просыпается,
разряжает оба ствола своего дробовика в
потолок и кричит: "Я не знаю, чего я хочу,
но я хочу этого немедля!"
Проблема в том, что если вы знаете, что вы
хотите, компьютер может это вам дать. Очень
скоро это будет истинным не только для
манипуляций с информацией, но и для
материальных вещей. Все, что нужно будет людям
сделать - сказать машинам, что они
хотят. Это означет, что они должны оказаться
способными выразить свои желания. Это
означает, что им понадобятся языки, которые
также богаты, как их воображение о желаниях.
Также это означает, они должны будут
оказаться способными ЯСНО ДУМАТЬ о своих
желаниях, приходя к полному пониманию и
знанию того, о чем они просят.
В наше время существует миф, что "использование компьютеров" заключается в нажимании кнопок. Это не так. Люди, которые ограничили свой менталитет уровнем землеройной машины, не могут конкурировать на рынке труда с кремниевыми чипами. Посмотрите на эти адские центры обработки звонков (call answering centres). Сейчас там "занято" больше людей, чем во всей производящей индустрии Великобритании. Их ответы подготовлены (расписаны). Звонки приходят и уходят на рабочие станции. Сценарии встроены в рабочую станцию, так что "работники" находят их "простыми в использовании" - или которым "нельзя не подчиниться", в зависимости от того, работник вы или босс.
Чем на самом деле являются эти люди - интерфейсом распознавания голоса. Ничем больше. Одна решающая эту задачу технология. Только одна. И их уши станут не нужны, и центр обработки звонков в полном составе поместится в шкафчик. Вероятно, на Дальнем Востоке, и его будет обслуживать Rob.
Нам нужно на это забить. Эра безмозглости ЗАКОНЧИЛАСЬ. Это не вопрос определения простых процедур, чтобы заставить машины выполнять сложные процедуры. Это означает становиться творческими, сознательными и изобретательными (а не просто говорить, что мы такие) и обеспечить себя соответствующими инструментами.
From: David Brown
Alan Carter wrote:
Вы когда-нибудь набирали:
$ man gcc
и смотрели, что делает опция -O3? Как вообще
компилятор может сделать работу лучшую, чем
заурядная сортировка, без каких-либо
ограничений? Какие свойства компилятора на
лету (runtime compiler) могли бы это сделать? Да
никакие, насколько я понимаю.
Как-то я читал документ о проекте "Synthesis" (затасканное
более других название - мне пришлось
работать в компании Synthesis над программой Synthesis,
которая не делала ничего из того, о чем
говорилось в том документе). В этом
конкретном случае Sythesis была
операционной системой, которая
компилировала и перекомпилировала код на
лету.
Преимущество, которое в ней обнаружилось, -
если компилятор может посмотреть на
окружение, в котором исполняется код, то он
может укоротить и полностью устранить
ветви, у которых нет шансов быть
исполненными в этом окружении. Это
гораздо более агрессивный, чем обычный, не-на-лету,
компилятор, поскольку обычный компилятор
ничего не знает о текущем состоянии
окружения. У него были числа, позоляющие
доказать, что в определенных случаях,
скажем при обработке/сборе данных в
реальном времени (она здорово подходила для работы с MIDI),
где цена исполняемого снова и снова
условного перехода высока и выигрыш от
перекомпиляции оказывался выше, чем
затраты на повышение быстродействия. Это очень
похоже на то, что делается в HotSpot JVM, над
которой работает Sun.
Мне бы очень хотелось опять найти тот
документ.
Конечно, по-настоящему агрессивный
компилятор мог бы предвычислять все
возможные пути исполнения и просто
выбирать правильный основываясь на
значениях переменных-ключей, но вспомним о
комбинаторном взрыве -- это были бы
смехотворно огромные потери времени и
памяти.
From: Peter Dettman
Alan Carter wrote:
и смотрели, что делает опция -O3? Как вообще
компилятор может сделать работу лучшую, чем
заурядная сортировка, без каких-либо
ограничений? Какие свойства компилятора на
лету (runtime compiler) могли бы это сделать? Да
никакие, насколько я понимаю.
Я предполагаю, что преимущество, которое
дает компиляция на лету, состоит в том, что
вы отслеживаете, что же программа исполняет
на самом деле, и хотя я не компьютерный гуру,
я могу легко представить, что информация о
том, что в действительности делает
программа, даст возможность оптимизации,
которая невозможна в противном случае.
Естественно, вам приходится сначала
интерпретировать код, или как-то
компилировать, чтобы это вообще заработало,
так что компиляция на лету - это просто
дополнительный уровень.
Еще одна выгода - обычно компилятору нужно
действительно оптимизировать очень малую
часть программы для получения большей доли
возможного улучшения, и он определяет, что
это за часть, сам! Это очень хорошее качество,
особенно для языков типа Java, где важно
исполнение Just-In-Time.
Сколько среди вас программистов на C++,
которые одну часть модулей программы
компилируют с оптимизацией по размеру, а
другую - с оптимизацией по быстродействию?
From: Alan Carter
David Brown wrote:
Преимущество, которое в ней обнаружилось, - если компилятор может посмотреть на окружение, в котором исполняется код, то он может укоротить и полностью устранить ветви, у которых нет шансов быть исполненными в этом окружении. Это гораздо более агрессивный, чем обычный, не-на-лету, компилятор, поскольку обычный компилятор ничего не знает о текущем состоянии окружения. У него были числа, позоляющие доказать, что в определенных случаях, скажем при обработке/сборе данных в реальном времени (она здорово подходила для работы с MIDI), где цена исполняемого снова и снова условного перехода высока и выигрыш от перекомпиляции оказывался выше, чем затраты на повышение быстродействия. Это очень похоже на то, что делается в HotSpot JVM, над которой работает Sun.
Может ли стать подобным примером в
обычном компьютере перехват обращений к select() для
определения, какие дескрипторы файлов
действительно открыты, и удаления всех
FD_ISSET() для неоткрытых дескрипторов? Я могу
себе представить, что в приложениях для
специфических областей подобные вещи могут
оказаться полезными - большие сети MIDI-устройств
могут быть примером. Я вспоминаю, что в
конце 1980-х люди MIDI казались немного
странными. Просто чуть более честолюбивые,
чем это позволяли технологии того времени,
поэтому они начали строить самые
удивительные специализированные штуковины
сами.
Конечно, по-настоящему агрессивный
компилятор мог бы предвычислять все
возможные пути исполнения и просто
выбирать правильный основываясь на
значениях переменных-ключей, но вспомним о
комбинаторном взрыве -- это были бы
смехотворно огромные потери времени и
памяти.
Я думаю, это потребовалось бы в
специфической ситуации с очень высокой
частотой поллинга [циклической проверки
условий - С.К.] или чего-то подобного.
Вероятно, написание программы, которая
просто забивает NOPами условные переходы,
было бы более эффективно. Стали бы
неспециалисты в этой специфической области
получать выгоды от встраивания этого в
компилятор?
Но игра честная - вы меня здесь сцапали! Если
это кто-то сделал, компилятор на лету может
делать вещи, которые обычный компилятор
делать не может!
From: Alan Carter
Peter Dettman wrote:
Сколько среди вас программистов на C++,
которые одну часть модулей программы
компилируют с оптимизацией по размеру, а
другую - с оптимизацией по быстродействию?
Я вообще последнее время редко беспокоюсь о
размере. Я утверждаю, что большинство людей
могли бы запустить целый мир в той
оперативной памяти (RAM), которая требуется
Microsoft
для текстового процессора :-)
Одно исключение - есть ситуации, когда на
машинах с высокой загрузкой переключения
страниц это не очень хорошо. Слишком большая
доля запросов на подкачку страниц может
замедлить отклик. Реально
увеличению быстродействия может помочь объединение
нескольких тесно связанных классов в один
файл, поскольку они окажутся рядом в
объектном коде. Политика "один класс -
один файл" может привести к тому, что
вызовы неудачно проходят через виртуальное
адресное пространство, что приводит к
увеличению числа запросов на подкачку
страниц.
From: granitor
Alan Carter wrote:
Нам нужно на это забить. Эра безмозглости ЗАКОНЧИЛАСЬ.
Я с этим согласен, однако, неэффективная
внимательность (mindfulness) меня тоже очень
расстраивает, подобно попыткам рендеринга 3D
графики на Commodore 64 (не невозможная задача, я
видел расширение BASIC, которое аккуратно
обращалось с полигонами, но, определенно, на
сегодня это не самый легкий способ это
делать).
Это не вопрос определения
простых процедур, чтобы заставить машины
выполнять сложные процедуры. Это означает
становиться творческими, сознательными и
изобретательными (а не просто говорить,
что мы такие) и обеспечить себя
соответствующими инструментами.
На днях я разговаривал со своим другом об
анимации (? anime), и мы говорили, что японцы,
должно быть, подолгу создавали на
компьютерах трехмерные модели, учитывая
такое большое число механических моделей в
анимации... представьте попытку сделать
мультик, подобный "Трансформерам" ("Transformers"),
полностью вручную.
Что касается программирования, возможно,
было бы лучше работать на уровне алгоритма
и иметь нечто для генерации кода, или
наоборот, поскольку временами синтаксис
может затруднить работу над алгоритмом [алгоритм
труднее увидеть]. Мысленно я постоянно
делаю это преобразование, но поскольку это
так детерминированно, я склонен думать "а
не будет ли быстрее, если этим займется
машина"?
Подобно тому, как JBuilder показывает
диалоговые штучки параллельно коду (хотя
мои воспоминаниям JBuilder не совсем веселые...),
и, как я предполагаю, некоторые инструменты C++
делают подобное для построения диалоговых
окон, просмотр или даже редактирование
алгоритмов параллельно с кодом были бы
полезны.
Чтобы избежать привязки к определенному IDE,
я концептуально отделяю процесс от
инструмента, поэтому мы получаем нечто, что
транслирует .c файлы в некий другой формат и
обратно, и отдельный интрумент для
просмотра/редактирования этого нового
формата, но кроме того есть возможность
транслировать из этого формата на C++, или
какой другой язык.
From: Alan Carter
Zach Gold wrote:
Другое примечание - я думаю, что частично
привлекательность графического интерфейса
пользователя кратко можно выразить как
ИГРУШКИ!ПРИМОЧКИ!НАВОРОТЫ!КРУТО!
Да! Именно поэтому у меня в fvwm2 с несколькими
виртуальными столами запущено несколько xterms, xeyes, xosview, xaos, xephem
и прочие штучки! Дело том, что в целом
спор GUI vs. command - фальшивое исключающее
мышление и анти-логичность.
From: granitor
Alan Carter wrote:
Нет никакого конечного множества известных устоявшихся алгоритмов, которое задает программист, а компилятор потом выбирает. Этот способ просто не работает. Вера, что он работает (что, как я утверждаю, - заблуждение M0), происходит из веры, что программирование - это нетворческая черная работа по сравнению с постоянно извергаемой маркетоидной чушью.
Я готов признать свое невежество, однако,
обобщенное программирование, как оно
реализовано в STL на C++, - разве это не
множество алгоритмов, из которых
компилятор генерирует необходимый код для
их реализации?
Не утверждая, что программирование
нетворческое занятие, скорее наоборот, но
это постоянное набирание #include может
несколько утомить, а инструменты,
предназначенные в первую очередь для
генерации кода, могли бы сделать чуть
больше работы. Могли бы, поскольку я
предполагаю, что различные редакторы могли
бы взять на себя часть или вообще всю эту
работу, или существенно уменьшить, но они
могли бы это делать с помощью множества
ссылок (shortcuts), а не метафоры кода.
From: Zach Gold
Cи и Unix вырастали из вычислительной среды
последних 30 лет, чтобы в совершенстве
подходить для проблемной области. Я не
думаю, что они умрут до той поры, пока мы не
сменим "железо". Трудность
программирования на Си свидетельствует,
что наш разум - это не машина Тьюринга, или,
по крайней мере, не совместимый с машиной
Тьюринга, как любая из архитектур, которые
мы сейчас применяем. Это имеет какой-то
смысл?
Мой пример состоит в том, что человеческая
математика не совместима (not being compatible) с
машинной математикой. У людей есть
концепция чисел, существующих как стеки, в
которые можно поместить и извлечь из них. В
отличие от машинной математики, они не
составляют систему чисел (двоичную, по
основания 10) и не включают операции (сложение,
и т.п.). Да, я описываю процесс подсчета!
Этот эффект того, как мы обращаемся с
контейнерами, которые являются главным
барьером применимости между естественными
и искусственными языками. Идеальным был бы
контейнер неограниченных размеров,
допускающий вставку и удаление любого
числа элементов из любого места, наряду с
верхом и низом. Добавьте сюда хэширование и
очереди - вот вам и вся STL. Существует
несколько способов реализовать все это с
применением указателей, но они будут так
плохо компилироваться, что программа
станет бесполезной.
Причина этого в том, что бесконечность - это
несовместимость с машиной Тьюринга!
Машинной математике нужно конечное
множество атомов и операций. Я не уверен,
что объяснил все это правильно, поскольку
не очень силен в компиляторах.
From: Alan Carter
granitor wrote:
Что касается программирования, возможно,
было бы лучше работать на уровне алгоритма
и иметь нечто для генерации кода, или
наоборот, поскольку временами синтаксис
может затруднить работу над алгоритмом [алгоритм
труднее увидеть].
Абсолютно, чем меньше можно сказать на
языке, тем проще сказать то, что на нем можно
сказать. Основы теории кодирования на самом
деле. Именно поэтому у нас так много языков!
Я бы не захотел подбирать оптимальный
телефонный тариф с помощью Си, но в
электронной таблице это просто.
Электронная таблица менее общая. Детали
интерфейса на самом деле значат мало. Вы
могли бы подготовить табличный текстовый
файл и скормить его программе, которая
выплюнула бы другой текстовый файл с
небольшим уменьшением полезности (utility).
Тонкое искусство проектирования языка
заключается в идентификации абстрактного
пространства проблемной области и
выражения его с необходимой достаточностью.
Это немного связано с вопросом клико-GUI vs.
команднострочный GUI. Клико-GUI предоставляет
очень простой язык, который поддерживает
настолько малое множество несоединяемых (non-conjunctable)
операций, что они могут быть исчерпывающе
перечислены. Команднострочный GUI
предоставляет богатое множество операций
со множеством режимов их объединения.
Но исключающе мыслящие фанаты клико-GUI не
смотрят на это с такой точки зрения.
Исчерпывающий список в клико-GUI (который "обязаны
знать") привлекателен для людей, которые
(GN (Призрачное НЕ)) думают, что все, что они
знают - это все, что есть. Если им показать
интересные выражения в открытых языках, они
гневно воют - как от них можно требовать это
"знать"? Они не видят язык - они
видят бесконечный список, который нужно
вызубрить! Они действительно зубрят -
несколько раз невежественные люди заявляли,
что моя работа скучна, поскольку мне целыми
днями приходится "запоминать коды".
Это также способствует (потворствует)
заблуждению, что выражение (specifying) желаний
состоит из действий, а не из размышлений.
Если ты продумал и понял, что же ты хочешь,
то построение синтаксиса для выражения
желания тривиально. Важно не запоминание
синтаксиса, важно размышление.
From: Alan Carter
granitor wrote:
Я готов признать свое невежество, однако,
обобщенное программирование, как оно
реализовано в STL на C++, разве это не
множество алгоритмов, из которых
компилятор генерирует необходимый код для
их реализации?
Не так - это просто библиотека. Тебе по-прежнему
нужно решить, использовать, например, какой-либо
контейнер, и если ты выберешь его
неправильно, ты можешь превратить O(log N)
проблему в O(N^2) проблему. Затем STL
скомпилирует в пожирающее время приложение,
как ты и попросил. Проблема в том, что в
отличие от (думающего) человека, компилятор
не может посмотреть на твой код, понять
посредством индуктивного вывода, что ты пытался
сделать, и достичь эту цель с помощью
оптимальный действий.
[Про индуктивный вывод. Я выяснил для себя,
что некоторые математики путают (полную)
математическую индукцию, которая по сути -
особая форма математической дедукции, с (неполной)
индукцией, или просто индукцией. Кроме
математической логики есть еще и просто
логика. Человек (или какая-то часть людей)
способен к неполной индукции, компьютер -
нет. Чем, по-видимому, они и отличаются. И, по-видимому,
в этом корень проблем искусственного
интеллекта и т.п. Компьютер не способен
самостоятельно выйти за рамки заложенных в
него аксиом (теорема Геделя). - С.К.]
Может показаться, что весьма хорош SQL, но там
мы не определяем действия, с которыми
компилятор должен проделать обратное
проектирование (reverse engineer) - мы определяем
цели. И язык целей, предлагаемый SQL, на деле
очень, очень ограниченный. Что касается
кода, который поддерживает оптимизацию
действий, то это настоящая задача для
программиста. Вы можете заработать
серьезную репутацию, если хорошо в этом
продвинетесь.
From: granitor
Alan Carter wrote:
Исчерпывающий список в клико-GUI (который "обязаны знать") привлекателен для людей, которые (GN (Призрачное НЕ)) думают, что все, что они знают - это все, что есть. Если им показать интересные выражения в открытых языках, они гневно воют - как от них можно требовать это "знать"? Они не видят язык - они видят бесконечный список, который нужно вызубрить! Они действительно зубрят - несколько раз невежественные люди заявляли, что моя работа скучна, поскольку мне целыми днями приходится "запоминать коды".
Я не осознавал этого явно, но заметил
подобную реакцию.
Что касается меня, как только решаю
уделять некоторое время, чтобы
поработать над тем, чтобы решение проблемы
стало тривиальной программой, кто-нибудь
обязательно пройдет мимо и спросит, чем я занимаюсь, а
когда я начинаю объяснять, скажет "Я не
могу знать все", хотя, по-моему, это не
стоит даже упоминания. Я предполагаю, что
они думают, что каждый неизвестный им
термин, который я упоминаю, - это еще одна
книга, которую нужно запомнить целиком.
Это также способствует (потворствует)
заблуждению, что выражение (specifying) желаний
состоит из действий, а не из размышлений.
Если ты продумал и понял, что же ты хочешь,
то построение синтаксиса для выражения
желания тривиально. Важно не запоминание
синтаксиса, важно размышление.
Я согласен, просто я думаю, что было бы
лучше применять метафоры (может быть
графические, а может быть просто слова),
которые сместили бы фокус к коду, делая его
более простым, особенно для людей, у которых
мало времени на изучение того, как выразить
себя в коде. Что-то вроде Logo или подобного,
но даже более очевидное, иконки вместо
ключевых слов или что-то в этом духе.
Не для создания серверов и тому подобного,
но для более легковесного программирования.
Например, чтобы показать треугольник, углы
которого изменяются в реальном времени, на
уроке математики (для младших классов). Или,
возможно, лучшие примеры можно будет найти
только после того, как такие способы
программирования появятся.
From: Alan Carter
granitor wrote:
Я не осознавал этого явно, но заметил подобную реакцию.
Различие между C2/паковщиком и C3/картостроителем
действительно очень глубоко, но поскольку
C2/паковщик - это подмножество C3/картостроителя,
а культура, язык, парадигма от C2, то трудно
увидеть, насколько это различие глубоко,
пока не узнаешь, что искать. Тогда это
страшно.
Я согласен, просто я думаю, что было бы
лучше применять метафоры (может быть
графические, а может быть просто слова),
которые сместили бы фокус к коду, делая его
более простым, особенно для людей, у которых
мало времени на изучение того, как выразить
себя в коде. Что-то вроде Logo или подобного,
но даже более очевидное, иконки вместо
ключевых слов или что-то в этом духе.
Не для создания серверов и тому подобного,
но для более легковесного программирования.
Например, чтобы показать треугольник, углы
которого изменяются в реальном времени, на
уроке математики (для младших классов). Или,
возможно, лучшие примеры можно будет найти
только после того, как такие способы
программирования появятся.
Парень, которого я знаю, однажды создал
графическую оболочку (так случилось, что он
применял
ParcWorks, но это не важно). У него были иконки
для файлов, исполняемые программы, которые
можно было отбуксировать в середину экрана,
как процессы, и коннекторы. С помощью
получившегося набора инструментов он мог
говорить такие вещи, которые просто
невозможно сказать с использованием
командной строки bash, из-за дополнительного
измерения (extra dimension). Конечно, чтобы делать
то же самое, можно было бы определить
синтаксис оболочки для выполнения всего
этого из командной строки, но это оказалось
бы гораздо сложнее. Как только задавали
диаграмму потоков данных, графическая
оболочка производила все эти
отвратительные dup() и fork(), чтобы все
заработало.
Это то, что я имею в виду, когда говорю, что
нужно сделать, чтобы графическое
представление показывало устройство
компьютера, а не нечто другое, как стол
старорежимного клерка.
From: granitor
Alan Carter wrote:
Различие между C2/паковщиком и C3/картостроителем действительно очень глубоко, но поскольку C2/паковщик - это подмножество C3/картостроителя, а культура, язык, парадигма от C2, то трудно увидеть, насколько это различие глубоко, пока не узнаешь, что искать. Тогда это страшно.
Да. Одна вещь, которую я считаю ужасной - это то, что я называю "придание равного веса знаниям (equal weighting of knowledge)", недавно в этой переписке предположили, что если бы в новостях M0 назвали распространенной проблемой, то это стало бы просто "еще одним фактом", как любой другой пакет. Что касается меня, я был действительно обеспокоен, когда мой знакомый произнес что-то типа: "Я только что от доктора, который посоветовал мне немедленно посетить специалиста по серьезным медицинским показаниям. Однако, у меня сегодня встреча, поэтому я схожу как-нибудь в другой раз", как будто обе встречи имеют равный вес, и решение принимается исключительно по принципу "первым пришел, первым обслужен".
From: Alan Carter
granitor wrote:
"...Однако, у меня сегодня встреча, поэтому я схожу как-нибудь в другой раз", как будто обе встречи имеют равный вес, и решение принимается исключительно по принципу "первым пришел, первым обслужен".
Да. Это тот способ, которым ежедневно оценивается риск в обществе M0. Почему ничтожнейшая тривиальность может стать более важной, чем масса фатальных изъянов (showstoppers) в проектах систем. Почему большинство ритуализированных работников (менеджеров) всегда отстаивает коротенькие "заплатки", замалчивая их цену с точки зрения проекта. Почему политические журналисты не применяют электронных таблиц и т.д.
Перевод: Prog.Stone
Русский сайт Programmers' Stone / Reciprocality : progstone.narod.ru или progstone.narod.ru
1 декабря 2001