Количество разума на планете - величина постоянная. А население растет... Хотя нет, я же хотел рассказать что-то другое...
Все мы конечно выдающиеся мыслители, но проблема в том, что человеческий мозг использует свой потенциал лишь на 5%. И имеющегося в нашем распоряжении потенциала катастрофически не хватает на все. Наша краткосрочная память может запоминать одновременно только семь объектов. Это означает лишь одно - чтобы в голову приходили хорошие мысли нужно стараться не расходовать наш мыслительный потенциал попусту. То есть, не надо думать про то, про что думать не требуется.
В былые времена оперативной памяти постоянно не хватало. Что только не придумывали люди ради этого. Помню были утилиты, позволяющие использовать видеопамять в качестве оперативки - 700 килобайт основной памяти... это было круто. Но это только цветочки.
Программисты напрягались границами сегментов и моделями памяти. Но гораздо сложнее было было программистам, программирующим ресурсоемкие приложения. Существовала когда-то технология оверлеев. Это когда толстый бинарник загружался в память по частям. Причем эта возможность поддерживалась компиляторами. Я к сожалению не знал толком как этим пользоваться, не доводилось. А сейчас это уже практически никому не интересно.
И вот пришла эра плоской памяти. И случилось чудо, думать о использовании памяти стало не нужно. По большому счету именно тогда, наверное, отпала необходимость оптимизировать. Не скажу точно, чем заполнился оставшийся свободным потенциал... много воды утекло с тех пор. Хотя нынешние архиваторы жмут не в пример лучше тех.
Но потенциала то больше не стало. Программируя мы невольно думаем о том, что ограничивает нас. И это ограничивает нас еще больше, потому что мы невольно делаем все основываясь на ограничениях. Ограничения нами управляют, они есть и не думать о них не очень то получается. Сам не понял что сказал, но поедем дальше. Наверное здесь стоило бы ввернуть пару поучительных примеров, но думаю что многим мои примеры покажутся надуманными и неинтересными, как и эта статья. Хотя пожалуй вот...
Я долгое время не хотел писать ядро на C++, во первых для этого требуются хорошие знания C++, которых пять лет назад откровенно не хватало. Во вторых я считал, что на ассемблере я лучше представляю себе взаимодействие с железом... С C++ это было правильно, потому что борьба с языком слишком сильно отвлекала меня от мыслей о логике ядра. Может быть именно это и отвращало меня от C++ тогда.
Прошло время, знаний C++ прибавилось, кроме того прибавилось понимания того, что имеющееся железо - это лишь средство функционирования системы. Оно не должно руководить. После чего ядро разделилось на две части. Высокоуровневая часть вообще ничего не знает о железе, а лишь формирует логику взаимодействия объектов ядра. А низкоуровневая часть могла бы по прежнему остаться на ассемблере, но она стала на си, что в принципе несущественно, все равно не переносимо.
Но после этого стало ясно что высокоуровневая часть не просто не зависит от железа, но может вообще работать практически в любых условиях (не иначе как освободившийся потенциал мозга подкинул такую идею), и я могу запускать ее абсолютно в любом окружении (ну где есть C++), естественно при наличии соответствующей этому окружению платформенной части.
Прозрения в принципе случаются в разных областях. Например вот раньше интернет файлохранилища неизбежно обзаводились зеркалами. Взять к примеру Sourceforge.Net, помню времена когда зеркал у него не было (я пользовался им с 2002 года). Но с ростом популярности опенсорс, нагрузка на сервер возросла, и назрела необходимость ее распределять, и появились зеркала. В принципе логично. Но не слишком гибко.
Но вот с некоторых пор я перешел на Google code, мне наскучил SF с его избыточным интерфейсом, люблю лаконичность, а GC необычайно лаконичен. И вот что я думаю. При всей популярности GC, при всей нагрузке на их сервера им вряд ли когда нибудь понадобятся зеркала в традиционном понимании этого слова, у них и так достаточно распределенная структура. И уж конечно они не будут каждый раз спрашивать у пользователей с какого зеркала они предпочитают скачивать (они сами все лучше нас знают :D SkyNet блин).
И вот думаю, в юниксе традиционно приложения имеют стандартный ввод, и два стандартных вывода (по большому счету один). И хоть при дальнейшей работе они могут использовать произвольное количество вводов-выводов, но это все равно накладывает ограничения на их использование. Какие перспективы открылись бы перед приложениями если бы количество потоков было бы неограниченным? Может быть именно из за этого и придумали контейнеры, типа avi? Как в свое время придумали оверлеи ради преодоления ограничений памяти? Хотя надо было просто придумать линейную память. :)
Где-то я уже слышал (в NTFS кажется) про файловые потоки. Файловые метаданные тоже что-то никак не найдут себе достойного применения. Идеи витают в воздухе... где же прорыв?
Или вот еще про приложения думаю. В юниксе традиционная мелкозадачность. То есть для каждой конкретной задачи свое приложение, скрипты кишмя кишат в наших системах и постоянно десятки приложений запускаются и останавливаются. На что мы тратим свои гигагерцы? Альтернативой могло бы стать сервисное взаимодействие, то есть не библиотеки и не приложения, а некие службы. Гибкости в этом варианте гораздо больше но почему-то опять таки пробивается плохо. COM еще жив? Может быть нафиг объекты, да здравствует HTTP-like? как там все просто и гибко. Может быть именно это стремление обуславливает нынешнее развитие SAAS?
Собственно к чему я это все. Ограничения управляют нашим мышлением. Мы мыслим в рамках. В некоторых случаях это может быть оправданно, но не замечая рамок и ограничений можно увидеть и понять то, что раньше казалось невозможным. Ложки нет...
Построить Qt из исходников под Linux
6 месяцев назад
13 коммент.:
Насчёт использования 5% потенциала мозга, я где-то встречал исследования учёных, где установили, что мозг задействован на 100% своих ресурсов.
Думаю, если бы реально потенциал был очень высоким, то процент умных людей был бы гораздо выше текущей статистики. Налицо физические ограничения.
А никто точно не знает... :) Но насчет 7 объектов - это скорее всего близко к среднестатической истине.
Поэтому когда мы начинаем думать о том как разместить объект в памяти вместо функций объекта, или например как снизить нагрузку на сервер вместо наполнения сервера, мы по большому счету тратим свои ресурсы впустую.
Правильно Джоэл сказал... один два года оптимизирует программу для 286, а другой эти два года наворачивает новые фичи. И тут бац, выходит 386, и второй выиграл, потому что его программа не в пример круче.
Но может показаться что это весьма грубо. Всмысле расточительно. Но оказывается не так... когда мы начинаем думать о назначении объекта, мы лучше понимаем что от него требуется и соответственно код получается качественнее и оптимальнее.
Вот я где-то это хотел сказать. :)
Поэтому, чтобы мозг работал хорошо, его надо как i386 загружать оптимальными программами, т.е. самыми полезными знаниями и оптимальными алгоритмами, иначе будет тормозить и свопиться (придётся постоянно копаться в справочниках) :-)
Оптимальность - это и есть отсутствие лишнего...
Ну про лишнее и не лишнее я наверное еще потом что нибудь напишу... :) тоже сходная тема.
Проблема с мозгом в том, что он каждые 2 года не увеличивается в 2 раза :-) Поэтому верно, надо сосредоточиться на чём-то одном, на какой-то определённой стратегии.
А это была другая тема, если кто не понял (наверное я плохо ее раскрыл, но как мог)...
смысл заключался в том, что когда мы перестаем смотреть под ноги - мы начинаем видеть горы... :)
Про работу с 7 объектами не совсем понятно. Я когда разрабатываю функии ОС, учитываю до 100 сущностей одновременно, ведь ОС устроена сложно. При этом я не считаю себя умнее других, профессионалы в других областях тоже анализируют десятки и сотни сущностей одновременно. Представь хирурга, делающего операцию, или водителя грузовика, едущего по городу.
Вот тут ты не прав... Вокруг тебя могут быть тысячи объектов, но сконцентрирован ты всего на нескольких... и одновременно ты можешь думать лишь о взаимодействии нескольких объектов... среднестатически - семи. Возможно выдающиеся умы могут обдумывать 20 объектов одновременно... :) Но никак не 100.
Что касается вождения - то там все не так сложно. управление машиной практически не требует умственных усилий - оно автоматическое. Для безопасного вождения достаточно контролировать впереди/сбоку-едущие машины, то есть максимум 5-6 штук. При отсутствии машин необходимо контролировать обочину дороги - одну штуку, на предмет появления дополнительных объектов. :)
Конечно свободные резервы можно использовать для контролирования более удаленных машин... Но это опционально.
Сзади едующие машины нужно контролировать только когда тормозишь :), тогда отпадает необходимость контролировать впередиедущие.
Я сам водитель и уже почти 10 лет за рулем, я не просто так говорю. :)
Про краткосрочную память - это я скопировал. Непонятно насколько краткосрочная и что значит одновременно :)
На самом деле я, в предыдущем комменте, тоже был немного неправ.
То, на чем сфокусировано наше внимание - это одно. Взять к примеру водителя - Визуально он контролирует лишь один сектор. Стоит посмотреть налево - нет ли помехи, как правый сектор становится неконтролируемым.
Но это не мешает мозгу адекватно оценивать ситуацию. То есть объекты, с которых уходит фокус внимания всеравно анализируются мозгом - просчитываются как бы.
Но при этом, если в неконтролируемом секторе произойдут какие-то непредсказуемые изменения, рассчеты мозга могут оказаться несоответствующими действительности. :)
А глаза наши - вообще весьма несовершенны. Только благодаря мозгу мы видим то, что видим :)
Но есть еще слух, который позволяет мозгу дополнять видимое и невидимое состояние реальности. :)
Есть ещё интуиция, которая не зависит от количества наблюдаемых объектов :-)
Каждый шаг в развитии программирования - это переход на более высокий уровень абстракции, при этом откидываются вспомогательные детали. Сложность программ растёт. Этот процесс является необходимым, потому что если не отбрасывать лишнее, то в массе деталей мозг "утонет".
А про мозг ещё интересная новость:
"http://www.svobodanews.ru/news/science/2008/07/16.html?id=456500"
обработка многих потоков, сервисы? Хмм... А ведь эти идеи давно витают в воздухе, но благодаря инерционности человеческого мышления постоянно проигрывают в распространённости:
1. Микроядро - ядро системы взаимодействующих сервисов,
2. BeOS - вьюверы картинок, пользующиеся системынми плагинами (каждый плагин умеет просматривать свой тип картинок, но используется разными вьюверами),
3. dbus - сервер сообщений GNOME и KDE,
4. plan/inferno - система, которая является Unix'ом больше, чем сам Unix,
и т.п.
Отправить комментарий