История изменений
Исправление vbr, (текущая версия) :
динамическое управление переменными в run-time;
Это очень плохо. Переменные должны быть статическими. Человечество не зря 50 лет шло к статической типизации.
API, позволяющее использовать: деревья, списки, память, таблицы, строки, …
Это есть в любом языке, включая C и Basic. Более того, львиная доля из этих структур данных на практике не пригождается. Нужны массивы и словари. Или даже гомогенная структура (ведь массив по сути такой же словарь).
Расскажу немного о таблицах.
Нужна поддержка SQL для запросов по таким таблицам. Причём интегрированного в языке в типизированном виде. Можно посмотреть, как это сделано в PL/SQL.
Строки таблиц могут содержать данные любых базовых типов и объекты.
Это очень плохо. Объекты поддерживать нельзя. Это лишнее. Таблица суть реляция, отношение. К объектам это не имеет отношения. Должны быть только данные базовых типов. Да и в целом ООП показало себя плохим подходом, от объектов лучше держаться подальше, включая терминологию.
При этом возможно в колонках строк можно использовать разного типа данные (например в первой строке первый элемент строка, а в следующей объект).
Это очень плохо. Должна быть строгая типизация.
Например доли секунды требуются для создание таблицы, содержащей например миллион натуральных чисел, получения их суммы и удаления элементов в трёх циклах.
Это очень долго. Например на Java такая операция выполняется за 2-3 миллисекунды. А ведь Java это не самый быстрый язык. Нужно оптимизировать скорость.
Исправление vbr, :
динамическое управление переменными в run-time;
Это очень плохо. Переменные должны быть статическими. Человечество не зря 50 лет шло к статической типизации.
API, позволяющее использовать: деревья, списки, память, таблицы, строки, …
Это есть в любом языке, включая C и Basic. Более того, львиная доля из этих структур данных на практике не пригождается. Нужны массивы и словари. Или даже гомогенная структура (ведь массив по сути такой же словарь).
Расскажу немного о таблицах.
Нужна поддержка SQL для запросов по таким таблицам. Причём интегрированного в языке в типизированном виде.
Строки таблиц могут содержать данные любых базовых типов и объекты.
Это очень плохо. Объекты поддерживать нельзя. Это лишнее. Таблица суть реляция, отношение. К объектам это не имеет отношения. Должны быть только данные базовых типов. Да и в целом ООП показало себя плохим подходом, от объектов лучше держаться подальше, включая терминологию.
При этом возможно в колонках строк можно использовать разного типа данные (например в первой строке первый элемент строка, а в следующей объект).
Это очень плохо. Должна быть строгая типизация.
Например доли секунды требуются для создание таблицы, содержащей например миллион натуральных чисел, получения их суммы и удаления элементов в трёх циклах.
Это очень долго. Например на Java такая операция выполняется за 2-3 миллисекунды. А ведь Java это не самый быстрый язык. Нужно оптимизировать скорость.
Исходная версия vbr, :
динамическое управление переменными в run-time;
Это очень плохо. Переменные должны быть статическими. Человечество не зря 50 лет шло к статической типизации.
API, позволяющее использовать: деревья, списки, память, таблицы, строки, …
Это есть в любом языке, включая C и Basic. Более того, львиная доля из этих структур данных на практике не пригождается. Нужны массивы и словари. Или даже гомогенная структура (ведь массив по сути такой же словарь).
Расскажу немного о таблицах.
Нужна поддержка SQL для запросов по таким таблицам. Причём интегрированного в языке в типизированном виде.
Строки таблиц могут содержать данные любых базовых типов и объекты.
Это очень плохо. Объекты поддерживать нельзя. Это лишнее. Таблица суть реляция, отношение. К объектам это не имеет отношения. Должны быть только данные базовых типов.
При этом возможно в колонках строк можно использовать разного типа данные (например в первой строке первый элемент строка, а в следующей объект).
Это очень плохо. Должна быть строгая типизация.
Например доли секунды требуются для создание таблицы, содержащей например миллион натуральных чисел, получения их суммы и удаления элементов в трёх циклах.
Это очень долго. Например на Java такая операция выполняется за 2-3 миллисекунды. А ведь Java это не самый быстрый язык. Нужно оптимизировать скорость.