Не так уж и далеко, если честно. До Inferno была Ada, был Oberon, была Lisp Machine, с точно такими же идеями. Сейчас есть JavaOS и Erlang. Они не новички в этом.
Inferno и Plan9 далеко ушли в другом: в эффективной и в простой для использования распределённости и в очень простом для программиста и пользователя API. Это действительно уникально и даёт много интересных возможностей.
Совсем не важно, на каком языке система написана, важно, что она позволяет делать.
Ну. Согласен с высокой производительностью I/0, она действительно не зависит, обычно, от способа исполнения программы, но иногда данные обсчитывать приходится, и тут уже Perl не поможет, как ни распараллеливай. Потому что, чем больше параллельности, с той целью, чтобы каждый процесс работал с небольшим объёмом работ, тем больше времени будет растрачиваться на обмен данными между узлами, что тоже занимает время. Иногда весьма значительное. Поэтому язык с 'толстыми' указателями и постоянной проверкой доступа к памяти, для таких задачек может и не подойти. А задачки есть такие. У меня по крайней мере, поэтому plan9.
Тык, чтобы коммьюнити была стойкой, она должна быть честной с самой собой. И не говорить, что plan9 - больше теоретическая, а Inferno - больше практическая. Видите, какая у меня, части community, ибо неравнодушен к 9p, реакция. И никакой идеологии в моих словах нет, скорее уж желание восстановить справедливость. Но, признаю свою ошибку, я не корректно выразился. Inferno и Plan9 одинаковые по интерфейсу к функциональности, по философии их использования, но созданы с разными целями. Поэтому говорить, что одно теоретическое, а другое практическое у нас нет оснований, они просто разные.
В Plan9 больше практики. Она эффективнее, и она реально используется. Скорее уж Inferno - это некая теория насчёт того, как можно сделать нечто легковесное, переносимое и надёжное. Но они жертвуют производительностью, значительно. Сервер на Inferno я бы поднимать не стал.
Конкретно в этом аспекте организации вычислений inferno полностью повторяет Plan9, документацию на которую можно раздобыть тут http://plan9.bell-labs.com/ . Можно почитать об идеологии и о том, как всё работает. Это я к тому, что документации мало.
Вам определённо следует учесть, что я прочитал 'Шаблоны' : ) И ничего нового для себя не открыл, всё то же самое, но не феноменологически: в этом случае делаем так, а в этом так, а в третьем задом-наперёд - а на гораздо более строгом и детальном уровне, в реальном коде, а не в стрелочках, описано у Бадда в 'ООП в действии' или у Голуба в 'правилах программирования на C и C++'.
Функциональное программирование больно той же самой болезнью: нужно проектировать задом наперёд. Сначала проектируется общий вид основной функции, а потом всё ниже и ниже проектируются вспомогательные. То же самое в ООП: сначала проектируем интерфейс, а потом пытаемся реализовать. И если интерфейс оказался неподходящим, то переделывать придётся весь код. Если высокоуровневая функция в функциональном подоходе оказалась неподходящей, то переделывать весь код придётся в гораздо большей степени, чем в императивном ООП.
Оба подхода заставляют по форме (что должно быть) определить содержание (как должно быть). Вобщем-то вполне себе математичный подход. Теоретически красивый. Да, мы вот сейчас всё пишем и пишем, и на словах, действительно ООП гораздо красивее обычного структурного подхода. Кроме того, можно кучу книжек писать, ООП - богатая среда для мудрствований, например, вот те же замечательные философствования о шаблонах и рефакторинге. Так же как и функциональное программирование, а когда оно ещё и с монадами, то вообще, ууУУух как поумничать можно и статьи пописать.
C же освобождает от необходимости проектировать строго определённый интерфейс, конечно, от ответа на вопрос: что код должен делать? уйти вряд ли удасться, но ответ этот может быть достаточно нестрогим. Язык ориентирован на работу с данными, а не объектами. Если я совершу ошибку на этапе придумывания интерфейса, то мне никто не мешает напрямую залезть в структуру данных, и написать новый код для работы с ней, в том месте, где он нужен. Да, это грязно, это не математично, это нарушение кучи принципов, об этом не напишешь умную книжку, потому что это глупо, но это работет. И работает не только корректно, но и эффективно. Если подобный код мне нужен будет во многих местах - родилась абстракция - я его вынесу в соответсвующий модуль, и доступ к нему сделаю частью интерфейса.
Мог бы я подобное обнаружить на бумажке? Запросто, если бы писал на бумажке настоящую программу, до уровня операторов и вызов функций, а не просто рисовал бы стрелочки, то наверняка обнаружил бы то же самое. Но на бумажке невозможно написать нечто более или менее сложное.
Я могу предполагать, что в этом случае списки эффективны, но на реальных данных может оказаться, что они убивают производительность, или, вдруг оказывается, что для реализации некоторой возможности в новой версии нужно обращение к произвольному элементу. Если я это всё буду учитывать только после того, как напишу программу на бумажке, потом закодирую на ООП, потом откомпилирую, потом пойму, что все мои расчёты, мягко говоря, некорректные, потом опять сяду за бумажку... Я рискую ни одной эффективной программы за всю жизнь не написать.
В итоге, конечно, у меня тоже появляются объекты в программе, но границы у них не жёсткие, а размытые, и объекты именно появляются, а не спускаются сверху. Не тотальная закапсулированность позволяет упростить взаимодействие, особенно, при использовании в новом коде. А то, что объект возник естественным путём освобождает меня от необходимости прописывать какую-то невостребованную функциональность.
Да, всё то же самое можно делать и на C++, например. Но тогда надо будет делать все данные и методы изначально открытыми, и возникает вопрос, а зачем тогда этот весь этот лишний классовый синтаксис?
Ещё можно сказать, что в Smalltalk именно так формировались интерфейсы. Они формировались снизу вверх. Они возникали, а не навязывались сверху. Наследования же вообще не было. Все эти, на мой взгляд, сложности, связанные с проектирование сверху вниз, появились в компилируемых языках, в которых для повышения эффективности стали путать типы и объекты.
И последнее замечание: в книжках по функциональному программированию, обычно, всё истолковывается в терминах и примерах из императивных языков программирования, поэтому, в них со сравнением с другими технологиями всё лучше.
О чём, собственно, и речь. Либо я должен ограничивать полёт своей мысли некими шаблонами, которые вполне могут не вписываться в решаемую задачу, а для этого изучать много умных слов и тратить время, которое я могу потратить на разработку алгоритмов. Или я сам должен придумать шаблоны, но тут опять полезут сложно исправляемые глюки в будущем.
И я должен буду выполнять много сложной работы по переписыванию кода, настолько сложной, что для этого появляются автоматизированные средства.
Теоретически, всё верно. Но быстро выстроить хорошие абстракции очень сложно. Нет, конечно, если человек может делать это быстро, то у него превосходный интеллект, я бы сказал на уровне гениальности, но многи ли таких людей? Обычные люди, как убедительно показывают исследования в области истории науки, абстракции, не формулируют перед началом работы, а находят в процессе исследований. Абстракция - это обобщение свойств. А как можно начать обобщение свойств, когда компоненты ещё не написаны? Конечно, можно указать множество ситуаций, в которых можно прибегнуть к имеющемуся опыту. Например, кнопка там, или итератор, они и в Африке кнопка или итератор. Но что если программа к этому не сводится? Когда абстракции понятны - ООП рулит, очевидно и неоспоримо. Расширяться тоже можно просто и без проблем, реализуя уже найденные интерфейсы.
Но для новых проектов всё это ООП - зло. Оно заставляет поиск решения производить задом наперёд: придумали абстракцию начали делать, а потом, хопа, поняли, что всё это работать не будет, и начинается изменение всей иерархии. Это же сложно и время отнимает, поэтому люди начинают нарушать парадигму на право и налево. Но возникает вопрос: а зачем тогда вообще они начали писать свои классы?
Насчёт free. Частое использование malloc/free - это рузультат неправильного проектирования, по моему мнению. И является болезнью больших проектов, в которых писают всё написать на C. Но C придумывался не для этого. Компоненты, написанные на C должны быть маленькими и максимально специализированными под решаемую задачу. Большая же решается через объединение компонентов через IPC. Это удобнее, чем придумывание иерархий, потому что позволяет вклиниваться и менять взаимодействие между компонентами как угодно.
Попробуйте воткнуть дополнительную обработку в pipe, или дополнительную обработку во взаимодействие между двумя объектами, когда один вызывает другой. Как минимум, придётся нечто наследовать, заново думать над тем, что должно быть виртуальным или не виртуальным. И так далее. Много работы. Может быть, именно поэтому, все сложные ОО системы рано или поздно приходят к тому, чтобы создать свою транспортную систему данных между объектами. Или воспользоваться существующей в виде базы данных или чего-нибудь, вроде, CORBA. Но это всё усложнения, усложнения и ещё раз усложнения. Которые надо осваивать, особенно при коммерческом программировании, а это всё уводит сознание от размышлений над другими методами организации вычислений. Существенно более гибкими и простыми. Ну вот сравнить хотя бы ту же CORBA с plumber'ом из Plan9 или Linda.
Поэтому я против ООП. Мне не нравится, когда навязываются сложности и неэффективности, да ещё такими ненаучными способами: вы хотя бы в одной книге по ООП видели сравнение предлагаемых способов решения тех или иных иных задач в этой парадигме с решением их в других?
КРоме того, GUI очень просто пишется на tcl - средстве, которое разработано, чтобы сшивать различные функции на C. Вот. Логика у него такова, что памятью в tcl программе очень просто управлять автоматически, а на tcl/tk GUI писать - совершенно очаровательное дело. Надо кнопку - пишем buttom и не мучаемся : ) Это я к тому, что все эти сложности с объектами, иерархиями, интерфейсами и прочим - совсем не обязательны, чтобы писать быстро и компактно.
Лёгкий GUI, написанный на Python превращается в очень тяжёлый GUI. Тяжёлый для пользователя, конечно: подтормаживает, память поджирает, процессор грузит. Не самая сложная программа, например, gajim, которая вобщем-то есть GUI для Jabber, может очень сильно начать греть процессор и грузить swap. Странно, но гораздо более сложный и функциональный gaim намного реактивнее. При этом, объём его кода всего на 30 процентов больше (а, напомню, протоколов он поддерживает в 6 раз больше). Вот такие пироги.
Почему? Люди любят учиться и разбираться, иначе они не пошли бы в программисты. Только разобраться во всём очень сложно. А работодатель заставляет разбираться не в самых эффективных средствах разработки. А раз человек выучил интерпретируемый язык, потому что все вокруг хотят от него того, чтобы он его выучил, и раз он может написать на нём программу, которая его устраивает, он и будет это делать.
Удручает только то, что вместо, например, огромной библии программирования на с++ или толстенной camelbook он бы мог прочесть тоненькую книжку о 'c', и толстую книжку об алгоритмах и структурах данных, да пару руководств по shell с описанием всяких утилит, вроде sed, что позволило бы ему писать более эффективно и быстро, да к тому же использовать все возможности существующего кода.
Тоже хочется про языки сказать. Вы не забывайте, что удобный и используемый язык - это не то же самое, что и язык за знание которого нанимают. C++, C#, Java, Perl - это то, за что платят, а платят потому что те, у кого есть деньги, частенько понятия не имеют, с чем они сталкивают своих программистов. Нет у них времени разобраться, поковыряться, и найти горы глюков, неконсистентностей, сложностей во всех этих раскрученных средствах разработки. Всё это есть в любях языках, например, в C кошмар с #include или деление на значение по адресу. Но чем меньше язык, тем этих глюков меньше. Perl, C++, C# и современная Java - большие языки.
Почему сложные языки популярны? Популярность этих средств книжна: чем толще книжка, тем язык круче - обычная мораль, обычного самца homo sapiens. Раз он смог освоить очень сложное средство, то он крут. Раз он смог освоить корявое средство, вроде C++, то он крут. Так уж получилось, что люди с деньгами оценвают не эффективность, а именно крутость того, кого нанимают, ибо в эффективности они понять ничего не могут, в силу иной профессиональной ориентации. А крутость, ещё раз, в программировании это означает умение программировать на сложных средствах. Нет, конечно, гораздо круче разбираться во всех алгоритмах, упомянутых Кнутом и Корнелом, но для этого уже нужно напрягать мозг и тратить время, и проверить эту крутость сложнее, потому что тогда наниматель должен в этом всём разбираться сам, а там терминов и абстракций гораздо больше, чем в семантике языка программирования, а связи между ними гораздо богаче, чем отношение isA.
Плюс людям с деньгами на семинарах промывают мозги, рассказывая сказки о том, насколько Java может быть эффективной, и насколько хорошо она может управлять нитями, и насколько хорошо памятью. Но начинаешь разбираться и: конечно, может, иногда, в некоторых случаях, специальных, которые часто встречаются в том коде, скорость работы которого не критична. Вы не забывайте, что насколько бы продвинутой была VM она обязана защитить runtime от действий программиста, а это горы лишних проверок при хоть сколько-нибудь нетривиальном обращении к массивам, или отсутсвие нормальных массивов в языке совсем. Но менеджер этого не знает, а обёртка у Java очень красивая.
Про C++ то же самое: смотрите какие чудные иерархии мы можем строить, а потом использовать совершенно безумные хаки, чтобы это всё нормально работало, cooool, давайте заставлять их строить всегда и везде, в любой беде. Давайте напишем про это кучу теоретических книжек, сделаем большие бабки на этом, и дадим кодерам возможность получать больше денег, за меньший объём осмысленной работы. Умные гомоморфные автоматические указатели со сборкой мусора рулятЪ и trueЪ. Это же такая хардкорная математика, и, как алгебраиста интеллектуально она меня очень привлекает, например. Всегда очень хочется прочитать новое издание advanced c++ programming. Но это всё красивые теории, а не практика.
Это всё к удобству и эффективности отношения не имеет. Просто, подкреплённое ленью менеджеров и ценой на компиляторы (компилятор C++ или C# НАМНОГО сложнее, чем компилятор C, естественно, их сложно воспроизвести, следовательно, на этом можно делать деньги), общественное мнение и работа на собственную крутость.
Между тем, на C в комбинации с продвинутой shell можно спокойно писать сложные web-приложения. И даже гораздо более сложные, чем на всех этих высокоуровневых С#, Java, C++, Python, которые загоняют программистов в древовидные структуры классов и библиотек. Потому что дают свободу. Посмотрите на все web службы для Plan9 - там только C и rc. Сложный ли там код? Гораздо проще, чем мне доводилось видеть в аналогичных службах, писанных на asp.net. Да, на C приходится писать free, освобождая память, но это единственная техническая сложность. Но по сравнению с чисто техническими проблемами при использовании классов - это такие мелочи.
Почему Linux'оиды чаще всего выбирают для программирования C и shell, а не кучу других языков, которые доступны для использования? У меня вот в gentoo установлено сейчас около 400 пакетов, и только около 50 составлены на чём-то отличном от C и shell. Не по историческим причинам совсем при разработке 'софта не из-за денег' используется именно эта комбинация, есть много свеженьких проектов, разработку которых начали в эпоху всего этого высокоуровневого разгула. Именно потому, что это достаточно компактные языки. Можно быстро выучить и запомнить все странности и глюки, можно получить свободу в оперировании данными. А это как раз то, что нужно, чтобы за короткое время стартануть, а потом эволюционно развивать проект.
Поэтому, возможно, самого C не станет со временем, но подобный ему язык со всеми прелестями (действительно прелестями, а не недостатками, как это считают теоретики), вроде указателей и плоского пространства имён, обязательно будет существовать. И будет массовым. Потому что простенько, эффективно и пригодно не только для того, чтобы писать ядра систем или виртуальные машины для языков программирования.
HT как раз успевает всё прокачивать, что доказывает тест на 2 модулях системы. Затыки возникают внутри процессора при обращении к общему контроллеру. И не понятно, как этого затыка избежать, ведь, ресурс один, что автоматически приводит к необходимости упорядочивать запросы и выполнять их последовательно. Когда amd сделает два контроллера памяти, то в процессоре будет 4 ядра, и они будут работать чепез общий L3, хотя и побитый на банки, ну, если верить картинкам, что приведёт к драке за этот кэш, потому что логика разруливания по банкам, всё равно, потребует упорядочивания запросов. Опять коллизии и ничего хорошего. Хых.
Но они погоняют свои мелкие тесты, вроде фотошопов, кодеков и архиваторов, и опять объявят процессоры самыми лучшими и высокопроизводительными на рынке PC. Ну ладно, они будут правы, Intel они опять сделают, скорее всего. НО, можно же более производительную архитектуру предложить, как показывают все эти эксперименты. И более дешёвую и энергоэффективную, как доказывает IBM своим BlueGene.
Хм. Неужели единственное, что сдерживает - страх перед тем, что программисты не освоят программирование для логически неоднородной системы? Хотя, тут давление, наверное, ещё со стороны компиляторщиков, которым надо продавать продукты с этикеткой OpenMP compatible. Да и Windows исторически многонитевая и мозги ей уже ничем не вправишь, кроме лома. Мдя, опять система ползёт в глючный аттрактор, как это произошло с x86.
Так можно, конечно. Удручает отношение большинства к вопросам. Даже к тем, которые не требуют особых ресурсов и времени. Я за выходные смогу написать выкладывалку архивов с исходниками, чтобы они подсвечивались и перекрёстно ссылались: vim и ctags рулят. Но даже на такую мелкую деятельность очень многих сложно подопнуть.
Ну, хорошо, у всех свои интересы и так далее. Я понимаю это. Но я не понимаю, от куда негативное отношение к велосипедостроению : ) То есть, люди делают попытки доказать, что отношение велосепедиста к жизни не правильное.
Вот вчера был свидетелем, как солидный специалист в одной закрытой общалке, двум студентам промывал мозг на тему того, что ну не правы они, раз хотят свой движок для игр писать, нужно обязательно изучить движок Unreal и не шалить самостоятельно. Хм... Вот так вот. Нужно быть очень энергичными, чтобы не пасть духом и не разбиться о стену существующего.
Inferno и Plan9 далеко ушли в другом: в эффективной и в простой для использования распределённости и в очень простом для программиста и пользователя API. Это действительно уникально и даёт много интересных возможностей.
Совсем не важно, на каком языке система написана, важно, что она позволяет делать.
Оба подхода заставляют по форме (что должно быть) определить содержание (как должно быть). Вобщем-то вполне себе математичный подход. Теоретически красивый. Да, мы вот сейчас всё пишем и пишем, и на словах, действительно ООП гораздо красивее обычного структурного подхода. Кроме того, можно кучу книжек писать, ООП - богатая среда для мудрствований, например, вот те же замечательные философствования о шаблонах и рефакторинге. Так же как и функциональное программирование, а когда оно ещё и с монадами, то вообще, ууУУух как поумничать можно и статьи пописать.
C же освобождает от необходимости проектировать строго определённый интерфейс, конечно, от ответа на вопрос: что код должен делать? уйти вряд ли удасться, но ответ этот может быть достаточно нестрогим. Язык ориентирован на работу с данными, а не объектами. Если я совершу ошибку на этапе придумывания интерфейса, то мне никто не мешает напрямую залезть в структуру данных, и написать новый код для работы с ней, в том месте, где он нужен. Да, это грязно, это не математично, это нарушение кучи принципов, об этом не напишешь умную книжку, потому что это глупо, но это работет. И работает не только корректно, но и эффективно. Если подобный код мне нужен будет во многих местах - родилась абстракция - я его вынесу в соответсвующий модуль, и доступ к нему сделаю частью интерфейса.
Мог бы я подобное обнаружить на бумажке? Запросто, если бы писал на бумажке настоящую программу, до уровня операторов и вызов функций, а не просто рисовал бы стрелочки, то наверняка обнаружил бы то же самое. Но на бумажке невозможно написать нечто более или менее сложное.
Я могу предполагать, что в этом случае списки эффективны, но на реальных данных может оказаться, что они убивают производительность, или, вдруг оказывается, что для реализации некоторой возможности в новой версии нужно обращение к произвольному элементу. Если я это всё буду учитывать только после того, как напишу программу на бумажке, потом закодирую на ООП, потом откомпилирую, потом пойму, что все мои расчёты, мягко говоря, некорректные, потом опять сяду за бумажку... Я рискую ни одной эффективной программы за всю жизнь не написать.
В итоге, конечно, у меня тоже появляются объекты в программе, но границы у них не жёсткие, а размытые, и объекты именно появляются, а не спускаются сверху. Не тотальная закапсулированность позволяет упростить взаимодействие, особенно, при использовании в новом коде. А то, что объект возник естественным путём освобождает меня от необходимости прописывать какую-то невостребованную функциональность.
Да, всё то же самое можно делать и на C++, например. Но тогда надо будет делать все данные и методы изначально открытыми, и возникает вопрос, а зачем тогда этот весь этот лишний классовый синтаксис?
Ещё можно сказать, что в Smalltalk именно так формировались интерфейсы. Они формировались снизу вверх. Они возникали, а не навязывались сверху. Наследования же вообще не было. Все эти, на мой взгляд, сложности, связанные с проектирование сверху вниз, появились в компилируемых языках, в которых для повышения эффективности стали путать типы и объекты.
И последнее замечание: в книжках по функциональному программированию, обычно, всё истолковывается в терминах и примерах из императивных языков программирования, поэтому, в них со сравнением с другими технологиями всё лучше.
И я должен буду выполнять много сложной работы по переписыванию кода, настолько сложной, что для этого появляются автоматизированные средства.
Но для новых проектов всё это ООП - зло. Оно заставляет поиск решения производить задом наперёд: придумали абстракцию начали делать, а потом, хопа, поняли, что всё это работать не будет, и начинается изменение всей иерархии. Это же сложно и время отнимает, поэтому люди начинают нарушать парадигму на право и налево. Но возникает вопрос: а зачем тогда вообще они начали писать свои классы?
Насчёт free. Частое использование malloc/free - это рузультат неправильного проектирования, по моему мнению. И является болезнью больших проектов, в которых писают всё написать на C. Но C придумывался не для этого. Компоненты, написанные на C должны быть маленькими и максимально специализированными под решаемую задачу. Большая же решается через объединение компонентов через IPC. Это удобнее, чем придумывание иерархий, потому что позволяет вклиниваться и менять взаимодействие между компонентами как угодно.
Попробуйте воткнуть дополнительную обработку в pipe, или дополнительную обработку во взаимодействие между двумя объектами, когда один вызывает другой. Как минимум, придётся нечто наследовать, заново думать над тем, что должно быть виртуальным или не виртуальным. И так далее. Много работы. Может быть, именно поэтому, все сложные ОО системы рано или поздно приходят к тому, чтобы создать свою транспортную систему данных между объектами. Или воспользоваться существующей в виде базы данных или чего-нибудь, вроде, CORBA. Но это всё усложнения, усложнения и ещё раз усложнения. Которые надо осваивать, особенно при коммерческом программировании, а это всё уводит сознание от размышлений над другими методами организации вычислений. Существенно более гибкими и простыми. Ну вот сравнить хотя бы ту же CORBA с plumber'ом из Plan9 или Linda.
Поэтому я против ООП. Мне не нравится, когда навязываются сложности и неэффективности, да ещё такими ненаучными способами: вы хотя бы в одной книге по ООП видели сравнение предлагаемых способов решения тех или иных иных задач в этой парадигме с решением их в других?
Удручает только то, что вместо, например, огромной библии программирования на с++ или толстенной camelbook он бы мог прочесть тоненькую книжку о 'c', и толстую книжку об алгоритмах и структурах данных, да пару руководств по shell с описанием всяких утилит, вроде sed, что позволило бы ему писать более эффективно и быстро, да к тому же использовать все возможности существующего кода.
Почему сложные языки популярны? Популярность этих средств книжна: чем толще книжка, тем язык круче - обычная мораль, обычного самца homo sapiens. Раз он смог освоить очень сложное средство, то он крут. Раз он смог освоить корявое средство, вроде C++, то он крут. Так уж получилось, что люди с деньгами оценвают не эффективность, а именно крутость того, кого нанимают, ибо в эффективности они понять ничего не могут, в силу иной профессиональной ориентации. А крутость, ещё раз, в программировании это означает умение программировать на сложных средствах. Нет, конечно, гораздо круче разбираться во всех алгоритмах, упомянутых Кнутом и Корнелом, но для этого уже нужно напрягать мозг и тратить время, и проверить эту крутость сложнее, потому что тогда наниматель должен в этом всём разбираться сам, а там терминов и абстракций гораздо больше, чем в семантике языка программирования, а связи между ними гораздо богаче, чем отношение isA.
Плюс людям с деньгами на семинарах промывают мозги, рассказывая сказки о том, насколько Java может быть эффективной, и насколько хорошо она может управлять нитями, и насколько хорошо памятью. Но начинаешь разбираться и: конечно, может, иногда, в некоторых случаях, специальных, которые часто встречаются в том коде, скорость работы которого не критична. Вы не забывайте, что насколько бы продвинутой была VM она обязана защитить runtime от действий программиста, а это горы лишних проверок при хоть сколько-нибудь нетривиальном обращении к массивам, или отсутсвие нормальных массивов в языке совсем. Но менеджер этого не знает, а обёртка у Java очень красивая.
Про C++ то же самое: смотрите какие чудные иерархии мы можем строить, а потом использовать совершенно безумные хаки, чтобы это всё нормально работало, cooool, давайте заставлять их строить всегда и везде, в любой беде. Давайте напишем про это кучу теоретических книжек, сделаем большие бабки на этом, и дадим кодерам возможность получать больше денег, за меньший объём осмысленной работы. Умные гомоморфные автоматические указатели со сборкой мусора рулятЪ и trueЪ. Это же такая хардкорная математика, и, как алгебраиста интеллектуально она меня очень привлекает, например. Всегда очень хочется прочитать новое издание advanced c++ programming. Но это всё красивые теории, а не практика.
Это всё к удобству и эффективности отношения не имеет. Просто, подкреплённое ленью менеджеров и ценой на компиляторы (компилятор C++ или C# НАМНОГО сложнее, чем компилятор C, естественно, их сложно воспроизвести, следовательно, на этом можно делать деньги), общественное мнение и работа на собственную крутость.
Между тем, на C в комбинации с продвинутой shell можно спокойно писать сложные web-приложения. И даже гораздо более сложные, чем на всех этих высокоуровневых С#, Java, C++, Python, которые загоняют программистов в древовидные структуры классов и библиотек. Потому что дают свободу. Посмотрите на все web службы для Plan9 - там только C и rc. Сложный ли там код? Гораздо проще, чем мне доводилось видеть в аналогичных службах, писанных на asp.net. Да, на C приходится писать free, освобождая память, но это единственная техническая сложность. Но по сравнению с чисто техническими проблемами при использовании классов - это такие мелочи.
Почему Linux'оиды чаще всего выбирают для программирования C и shell, а не кучу других языков, которые доступны для использования? У меня вот в gentoo установлено сейчас около 400 пакетов, и только около 50 составлены на чём-то отличном от C и shell. Не по историческим причинам совсем при разработке 'софта не из-за денег' используется именно эта комбинация, есть много свеженьких проектов, разработку которых начали в эпоху всего этого высокоуровневого разгула. Именно потому, что это достаточно компактные языки. Можно быстро выучить и запомнить все странности и глюки, можно получить свободу в оперировании данными. А это как раз то, что нужно, чтобы за короткое время стартануть, а потом эволюционно развивать проект.
Поэтому, возможно, самого C не станет со временем, но подобный ему язык со всеми прелестями (действительно прелестями, а не недостатками, как это считают теоретики), вроде указателей и плоского пространства имён, обязательно будет существовать. И будет массовым. Потому что простенько, эффективно и пригодно не только для того, чтобы писать ядра систем или виртуальные машины для языков программирования.
Но они погоняют свои мелкие тесты, вроде фотошопов, кодеков и архиваторов, и опять объявят процессоры самыми лучшими и высокопроизводительными на рынке PC. Ну ладно, они будут правы, Intel они опять сделают, скорее всего. НО, можно же более производительную архитектуру предложить, как показывают все эти эксперименты. И более дешёвую и энергоэффективную, как доказывает IBM своим BlueGene.
Хм. Неужели единственное, что сдерживает - страх перед тем, что программисты не освоят программирование для логически неоднородной системы? Хотя, тут давление, наверное, ещё со стороны компиляторщиков, которым надо продавать продукты с этикеткой OpenMP compatible. Да и Windows исторически многонитевая и мозги ей уже ничем не вправишь, кроме лома. Мдя, опять система ползёт в глючный аттрактор, как это произошло с x86.
Ну, хорошо, у всех свои интересы и так далее. Я понимаю это. Но я не понимаю, от куда негативное отношение к велосипедостроению : ) То есть, люди делают попытки доказать, что отношение велосепедиста к жизни не правильное.
Вот вчера был свидетелем, как солидный специалист в одной закрытой общалке, двум студентам промывал мозг на тему того, что ну не правы они, раз хотят свой движок для игр писать, нужно обязательно изучить движок Unreal и не шалить самостоятельно. Хм... Вот так вот. Нужно быть очень энергичными, чтобы не пасть духом и не разбиться о стену существующего.