Для того, чтобы быть scalable, в языке
— сборка мусора
— никаких указателей и арифметики указателей(pointer arithmetic)
— интерфейс (FFI) к языку C
— статическая проверка типов с выводом типов(type inference)
— поддержка исключений
— проверка в run-time ошибок, которые нельзя выловить на тапе компиляции — такие как выход за пределы массива или деление на ноль
— поддержка assertions и design by contract
— мощнай, ститчески проверяемая модульная система (a powerful, statically checked module system)
— поддержка ООП
— поддержка функционального програмирования
— структурные макросы (structural macros)
— поддержка компонентности
— простой, consistent и читаемый синтаксис
Правы ли были пещерные люди в далеком 2001-м году?
Здравствуйте, Mamut, Вы писали:
M>Статья аж 2001-го года
M>http://www.cs.caltech.edu/~mvanier/hacking/rants/scalable_computer_programming_languages.html
M>Общая идея:
M>Для того, чтобы быть scalable, в языке M>- сборка мусора M>- никаких указателей и арифметики указателей(pointer arithmetic) M>- интерфейс (FFI) к языку C M>- статическая проверка типов с выводом типов(type inference) M>- поддержка исключений M>- проверка в run-time ошибок, которые нельзя выловить на тапе компиляции — такие как выход за пределы массива или деление на ноль M>- поддержка assertions и design by contract M>- мощнай, ститчески проверяемая модульная система (a powerful, statically checked module system) M>- поддержка ООП M>- поддержка функционального програмирования M>- структурные макросы (structural macros) M>- поддержка компонентности M>- простой, consistent и читаемый синтаксис
M>Правы ли были пещерные люди в далеком 2001-м году?
Любят люди PL/I переизобретать...
Имхо для того, чтобы приложение было scalable, у его автора должен быть мозг в черепе, остальное — подпорки для случаев, когда это условие не выполняется
А scalable язык — он как неуловимый Джо, правда, в отличие от Джо, его вечно кто-то ищет.
Здравствуйте, Курилка, Вы писали:
К>Имхо для того, чтобы приложение было scalable, у его автора должен быть мозг в черепе, остальное — подпорки для случаев, когда это условие не выполняется
Грубовато как-то... И у умных людей встречаются ошибки проектирования, и неплохо, если язык помогает их избегать.
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, Курилка, Вы писали:
К>>Имхо для того, чтобы приложение было scalable, у его автора должен быть мозг в черепе, остальное — подпорки для случаев, когда это условие не выполняется
N>Грубовато как-то... И у умных людей встречаются ошибки проектирования, и неплохо, если язык помогает их избегать.
Ну извини, так получилось (несколько уже подустал от таких "ошибок проектирования").
Помогать — оно, конечно, хорошо, только вот это в итоге зачастую приучивает полагаться на "всесильный" компилятор.
На мой взгляд для таких вещей гораздо полезнее code review и чем больше участников, тем лучше (пример: кнутовский ТеХ ).
Т.е. если ты сам (с товарищами по комманде), не понимаешь, что происходит в твоём коде, то врядли даже самый умный компилятор сможет найти логические ошибки (хотя мелочи типа описок и т.п. — это, конечно, да).
Simply put, a scalable computer language is a language that one can write very large programs in (and extend very large programs that have already been written) without feeling an undue amount of pain. In a scalable programming language, the difficulty of managing the complexity of the program goes up roughly linearly with the size of the program. Conversely, a nonscalable computer language is one in which increasing the size and scope of a problem tends to make the program much harder to manage (i.e. the complexity of the program goes up much more than linearly with its size).
Вот это основное положение, от которого автор и плясал дальше.
Так вот, это положение неверно, с моей точки зрения.
Не может сложность программы рости линейно с ростом размера кода.
Сложность определяется количеством взаимосвязей в программе. Это количество всегда растёт факториально.
Существуют специальные методики, парадигмы и технологии программирования, которые с этим пытаются бороться.
Главное направление борьбы — инкапсуляция.
Кусок кода инкапсулировали в функцию/метод. Сложность перестала расти с увеличением размера кода, теперь
она растёт с увеличением кол-ва методов, а внутри метода с увеличенимем кол-ва кода. Делать очень большие методы
не всегда получается, да и не нужно — их становится тяжело отлаживать и вообще писать правильно.
Итак, мы научились писать бОльшие программы, но факториальный рост кол-ва взаимосвязей с кол-вом методов
быстро съел нашу инкапсуляцию.
Следующий шаг — придумали модули, в которые запаковывают методы, и наружу торчит интерфейс из много меньшего
кол-ва методов. Теперь наша сложность растёт факториально с ростом кол-ва модулей.
Усовершеннствовали модульный подход, при помощи ООП. Теперь сложность растёт факториально с ростом кол-ва
классов. Классы тоже стали делать приватными и т.п. Но всё равно, сколько их не прячь — рост-то факториальный.
Будет следующая технология, либо построенная на инкапсуляции, а скорее на более компактном и близком к решаемой
задаче модели программирования, то есть на DSL (впрочем, и это не суть важно).
Факт тот, что следующая технология тоже поможет увеличить размеры программ до определённого предела.
Скажем, рост сложности будет факториально зависить от кол-ва используемых технологий и DSL языков.
Это много меньше зависимостей, чем сложность определяемая кол-вом классов.
Но когда мы дойдём до десятков языков (к примеру, можно и "технологий" — вроде тех-же GC, type infering
и пр.) — то дальнеший рост опять остановится сложностью этих взяимосвязей.
Эрго — scalability всегда будет в определённых границах.
Второе — реальная scalability предполагает не только возможность написания больших программ, но и лёгкость
написания небольших программ. И эффективную работу небольших программ. Ну и толку, что java applet может
делать всё то-же, что и flash или java script — используют-то не applet-ы. Уж больно дорого стоит старт
всей виртуальной машины, занимающей десятки мег памяти, и всё только для исполнения небольшого кода.
Здравствуйте, mkizub, Вы писали:
M>Усовершеннствовали модульный подход, при помощи ООП. Теперь сложность растёт факториально с ростом кол-ва M>классов. Классы тоже стали делать приватными и т.п. Но всё равно, сколько их не прячь — рост-то факториальный.
(выделил про классы. но относится ко всему)
Почему факториально?
Все зависит от выбранной архитектуры. Можно так спланировать, что все классы в программе увязаны друг на друга по методу каждый с каждым и тогда рост действительно факториальный. Только какой смысл тогда разделять их на классы? ООП — это не там, где применяются ключевые слова "class" и "private" — это там, где объекты реализуют свою функциональность в минимальной зависимости от внешнего мира.
Часто, подумав, можно сделать такие классы, что связей между ними значительно меньше чем их число, и добавление нового класса в затрагивает , быть может, только 1-2 других класса, и то — управляющих.
Здравствуйте, fmiracle, Вы писали:
F>Почему факториально?
И в самом деле, почему?
F>Все зависит от выбранной архитектуры. Можно так спланировать, что все классы в программе увязаны друг на друга по методу каждый с каждым и тогда рост действительно факториальный.
Если N сущностей связаны каждая с каждой, то это всего лишь N(N-1)/2 связей.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, fmiracle, Вы писали:
F>>Все зависит от выбранной архитектуры. Можно так спланировать, что все классы в программе увязаны друг на друга по методу каждый с каждым и тогда рост действительно факториальный.
RO>Если N сущностей связаны каждая с каждой, то это всего лишь N(N-1)/2 связей.
Могу сделать лишь предположение, что берётся очень грустный случай, когда связность сказывается и "дальше" конкретной связи, т.е., например, используются конструкции a->getB()->getC()->doFoo()
Здравствуйте, Курилка, Вы писали:
RO>>Если N сущностей связаны каждая с каждой, то это всего лишь N(N-1)/2 связей.
К>Могу сделать лишь предположение, что берётся очень грустный случай, когда связность сказывается и "дальше" конкретной связи, т.е., например, используются конструкции a->getB()->getC()->doFoo()
Не, правильней было-бы предположить, что я ошибся Действительно, не факториальная, а квадратичная. А то я писал, и сам ужасался
Но смысла поста это не отменят — всё равно кол-во взаимосвязей растёт очень быстро.
Здравствуйте, Курилка, Вы писали:
К>Могу сделать лишь предположение, что берётся очень грустный случай, когда связность сказывается и "дальше" конкретной связи, т.е., например, используются конструкции a->getB()->getC()->doFoo()
Такие конструкции плохи вовсе не из-за связности. Если они используют публичный интерфейс и не опираются на детали реализации, то связность они не повышают.
Здравствуйте, fmiracle, Вы писали:
M>>Усовершеннствовали модульный подход, при помощи ООП. Теперь сложность растёт факториально с ростом кол-ва M>>классов. Классы тоже стали делать приватными и т.п. Но всё равно, сколько их не прячь — рост-то факториальный.
F>(выделил про классы. но относится ко всему) F>Почему факториально? F>Все зависит от выбранной архитектуры. Можно так спланировать, что все классы в программе увязаны друг на друга по методу каждый с каждым и тогда рост действительно факториальный. Только какой смысл тогда разделять их на классы? ООП — это не там, где применяются ключевые слова "class" и "private" — это там, где объекты реализуют свою функциональность в минимальной зависимости от внешнего мира.
Дело не в ООП. И методы можно писать так, что они минимально вызывают другие методы, и модули можно писать так, что
они минимально используют другие. Дело в том, что любой элемент программы может потенциально использовать любой другой элемент
программы. С этим инкапсуляция и борется. Способов инкапсуляции, или точнее, уменьшения кол-ва сущностей, придумали очень много,
и не только private, но и inheritance в ООП, и функции с параметризуемыми аргументами в FP, и muti-tier архитектуру и т.п.
F>Часто, подумав, можно сделать такие классы, что связей между ними значительно меньше чем их число, и добавление нового класса в затрагивает , быть может, только 1-2 других класса, и то — управляющих.
Это и есть много-уровневый подход. Аналогичный разбиению сетевого стека на несколько уровней. Это сильно помогает, но опять-же
имеет свой лимит. Из нашей любимой кибернетики известно, что для полностью эффективного управления, управляющая система должна
иметь полную модель управляемой, а следовательно, она как минимум должна быть так-же сложна, а на практике она должна
быть ещё сложнее, так как ей этой моделью ещё надо воспользоваться, вычислять наиболее эффективный ответ на внешнее
или внутреннее событие. А если управляющая система более сложна, чем управляемая — то кто же будет управлять этой
управляющей системой, ещё более сложная? Так мы уйдём в бесконечность.
Поэтому на практике управляющая система вынуждена быть более простой, чем управляемая, а значит — она не может
достичь полной эффективности управляемой системы. Эмпирически оптимум лежит где-то в районе 30% (т.е. сложность
управляющей системы составляет около 30% от сложности управляемой). Если управляющая система всё равно слишком
сложна — над ней настраивается ещё одна управляющая система. Получается иерархия управленцев. И на каждом
уровне иерархии теряется эффективность. Зато, мы хотя-бы сохраняем управляемость всей системы в целом.
Собственно, в программах у нас эта иерархия и присутствует — видимые только интерфейсы, видимые внутри модулей классы,
видимые внутри классов методы, видимые внутри методов переменные/операции и т.п. А сверху, когда этого не хватает,
накладывают ещё специфичные архитектуры/шаблоны проектирования — например MVC для UI.
А цена — чудовищная неэффективность использования ресурсов.
Пока мощность компов растёт экспоненциально, спасибо закону Мура, это не очено замечаем.
При выходе новой версии Windows, каждый раз отжирающей чудовищные ресурсы — все тяжко сетуем на идиотов из M$,
а через несколько лет гляди — а оно шустренько бегает на новом железе!
Вот когда он закончится... А это уже скоро, частота уже не растёт экспоненциально, а гонку роста кол-ва транзисторов выдерживает
только Intel (за счёт огромных денежных и интеллектуальных ресурсов), все остальные уже отстают от экспоненциального роста
по кол-ву транзисторов. А лет через 5 лет Intel на это забъёт — денег не хватит. Сделают 22нм процесс, и практически всё.
А скорее всего, и 22нм процесс уже отстанет от графика "каждые два года — увеличить вдвое".
Вот тут и этому подходу уменьшения кол-ва взаимосвязей (т.е. многоуровневой архитектуры) прийдёт конец.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, Курилка, Вы писали:
К>>Могу сделать лишь предположение, что берётся очень грустный случай, когда связность сказывается и "дальше" конкретной связи, т.е., например, используются конструкции a->getB()->getC()->doFoo()
RO>Такие конструкции плохи вовсе не из-за связности. Если они используют публичный интерфейс и не опираются на детали реализации, то связность они не повышают. А что они повышают тогда?
Публичный интерфейс, конечно, чуть улучшит ситуацию, но суть проблемы останется той же самой...
RO>Они нарушают принцип Деметры, вот почему они зло.
Да хоть горшком назови, но они расширяют контракт налагаемый на a за счёт контракта, налагаемого на результат getB() (и далее getC())
Ну и плюс цитата (хоть это и слабый аргумент) из вики:
Since objects are less dependent on the internal structure of other objects, object containers can be changed without reworking their callers.
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, Курилка, Вы писали:
К>>Имхо для того, чтобы приложение было scalable, у его автора должен быть мозг в черепе, остальное — подпорки для случаев, когда это условие не выполняется
N>Грубовато как-то... И у умных людей встречаются ошибки проектирования, и неплохо, если язык помогает их избегать.
А разьве что-то из указанного может предотвратить ошибки проектирования?
Здравствуйте, mkizub, Вы писали:
M>Это и есть много-уровневый подход. Аналогичный разбиению сетевого стека на несколько уровней. Это сильно помогает, но опять-же M>имеет свой лимит. Из нашей любимой кибернетики известно, что для полностью эффективного управления, управляющая система должна M>иметь полную модель управляемой, а следовательно, она как минимум должна быть так-же сложна, а на практике она должна M>быть ещё сложнее, так как ей этой моделью ещё надо воспользоваться, вычислять наиболее эффективный ответ на внешнее M>или внутреннее событие. А если управляющая система более сложна, чем управляемая — то кто же будет управлять этой M>управляющей системой, ещё более сложная? Так мы уйдём в бесконечность.
Никуда мы так не уйдем.
Вы спокойно управляете процессором(сверхсложной системой, как она работает — вы не поймете досконально) через ограниченный набор ног и ограниченный набор машинных команд. Это инкапсуляция в чистом виде. вы не знаете за какие ноги его правильно дергать, и вы не знаете например ассемблера. Вам дают языки высокого уровня и полностью избавляют вас от знания о ногах процессора. И только таким образом вы в состоянии вообще написать какую-то программу.
вы никогда не смогли бы написать хоть какую-то программу для управления этими сотнями миллионов вентилей, чтобы программа на них сделала хоть один шаг. и запросто напишете на консоль hello world. с помощью той самой иерархии управления.
у вас подход грубо математический. по вашему сложность уже проца является ужасающей, это если при рассмотрении сложности, например, учитывать движение каждого электрона в канале транзистора. но на самом деле это никого не волнует. поскольку данная сложность не является существенной для управления.
аналогично автомобилем можно управлять несколькими педалями и рулем в количестве одна штука. Несмотря на то что сложность его как механической системы ужасающе велика.
А еще более ужасающей сложностью потоков автомобилей в городе с сидящими там разумными существами, можно управлять одной полосатой палкой, и ящичками с тремя огоньками.
а страной можно управлять сидя на стуле.
но по вашему — такими системами уже невозможно управлять...покольку транзисторов реально не хватит
M>А цена — чудовищная неэффективность использования ресурсов.
Ну предложите чудовищно эффективный способ управления полком солдат. Или каждым электроном в проце.
M>Вот тут и этому подходу уменьшения кол-ва взаимосвязей (т.е. многоуровневой архитектуры) прийдёт конец.
ерунда. никто не собирается командовать броуновским движением. на каждом уровне иерархии, есть свои инварианты, сложность одних компенсируется сложностью других, образуются интегральные понятия, что выходят на новый уровень управления, и неисчислимый хаос молекул в стакане превращается в температуру, которую меряют градусником.
Здравствуйте, merk, Вы писали:
M>>А цена — чудовищная неэффективность использования ресурсов. M>Ну предложите чудовищно эффективный способ управления полком солдат. Или каждым электроном в проце.
В качестве претендента на управление полком я бы назвал Auftragstaktik
Мне кажется, проблема не в языках, а в архитектуре.
Если программа организована так, что многие ее компоненты общаются со многими, то количество таких связей, а, значит, и сложность поддержания программы на плаву, будут расти как минимум как квадрат количества кода.
Если же в программе есть четкая иерархия, концептуальная сложность программы будет расти линейно с увеличением количества кода в программе.
Язык всего лишь инструмент, и слишком многое зависит от того, кто и как этим инструментом пользуется. Мне трудно придумать на вскидку язык программирования, кроме уж совсем идиотских, которые не позволяют писать на себе сколь угодно сложных программ при правильном подходе.
Правда при этом надо сказать, что вокруг каждого популярного языка есть определенная культура его использования, которая формируется community этого языка. И вот эти культуры разные, даже для весьма похожих языков (пример — Java vs C++). И я вполне могу себе представить ситуацию, когда неудачная, нерасширяемая архитектура возникает именно благодаря следованию общепринятым подходам, а не из-за языка как такогого.
Действительно, не факториальная, а квадратичная. А то я писал, и сам ужасался 
