Я подозреваю, что сложность выполнения алгоритмов — вещь довольно теоретическая. Практически, мы имеем дело с конкретными реализациями, и реальная быстрота выполнения алгоритма может весьма варьироваться. Обычно, в таких случаях, ориентируются на систему статистических испытаний. Не говоря, уж, о том, что, в зависимости от типов данных и от размеров данных будут существенно меняться и скорость выполнения операций, а это значит, что говорить о самом быстром алгоритме не приходиться. Все эти теоретические оценки асимптотические. Вот почему, реальное программирование — это искусство выбора оптимального решения в данных обстоятельствах. А, поскольку, каждый запуск приложения происходит в уникальных обстоятельствах, то и от приложения следует ожидать возможности выбирать различные пути реализации одной и той же операции. Вот я о чём.
— это шаблон или это встроенный тип? Дело в том, что от языка программирования ожидаешь, что в нём самом реализованы основные вычислительные концепции. Кажется, что так должно быть. Или, например, сортировка.Сортировка, как таковая, единственна, но есть множество алгоритмов сортировки. Что с этим делать? В STL мы, просто, вызваем нужный нам алгоритм и всё, так? А если мы хотим иметь пул методов и выбирать по ситуации, какой лучше? По моему, это — увод мною разговора в другую сторону, но я ещё подумаю, что именно меня интересует.
P.S. Ещё вспоминаю Borland C++ 5.0, где, вроде бы, были всякие контейнеры, но без шаблонов. Чем так страшно предоставление информации о типах в рантайме? И что будет, если попробовать разобраться в различных способах построения контейнерных типов? Вряд ли такой способ единственен…
Скорее всего, подспудно, Вам пытаются донести мысль, что нужно во всём проявлять профессионализм. Если Вы опускаете планку где-то «для себя», то, скорее всего, будете опускать её и «для других». Сие уже настораживает. Как минимум.
А у меня к Вам немного перпендикулярный вопрос: обязаны ли мы пользоваться шаблонами?
Да, шаблоны предоставляют возможность записать решение задачи в общем виде. Но является ли этот подход единственным для реализации стандартной библиотеки? И, конечно, очень важно понять, что должно быть частью языка, а что должно, действительно, быть реализовано в виде библиотеки. Шаблоны занимают здесь некое промежуточное положение: «ни нашим, ни вашим». Между тем, хотелось бы иметь явную поддержку со стороны языка, чтобы семантика выражений всегда гарантировала определённый результат, а программист мог бы выбирать как модель памяти, так и набор используемых им алгоритмов.
Читая подобное, хочется (в сердцах) воскликнуть: не пишите сложный код! не пишите лишний код! не пишите дублирующий код (для одного и того же)! не используйте (вставить ненадёжный ЯП и/или ИСР)! Не (по)рождайте уязвимости!
Как можно выпускать продукцию, над которой пользователь не имеет полного контроля? Если бы в этой области была настоящая конкуренция, то у пользователей был бы выбор: либо покупать традиционные продукты «как есть» по бросовым ценам, либо приобретать за хорошую деньгу систему, предоставляющую пользователю полный контроль. Это касается и оборудования, и программного обеспечения.
Например, если бы БИОС с самого начала была полноценной базовой системой ввода вывода, то мы все давно имели бы стандартный загрузчик с выбором операционной системы, причём, БИОС сама распределяла бы дисковую память между операционными системами, а те не знали бы ничего про основную загрузочную запись и, соответственно, никто и никогда изнутри никакой операционной системы не мог бы подменить MBR. Вот, зачем, операционной системе физический доступ к диску? Незачем!… Сколько вирусов было бы невозможно написать, если бы все разработчики всегда чётко разделяли уровни реализации и функционирования, а в производство шли бы только те продукты, которые это разграничение чётко выдерживали бы!
Или… кому-то было бы очень скучно жить в таком упорядоченном и прозрачном мире? ;-)
А что делать мне, которому кажется, что свойства немного недооценены, и на их основе можно было бы развить совершенно другие подходы к организации кода? (Боюсь, придётся заняться сведением всех разрозненных представлений по этой теме в целую статью. Рискнуть написать?)
Всё сказанное выше убеждает меня в том, что язык C++ надо было уже давно «зафиксировать» в виде некоторого разумного стандарта и добиться строгой реализации этого стандарта. Если для разумности нужно будет пожертвовать чем-то, что кажется полезным, то лучше этим пожертвовать в пользу концептуальной чистоты языка. А все накопившиеся проблемы следует решать, создавая новый язык программирования.
И тут возникнет важный вопрос: что должно стать органической частью нового языка программирования (на уровне ключевых слов и синтаксических конструкций), а что должно быть реализовано в виде поставляемых библиотек. Беда большинства языков программирования, как раз, в том и заключается, что происходит смешение, когда на одном и том же уровне организации оказывается и код приложения, и код реализации функций и компонентов, используемых в приложении.
Например, на низком уровне находятся такие понятия как типы хранимых данных (символы, числа, строки, массивы, структуры...), на более высоком — домены (описывающие поля хранимых в базах данных объектов, которые, с одной стороны, используют для физического хранения и, возможно, для визуального представления какой-либо тип данных, а, с другой стороны, связаны с некоторой сущностью, принадлежащей концептуальной схеме базы данных), и на самом высоком уровне — уже сами сущности. Было бы крайне любопытно взглянуть на язык программирования, где реализована многоуровневая архитектура управления данными приложения…
Я не говорю ещё о визуальных компонентах и операционной системе.
Если язык программирования способен предложить программисту удобный способ привязки программных структур и визуальных компонентов, позволяющий оптимальным образом разделить, собственно, функции вывода на экран и получения сообщений от пользователя, от той задачи, которую должен в данном приложении решает данный компонент, то есть, будет предложен подлинный компонентный подход (когда код изначально создаётся в виде компонентов и специальный слой осуществляет отображение этих компонентов на представления, использующие уже визуальные компоненты, являющиеся частью операционной системы), то, я думаю, всем станет немного проще.
Numbers TS
Было бы очень хорошо! Всегда пытаешься «сварганить» нечто похожее доморощенными средствами. Но! Всё это потребует существенной «ломки» синтаксиса. Я бы мечтал о том, чтобы была возможность перегружать ",", "(", ")", ":" и многое другое, что позволило бы описывать прямо в коде конструкции произвольной сложности. Или всё это уже реализовано?
И можно ли в C++ делать что-то по типу оператора with? Например, так:
object{
.Open();
.Load();
.Close();
}
Что я ещё пропустил (из предыдущих серий)?
P.S. А ещё свойства (properties)! Есть ли какие-либо планы относительно свойств?
Попытка сделать на C++ нечто, приближённое к Erlang, очень любопытна сама по себе и побуждает подробнее узнать про Erlang. Если есть хороший подход, то почему бы не использовать именно его?! Конечно, крайне интересно было бы узнать, что по поводу всего этого говорит богатая теория и практика разработки систем, основанных на асинхронном взаимодействии. Помнится, когда-то давно была написана книга «Взаимодействующие последовательные процессы» (Хоар Ч., 1989)…
Пока, у меня возник, только, один вопрос: а почему агенты обязаны быть объектами — экземплярами классов C++? Что мешает основную инфраструктуру разрабатывать с применением классов, но сами агенты реализовывать как структуры, которые управляются ядром определённым образом?
И, конечно, это немного SmallTalk-подобная архитектура заставляет задуматься об упорядочивании агентов по типам (по типам сообщений, по задачам, по особенностям данных), и это упорядочивание (типа декомпозиции системы) само по себе способно разрешить проблему перегрузки агентов.
С другой стороны, мне очень нравится идея с удалением агентов. Я представил себе, как бы упросилась жизнь разработчика, если бы каждый объект должен был бы постоянно уничтожаться и воссоздаваться заново. Это обеспечило бы стабильность работы (объект почти всегда в корректном состоянии), надёжность доставки сообщений (необработанные сообщения можно всегда доставить новой версии объекта; а, если, осуществлять скрещивание или расщепление объектов с элементами генной инженерии?), при этом, сами сообщения тоже могут быть объектами-агентами особого сорта (могут приниматься другими объектами, но сами могут обрабатывать сообщения).
P.S. Ещё вспоминаю Borland C++ 5.0, где, вроде бы, были всякие контейнеры, но без шаблонов. Чем так страшно предоставление информации о типах в рантайме? И что будет, если попробовать разобраться в различных способах построения контейнерных типов? Вряд ли такой способ единственен…
Да, шаблоны предоставляют возможность записать решение задачи в общем виде. Но является ли этот подход единственным для реализации стандартной библиотеки? И, конечно, очень важно понять, что должно быть частью языка, а что должно, действительно, быть реализовано в виде библиотеки. Шаблоны занимают здесь некое промежуточное положение: «ни нашим, ни вашим». Между тем, хотелось бы иметь явную поддержку со стороны языка, чтобы семантика выражений всегда гарантировала определённый результат, а программист мог бы выбирать как модель памяти, так и набор используемых им алгоритмов.
Как можно выпускать продукцию, над которой пользователь не имеет полного контроля? Если бы в этой области была настоящая конкуренция, то у пользователей был бы выбор: либо покупать традиционные продукты «как есть» по бросовым ценам, либо приобретать за хорошую деньгу систему, предоставляющую пользователю полный контроль. Это касается и оборудования, и программного обеспечения.
Например, если бы БИОС с самого начала была полноценной базовой системой ввода вывода, то мы все давно имели бы стандартный загрузчик с выбором операционной системы, причём, БИОС сама распределяла бы дисковую память между операционными системами, а те не знали бы ничего про основную загрузочную запись и, соответственно, никто и никогда изнутри никакой операционной системы не мог бы подменить MBR. Вот, зачем, операционной системе физический доступ к диску? Незачем!… Сколько вирусов было бы невозможно написать, если бы все разработчики всегда чётко разделяли уровни реализации и функционирования, а в производство шли бы только те продукты, которые это разграничение чётко выдерживали бы!
Или… кому-то было бы очень скучно жить в таком упорядоченном и прозрачном мире? ;-)
— для выхода из двойного цикла, и
— для выхода только из вложенного цикла?
Я имею в виду конструкцию, которая восходит ещё к Delpi:
С этим элементом языка что-то не так?
И тут возникнет важный вопрос: что должно стать органической частью нового языка программирования (на уровне ключевых слов и синтаксических конструкций), а что должно быть реализовано в виде поставляемых библиотек. Беда большинства языков программирования, как раз, в том и заключается, что происходит смешение, когда на одном и том же уровне организации оказывается и код приложения, и код реализации функций и компонентов, используемых в приложении.
Например, на низком уровне находятся такие понятия как типы хранимых данных (символы, числа, строки, массивы, структуры...), на более высоком — домены (описывающие поля хранимых в базах данных объектов, которые, с одной стороны, используют для физического хранения и, возможно, для визуального представления какой-либо тип данных, а, с другой стороны, связаны с некоторой сущностью, принадлежащей концептуальной схеме базы данных), и на самом высоком уровне — уже сами сущности. Было бы крайне любопытно взглянуть на язык программирования, где реализована многоуровневая архитектура управления данными приложения…
Я не говорю ещё о визуальных компонентах и операционной системе.
Если язык программирования способен предложить программисту удобный способ привязки программных структур и визуальных компонентов, позволяющий оптимальным образом разделить, собственно, функции вывода на экран и получения сообщений от пользователя, от той задачи, которую должен в данном приложении решает данный компонент, то есть, будет предложен подлинный компонентный подход (когда код изначально создаётся в виде компонентов и специальный слой осуществляет отображение этих компонентов на представления, использующие уже визуальные компоненты, являющиеся частью операционной системы), то, я думаю, всем станет немного проще.
Было бы очень хорошо! Всегда пытаешься «сварганить» нечто похожее доморощенными средствами. Но! Всё это потребует существенной «ломки» синтаксиса. Я бы мечтал о том, чтобы была возможность перегружать ",", "(", ")", ":" и многое другое, что позволило бы описывать прямо в коде конструкции произвольной сложности. Или всё это уже реализовано?
И можно ли в C++ делать что-то по типу оператора
with? Например, так:Что я ещё пропустил (из предыдущих серий)?
P.S. А ещё свойства (properties)! Есть ли какие-либо планы относительно свойств?
Пока, у меня возник, только, один вопрос: а почему агенты обязаны быть объектами — экземплярами классов C++? Что мешает основную инфраструктуру разрабатывать с применением классов, но сами агенты реализовывать как структуры, которые управляются ядром определённым образом?
И, конечно, это немного SmallTalk-подобная архитектура заставляет задуматься об упорядочивании агентов по типам (по типам сообщений, по задачам, по особенностям данных), и это упорядочивание (типа декомпозиции системы) само по себе способно разрешить проблему перегрузки агентов.
С другой стороны, мне очень нравится идея с удалением агентов. Я представил себе, как бы упросилась жизнь разработчика, если бы каждый объект должен был бы постоянно уничтожаться и воссоздаваться заново. Это обеспечило бы стабильность работы (объект почти всегда в корректном состоянии), надёжность доставки сообщений (необработанные сообщения можно всегда доставить новой версии объекта; а, если, осуществлять скрещивание или расщепление объектов с элементами генной инженерии?), при этом, сами сообщения тоже могут быть объектами-агентами особого сорта (могут приниматься другими объектами, но сами могут обрабатывать сообщения).