Тематика дискуссии или О ГЛАВНОМ
Aku-Aku
в междометиях.
Ясно что тема эта о програмировании. Но сегодня, как никогда,
програмирование очень широкая тема.
Я предлагаю поговорить об эффективности програмирования.
Лично мне не хочется утонуть в какой-то одной специфической теме,
вроде оптимизации, или использования функциональных языков, или
новомодных быстрых методик.
Хочу посмотреть на проблему в общем, как на техническую проблему.
Я уже упоминал раньше о практике ТРИЗ (теории решения изобретательских
задача) -- хочу попробовать применить её методы.
Есть там такой -- ИКР -- метод когда для решения задачи пытаются
представить себе идеальный конечный результат. Что помагает лучше
понять условия задачи и чего мы в конце концов добиваемся.
Что же можно назвать идеальным конечным результатом. В терминах ТРИЗ
ИКР означает что задача решена так, что для выполнения задачи не
требуется никаких (в идеале) или очень мало ресурсов, когда она
решается вроде сама собой. (кому интересно, в ТРИЗ много
хрестоматийных примеров такого плана)
Вот и я, хочу здесь определить эффективное програмирование как такое,
что практически не требует програмирования.
Предлагаю поразмыслить (пофантазировать?) на тему как сделать
програмирование, как техническую системц, одновременно и мощным, и
легким, и незаметным для того кто его использует.
Aku-Aku
Какой-то ТРИЗ, какой-то ИКР... совсем не похоже на разговор о
програмировании. :)
Надеюсь дальше будет интереснее.
Есть в ТРИЗ еще один метод -- операторы РВС (Размер, Время, Стоимость)
Это когда задачу пробуют представить по-новому, представив что эти три
параметра сильно отличаются от реальных в большую или меньшую
сторону.
Например, размер.
Представим что перед нами стоит задача написания абсолютно минимальных
программ -- размером в один бит -- как тогда будет выглядеть
програмирование? А если наоборот. Программа должна состоять из гугона
(десять в сотой) бит, как тогда?
Ну с однобитовой программой все вроде ясно.
Оформляем текстовый файл исходного кода -- пусть это будет один
символ, плюс форматирование, плюс коменты.
Исходя из современных технологий (прежде всего компилируемых)
получиться где-то десятибайтовый файл исходника.
Дальше проганяем его не компиляторе, линкуем.
Хм.
Как бы, не получается минимальной программы. В результате компиляции и
ликовки ну никак не получится минимальной программы (пусть даже в один
байт, а не бит)... что-то здесь не так.
Дальше.
Берем программу в гугол бит. Что делать с ней?
Ведь даже для её записи, не то чтобы компиляции и исполнения не хватит
всех атомов вселенной.
И это при том, что мы то знаем, что в этой программе скорее всего
очень и очень много дублирования, повторяющихся участков кода и т.п.
Дальше берем время.
Что если на написание програмы нам дана всего одна наносекунда?
Человек не способен мыслить с такой скоростью -- как тогда решеть
такую задачу.
Или дано время до конца тепловой смерти вселенной (наверняка для
написания гугольной программы :) ).
Как будем действовать тогда?
Ведь даже после первого миллиона лет получится что мы имеем чотрову
уйму унаследованного кода, который уже никто не помнит как писался и
собирался.
Еще один параметр -- Стоимость.
Предположим что максимальная сумма которую можно получить за
разработку -- один цент.
Тогда чтобы нормально заработать нужно уметь плодить программы со
скоростью дюжину за секунду.
Как это можно реализовать?
Или наоборот. Одна программа стоит очень очень дорого.
Например, только у Била хватит денег, если отдаст все свое состояние
за эту программу.
Как быть всем остальным? Как разработать такую одну программу, стоящую
как программа полета на Марс, чтобы подошла всем, чтобы использовалась
достаточно долго и окупила вложения?
Ну что, раскрепощаем фантазию?
Artem Chuprina
"запрограммировать" есть две постановки.
Одна - это создать программу, решающую сложную задачу, которую на момент
постановки задачи, вообще говоря, еще непонятно, как решать. Зато на ее
решение можно выделить немалое количество ресурсов.
Другая - "если ты поймал себя на том, что в третий раз выполняешь один и
тот же алгоритм вручную - пора писать программу". Тут количество
ресурсов мало.
Создатели UNIX полагали, что между этими двумя постановками пропасти
нет, в крайнем случае - она вполне преодолима. Примерно то же полагал и
Ершов, продвигая концепцию "программирование - вторая грамотность".
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: r...@jabber.ran.pp.ru
Дело говоришь!
Теперь делай его.
Кнышев.
Artem Chuprina
A> Я понимаю что то что выше написано не больно интересно. Какой-то
A> ТРИЗ, какой-то ИКР... совсем не похоже на разговор о
A> програмировании. :)
Как раз наоборот. Чем менее похоже, тем интереснее. Вот в этом письме
как раз не очень интересно, но кое-что все же есть, а две мысли -
лучше, чем одна мысль...
На правах потока сознания. Получилось, гм, как обычно, "все придумано
до нас".
A> Например, размер.
A> Представим что перед нами стоит задача написания абсолютно минимальных
A> программ -- размером в один бит -- как тогда будет выглядеть
A> програмирование? А если наоборот. Программа должна состоять из гугона
A> (десять в сотой) бит, как тогда?
A> Ну с однобитовой программой все вроде ясно.
A> Оформляем текстовый файл исходного кода -- пусть это будет один
A> символ, плюс форматирование, плюс коменты.
A> Исходя из современных технологий (прежде всего компилируемых)
A> получиться где-то десятибайтовый файл исходника.
A> Дальше проганяем его не компиляторе, линкуем.
A> Хм.
A> Как бы, не получается минимальной программы. В результате компиляции и
A> ликовки ну никак не получится минимальной программы (пусть даже в один
A> байт, а не бит)... что-то здесь не так.
Хотите, я покажу Вам программу в 0 бит? Пустая строка, ага. Вполне
валидная программа на perl, python, tcl, lisp, sh. Ну ладно, пустая
программа слишком тривиальна. Программа из 1 байта (с 1 битом сложно -
гранулярность размера программы на доступной мне технике все же байт, а
не бит) вполне возможна на 3 из этих 5 языков (домашнее упражнение - на
каких?).
Что? Машинный код? А при чем тут машинный код? Мы про
программирование (т.е. написание программ) или про их выполнение? Я вот
недаром писал слово "lisp-машина"... С точки зрения почти кого угодно
компьютер сейчас не является машиной для исполнения бинарного кода. С
точки зрения пользователя он ... даже не Windows-машина. Он
Word-машина, Excel-машина, Photoshop-машина, а то и просто
Internet-машина. У грамотного программиста он может работать
lisp-машиной, perl-машиной и т.д. Он "стоит на плечах гигантов".
А машиной для исполнения бинарного кода компьютер давно уже не является
даже в отсутствие ОС. Чтобы программа попала в процессор, требуется
несколько программ, работающих в нескольких вспомогательных процессорах.
Так что принципиальной разницы между бинарным и перловым кодом нет (она,
впрочем, и с виду не всегда заметна при взгляде на перловый код...)
A> Дальше.
A> Берем программу в гугол бит. Что делать с ней?
A> Ведь даже для её записи, не то чтобы компиляции и исполнения не хватит
A> всех атомов вселенной.
A> И это при том, что мы то знаем, что в этой программе скорее всего
A> очень и очень много дублирования, повторяющихся участков кода и т.п.
А вот совсем не обязательно. Как сказано в одной из моих фортунок,
Will write code that writes code that writes code that writes code for
money.
-- on comp.lang.lisp
Можно, натурально, написать и с неповторяющимся кодом. И гугол. И не
записывать, а исполнять прямо на ходу, дабы избежать проблем с
количеством атомов....
Можно даже написать так, что результирующий код не будет определяться
детерминированно кодом, написанным программистом (т.е. информации там
будет больше, чем в оригинале). Был бы источник энтропии...
И решать этим кодом NP-задачи за полиномиальное время. Ибо обращение к
оракулу.
A> Дальше берем время.
A> Что если на написание програмы нам дана всего одна наносекунда?
A> Человек не способен мыслить с такой скоростью -- как тогда решеть
A> такую задачу.
Will write code that writes code ...
Впрочем, на практике я применю другой подход. Время на написание
программы включает время на постановку задачи. Посколько на все про все
наносекунда - у вас 0.1 нс на постановку задачи. Время пошло.
Хотя написать программу, способную написать программу (в 0 байт,
см. выше) за наносекунду, задача сложная (нано- это 10^{-9}? Типа 2-5
тактов современного процессора?), но реальная. А дальше исходную задачу
"напишите программу за наносекунду" мы будем решать этой программой.
Компиляция - это по сути почти оно же. Только немножко через зад.
A> Или дано время до конца тепловой смерти вселенной (наверняка для
A> написания гугольной программы :) ).
A> Как будем действовать тогда?
A> Ведь даже после первого миллиона лет получится что мы имеем чотрову
A> уйму унаследованного кода, который уже никто не помнит как писался и
A> собирался.
А вот это - проблема, проявляющаяся уже на временах порядка года.
Правда, решать ее в таком порядке народ кое-как научился, но на миллион
решения масштабируются хреново. Впрочем, тоже прикидывать надо.
Лисповый car когда в первый раз был написан? Или кто там выражается
через примитивы? eval? И чо? До сих пор работает... А он по крайней
мере концептуально сложнее типичной современной ОО-программы... Зато
лучше специфицирован...
A> Еще один параметр -- Стоимость.
A> Предположим что максимальная сумма которую можно получить за
A> разработку -- один цент.
A> Тогда чтобы нормально заработать нужно уметь плодить программы со
A> скоростью дюжину за секунду.
A> Как это можно реализовать?
Will write code that writes code that writes code that writes code for
money.
Все придумано до нас :-)
A> Или наоборот. Одна программа стоит очень очень дорого.
A> Например, только у Била хватит денег, если отдаст все свое состояние
A> за эту программу.
A> Как быть всем остальным? Как разработать такую одну программу, стоящую
A> как программа полета на Марс, чтобы подошла всем, чтобы использовалась
A> достаточно долго и окупила вложения?
В смысле - разработка программы? Ну так это тоже придумано до нас. Я
вот сейчас пишу письмо в одной такой программе. emacs, ага. Она еще и
не продается обычно. Ее просто берут и пользуются. Вложения в нее, как
и в любую другую программу - это труд, а не деньги. И если не пытаться
подменять одно другим, проблема не то чтобы не встает, но находится не
там. На этой разнице построено все Free Software и больше половины,
подозреваю, коммерческого.
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: r...@jabber.ran.pp.ru
Functional programming is like describing your problem to a
mathematician. Imperative programming is like giving instructions to
an idiot.
-- arcus, #scheme on Freenode
Aku-Aku
Aku-Aku
Видно сильно сложно програмерским мозгам подумать о чем-то
нестереотипном.
(никаких намеков на персоналии, просто я и сам в себе замечаю привычку
"не придумывать велосипед")
Artem Chuprina
A> Что-то заглохла дискусия.
A> Видно сильно сложно програмерским мозгам подумать о чем-то
A> нестереотипном.
A> (никаких намеков на персоналии, просто я и сам в себе замечаю привычку
A> "не придумывать велосипед")
Я думаю...
Вообще у меня как "типа итог" последнего всплеска выплыла следующая
мысль. Прежде чем придумывать новое решение, хорошо бы понять, чем не
устраивают существующие. Это очень помогает в понимании того, в чем,
собственно, заключается задача.
Именно это мне не понравилось в Вашей попытке начать с изобретения
велосипеда. Развитие показало, что да, с пониманием задачи все не очень
хорошо...
К теме дискуссии я вернусь чуть погодя. Когда мысли оформятся.
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: r...@jabber.ran.pp.ru
If it's there and you can see it---it's real
If it's not there and you can see it---it's virtual
If it's there and you can't see it---it's transparent
If it's not there and you can't see it---you erased it!
IBM poster explaining virtual memory, circa 1978
Aku-Aku
добится лучшего понимания задачи.
Чтобы отойти от стереотипного понимания, чтобы не плясали перед
глазами белые оезьяны.
Alexander Mayboroda
> На правах потока сознания. Получилось, гм, как обычно, "все придумано до нас".
>
> A> Ну с однобитовой программой все вроде ясно.
>
>
Да мало ли, например потому что должна устанавливать или инвертировать один бит какой-то гипотетической машины.Не суть важно.
Главное, что сколь-нибудь приемлемого решения вы предложить не смогли, а потратили время целиком на то чтобы опровергнуть постановку задачи.
Так дело не пойдет.
Человек верящий в то что земля плоская никогда не захочет полететь в космос.
И даже если его поставить перед такой необходимостью, скорее будет придумывать отговорки, почему этого сделать невозможно.
А вот я вам приведу пример такой програмы. В первых компютерах, для заполнения памяти машины использовались тумблеры, какраз по штуке на один бит.
Правда это все равно не эффективно. Можна взять и другой пример. Древний формат исполняемого файла -- COM. В котором код программы начинался по смещению 0 файла.
Значит в нем достаточно знать нужную нам инструкцию и можна сразу её вводить и исполнять. Есть даже програмка debug.exe во всех версиях Вин, которая упрощает эту задачу.
> Что? Машинный код? А при чем тут машинный код? Мы про
> программирование (т.е. написание программ) или про их выполнение?
> lisp-машиной, perl-машиной и т.д. Он "стоит на плечах гигантов".
>
А кодирование без исполнения и получения результата -- это просто новый высокотехнологичный вид графомании.
> Впрочем, на практике я применю другой подход. Время на написание
> программы включает время на постановку задачи. Посколько на все про все
> наносекунда - у вас 0.1 нс на постановку задачи. Время пошло.
>
> Functional programming is like describing your problem to a
> mathematician. Imperative programming is like giving instructions to
> an idiot.
> -- arcus, #scheme on Freenode
Потому как и для функционального подхода хватает проблем, когда пробуют его внедрять в вотчину императивного.
Вот мне интересно. Есть ли какие-то удачные примеры реализации на функциональных языках интерфейса вхаимодействия с человеком (тот самый ГУИ),
который по сути сам диалогово-императивный?
ЗЫ Все так же какие-то непонятные траблы с отсылкой сообщений.
--
/ - - - - - - - - - - - - - - - - - - -
Best regards from Aku-Aku
Mayboroda Alexander, Chercassy, Ukraine
ICQ: 339413786
e-mail: aku...@mail.ru, alexande...@gmail.com
Artem Chuprina
A> Ну так я и затеял все это начинание с ИКР и РВС, для того чтобы
A> добится лучшего понимания задачи. Чтобы отойти от стереотипного
A> понимания, чтобы не плясали перед глазами белые оезьяны.
Ок. Чем не устраивают изложенные мной решения с РВС? Представим себе
на минутку, что я их сам придумал (что, собственно, и наблюдается - это
подходы там придуманы до меня, а применить их к этим задачам придумал я
сам).
С однобитовой программой не удалась постановка задачи, как показал
разбор. Там надо сначала придумать все же, какие условия, помимо
размера в один бит, накладываются на программу, чтобы решение "1" или
"0" (там чисто теоретически возможно два решения, ага) было принято. У
нас получается, что решение либо тривиально (если не закладываться, как
в постановке задачи, на существующие системы), либо принципиально
невозможно (если, как в постановке задачи, на них закладываться). С
бесконечным временем я решения не предложил, и это да, думать надо.
Остальные?
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: r...@jabber.ran.pp.ru
А еще следует потребовать, чтобы программисты, перед тем, как писать код,
внимательно прочли спецификацию: с сыром - это чизбургер.
Игус в <Pine.LNX.4.44.0401231840020.15582-100000@moon>