Comments 26
Почему выбрали одновременно строгую типизацию для свойств объектов и одновременно отсутствие типизации в переменных?
Часто языки притягиваются к чему-то одному: уж либо все типизируем, либо нет. А такая частичная типизация, имхо, соберет недостатки от обоих подходов: и многословность от строгой типизации, и ошибки во время выполнения от отсутствия.
Операции с variant-данными (u.)
between
А это как? я так понял, что variant - это "любой тип данных". К любым у вас относятся и объекты. Как вы операторы больше/меньше/равно для них реализуете, чтобы можно было "между" вычислить? У вас там перегружаемые операторы сравнения?
Очень приятно, что Вы внимательно читаете статью! Но, в описании операций сравнения указано, что для ссылочных и логический типов данных допустимы только операции сравнение на равенство (==,<>). Перечитайте это место. А, прежде чем сравнивать variant переменные, неплохо бы проверить текущий тип этой переменой.
Почему Вы решили, что для переменных отсутствует строгая типизация. Первая латинская буква в имени переменной жестко определяет ее тип и этот тип не может быть переопределен. Наличие переменных неопределенного типа просто необходимо, хотя бы для взаимодействия с внешними источниками данных.
А, я понял. Т.е.
oTrv as treeview
тут одновременно и "o" первой буквой участвует в типизации, и "as treeview"? Тогда получается типизация разорвана на 2 разных участка?
Тип переменной определяется первой буквы, а конструкция as предназначена только для средств IntelliSense и служит указанием, что эта переменная будет ссылаться в на объект класса treeview. Проблема в том, что Вы привыкли использовать as для определения типа.
Все равно выходит странно.
У вас правая часть как будто бы и является самым точным определением типа. А то, что это тип является и объектом заодно обычно в языках следует из иерархии наследования. Если вы правую часть используете только как подсказку IDE, то реальная типизация выполнена по первой букве - и тогда в эту переменную можно положить любой объект. Если мы рассуждаем об ООП языках, то в них оперируем сразу кучей разных классов. Зачем нужна столь слабая типизация? Обычно типизация же защищает от ошибок, а тут, похоже, я могу таки положить в oTrv совсем не характерный для нее объект.
Целью разработки языка ULCA было создание строго формализованного предельно простого универсального языка программирования совместимого со всеми объектно-ориентированными языками
А зачем? Все существующие языки усложняются с каждой новой версией. Не просто так, а "по многочисленным заявкам" в комьюнити. Так для чего суперпростой язык? Зачем этот сферический конь в вакууме? Для обучения? Уж лучше учить на подмножестве какого-то реального языка, потому что нет ни одной вакансии на языке UCLA.
Автор, было бы интереснее в 2-3 предложениях увидеть вашу мотивацию создания данного языка. Возможно, я ваши статьи не очень внимательно читал - но описание мотивации как-то ускользнуло от моего восприятия.
Если это просто ваше хобби - тогда это круто. Подобные проекты помогают формализировать мысли.
Речь идет не о языке программирования, а уже работающем программном продукте.
Язык - это только маленькая его часть.
Вы наверно хотели узнать, является ли мой проект коммеческим. Отчасти, да.
Бизнес и программирование - это о разном. Цель бизнеса - получить максимум прибыли и как можно быстрей. С другой стороны, без поддержки бизнеса или государства, продвинуть новый проект практически невозможно. Поэтому, я пытаюсь найти баланс между интересами бизнеса и возможностью использовать проект без ущерба для его развития.
нет, я просто не понял зачем это нужно. Чем этот язык лучше, чем уже имеющиеся решения. Выглядит просто как дополнительная абстракция - и для меня это не плюс.
Язык ULCA - это интерпретирумый язык. Интерпретатор может быть написан на любом обьектно-ориентированном языке. Поэтому такое внимание к совместимости языка ULCA с этими языками.
Опять нет ответа, чем это лучше того же Питона, например.
И при чем тут язык самого интерпретатора? Вообще не понял. Хоть на Ассемблере, хоть на Фортране пишите интерпретатор - какая разница?
судя по вашим ответам - вы не можете объяснить, чем этот язык лучше.
выглядит просто как костыльная надстройка над существующим с целью навязать бизнесу свою незаменимость. В этом плане решение хорошее, хоть и сомнительное. А в плане замещения существующего - просто сомнительное.
Автор упирает на то, что это максимально простой язык. Но он забыл, что уже есть предельно, супер-максимально простейший язык - машина Тюринга. Только вот на ней никто не программирует. Заговор, не иначе.
В формате штамп есть сведения о часовом поясе.
А как быть с датами до нашей эры в клинтских приложения, а главое, зачем, я не понимаю.
Как работать с датами до нашей эры?
Как работать с временм в разных часовых поясах?
Не надо переизобретать велосипед, причем, не самый лучший. Все это проработано в других языках.
Штамп: s - stamp
Занимает в памяти 10 байтов и содержит дату, время и номер пользователя, создавший этот штамп.
А где этот "номер пользователя"? Его нет ни в описании, ни в примерах. Да и вообще существование номера пользователя в типе данных о времени нехарактерно. Вот если бы это была попытка изобрести разновидность уникального идентификатора, то тогда смесь времени и номера пользователя была бы объяснимой - получился бы в целом нормальный идентификатор, но без поддержки распределенных систем.
Вы попали в самую точку! Действительно, в Ситеме штамп является уникальным идентификатор записи таблицы. А номер пользователя делает его его уникальным во всей базе данных.
Следующие две статьи будут посвящены виртуальной СУБД, где все это будет детально рассмотрено. Данная статья и так сильно перегружена.
Синтаксис языка программирования ULCA