Рейтинг языков программирования TIOBE назвал самый популярный язык 2019 года

21.01.2020      106883

Первым, по версии составителей рейтинга TIOBE, ожидаемо стала Java, а второе место неожиданно досталось C. Серебряный призер рейтинга обогнал Python – лидера 2007, 2010 и 2018 годов. 

TIOBE ежемесячно отражает популярность различных языков программирования. Составители рейтинга учитывают запросы в Google, Bing, Yahoo!, Baidu, а также к сайтам вроде Wikipedia, Amazon и YouTube. Рейтинг определяет не самый лучший, а самый популярный язык программирования, и подсказывает разработчикам, в каком направлении двигаться, чтобы остаться востребованным специалистом или сменить профиль. 

Чудеса случаются

Изменения в рейтинге TIOBE происходят нечасто. В апреле 2019 года С++ выдавил Python из тройки лидеров, но впоследствии вновь опустился на четвертую строчку. Разработчики ожидали, что Python вернет себе прежние позиции и завоюет первое место к 2020 году, но авторы рейтинга решили присудить победу С. 

Первая десятка рейтинга TIOBE в январе 2020 года выглядит так: 

 

 

Главные достоинства С – высокая скорость, возможность работать на низком уровне, напрямую обращаться к памяти. Конструкции языка сопоставляются с характерными машинными инструкциями. В то же время С позволяет писать достаточно высокоуровневый код. С был лидером рейтинга TIOBE с 1985 года. В конце 90-х он уступил С++, но смог отвоевать позиции. В 2010 году на первую строчку выбралась Java. С сумел ненадолго подвинуть ее, но сейчас все же занимает почетное второе место. 

Авторы рейтинга показали, как менялись позиции самых известных языков каждые пять лет: 

 

 

Языки, которые смогли

Составители отметили и другие языки, которые за год улучшили свои позиции. Если популярность С за год выросла на 2,4 процентных пункта (п.п.), то C# – на 2.1 п.п., Python – на 1,4 п.п., Swift – на 0,6%. 

C# поднялся с седьмого места на пятое, Swift – с пятнадцатого на девятое. Отметим и Ruby: он перепрыгнул с восемнадцатой строчки на одиннадцатую. Но в абсолютном зачете по-прежнему лидирует Java. Прежде всего, благодаря миллионам Android-пользователей и разработчиков и развитию интернета вещей. Один из главных аутсайдеров – С++: его популярность снизилась на 2,58 п.п. Но позицию «плюсы» не потеряли. А вот Visual Basic .NET, JavaScript и SQL опустились на строчку вниз. 

Вот как менялась популярность языков с 2001 года по месяцам:

 

 

Что обеспечило победу С

Создатель языка C Деннис Ритчи представил его в 1972 году. Компилируемый статически типизированный язык основан на языке B компании Bell Labs для реализации в ОС UNIX. Позднее его перенесли и на другие платформы.

Производительность приложений критически важна и для старых компьютеров, и для устройств интернета вещей. Для их работы нужен быстрый и эффективный код, который сможет работать в ограниченных условиях – с жестким лимитом памяти и слабыми процессорами. С изначально разрабатывался для таких устройств. Его расцвет пришелся на время, когда компьютеры были огромными, но умели не больше, чем современная кнопочная «звонилка».

Компиляторы С сегодня доступны практически для каждого процессора. Можно написать одно приложение и скомпилировать его под различные платформы, практически не меняя код. 

Раньше С также считали легким для изучения. Сегодня с этим можно поспорить, приведя в пример тот же Python. Классический «Hello world» на С выглядит так:

 

#include <stdio.h>

int main() {

printf("Hello, world!");

return 0;

}

 

На Python все же гораздо проще:

 

print("Hello, world!") 
 

Без подключения библиотек, лишних скобок и возврата значений-статусов. Но все же Python не позволит настолько плотно взаимодействовать с данными в оперативной и постоянной памяти, выживать в средах, где война идет за каждый килобайт. Скорее, он предназначен для создания скриптов, которые запускаются без особых переживаний о ресурсах. 


Автор:
Обозреватель


Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. triviumfan 92 21.01.20 17:30 Сейчас в теме
Этот индекс равносилен средней температуре по больнице.
dimisa; wowik; AlexSinichenko; d.zhukov; +4 Ответить
2. pm74 199 21.01.20 18:11 Сейчас в теме
Что обеспечило победу С

..
пока вроде Java чемпион

ксти в python можно подключать сишные библиотеки
3. AlexSinichenko 22.01.20 03:43 Сейчас в теме
Блин какая на самом деле статья ни о чем, пытающаяся перевернуть все с верх на голову.
Специально для автора объясняю
Директивы препроцессора:
#include <stdio.h>

Объявление функции
int main() {

Внимание!!!! Вывод строки!
printf("Hello, world!");

Конец функции
return 0;
}

Если уж упрощать на С то вполне достаточно и так:
#include <stdio.h>

void main() {
     printf("Hello, world!");
}

в Phyton точно так же есть элементарное объявление функций, потому что если он выполняет код построчно и там достаточно для вывода строки на экран написать лишь одну строку кода
print("Hello, world!")

то это уже не ООП а голимый Basic какой-то или элементарный .bat файл, который выполняет код построчно не зная вообще в принципе о существовании процедур и функций которые можно вызывать (при этом как ни странно знать, что существует функция print() которую все же вызывать можно)!
Теперь пожалуйста объясните мне программисту с 15-ти летним стажем, чем отличается написанное на С
printf("Hello, world!");

от написанного на Phyton
print("Hello, world!")


Я к тому, что на phyton для вывода строки недостаточно написать лишь
print("Hello, world!")

Нужно потрудиться точно так же, описав хотябы минимальную функцию в теле которой и будет вызываться вывод строки (или будет производиться выполнение любого другого кода соответственно).
Тем самым констатирую факт, вывод строки на Phyton ничем не проще вывода строки на С не вводите людей в заблуждение.
Perfolenta; Lazio; protexprotex; dimisa; nbondarenko; wowik; de0nis; djut77; pm74; +9 1 Ответить
4. Darklight 32 22.01.20 09:36 Сейчас в теме
(3)К сожалению вот такие тексты программ по выводу "Hello, world!" это мировая практика сравнения языков.
В современных реалиях было бы корректнее сравнивать хотя бы через задачу ассинхронного вывода того же текста "Hello, world!", читаемого из файла средствами одного компьютера (из набора свободных), и выводящегося на консолях из списка других компьютеров, с управлением от третьего компьютера, с динамически выбираемым способом чтения и вывода данного текста, источника и приемника!
Это конечно шуточное предложение - но в каждой шутке есть доля истины! И язык Си такое сравнение с треском проиграет пока дело не дойдёт до замеров производительности!
Просто на таких примитивных примерах совершенно невозможно показать ни красоту ни мощь ни комфорт ни понятность языка!
Просто современные задачи уж очень далеки от стиля программирования "Hello, world!", о того и современные языки обзавелись продвинутыми синтаксическими инструкциями высокого порядка - которые позволяют писать сложные вещи очень просто и кратко - но примеры "Hello, world!" это совсем не способны показать!

И к слову, в Python мне совсем не нравится отсутствие, например, программных скобок блок алгоритмов - а это очень сокращает число строк кода.
Импорт библиотек мне тоже не нравится как сделан, как и система декораторов - хотя в Си с этим ещё хуже!
6. starik-2005 3033 22.01.20 10:01 Сейчас в теме
(4)
И язык Си такое сравнение с треском проиграет пока дело не дойдёт до замеров производительности!
Я бы не был так категоричен, Запилить веб-сервер на С - это три строки кода (по сцылке достаточно сложный пример, для управления можно куда проще), управление консолькой с третьего компа на первых двух - очень простая задача. И если у вас венда, то питоновское окружение еще нужно будет развернуть, в то время как скомпилированный код на С будет уже "готов к эксплуатации".
Perfolenta; protexprotex; AlexSinichenko; +3 Ответить
7. Darklight 32 22.01.20 10:06 Сейчас в теме
(6)Да я не хотел, чтобы это воспринимали уж очень категорично. Просто намекнул - что сравнивать нужно в более актуальном контексте
14. Perfolenta 204 19.02.20 17:28 Сейчас в теме
(4)
И к слову, в Python мне совсем не нравится отсутствие, например, программных скобок блок алгоритмов - а это очень сокращает число строк кода.

Вы просто привыкли к Си подобному синтаксису... а мне эти скобочки не нравились никогда... т.е. это просто вкусовщина не влияющая на качество и возможности языка...
Да, количество символов уменьшается, но за счет читаемости... особенно при прокрутке текста программы снизу- вверх...
В 1С я вижу какой-то кусочек кода и при этом вижу, что он в двух вложенных циклах... а в Си я вижу только кучу скобочек... что бы понять контекст мне надо крутить вверх...
А вот на запись программы это мало влияет... я почти никогда не пишу все эти КонецЕсли, КонецЦикла... они сами добавляются...
Нет предмета для спора, вопрос привычки...
П.С.
Если посмотреть в историю этого вопроса, то, как мне кажется основной спор произошел во времена появления Си и Паскаля... в те времена память компьютера измерялась в килобайтах и скобочки были гораздо экономнее, чем begin и end... а еще, слово begin обычно лишнее в синтаксисе, т.к. и без него понятно, где начинается блок... а слово end без указания конец чего это, почти не отличается от закрывающей скобки, только длиннее...
В Питоне обошлись без обозначения конца блока, но сделали плохо для IDE, т.к. из-за этого только человек может форматировать текст... если человек забыл пробелы поставить, то IDE об этом ни как не догадается...
Вывод: идеального решения пока нет...
15. Darklight 32 19.02.20 18:22 Сейчас в теме
(14)Нет, дело не в экономии памяти. Изначально было дело в экономии в наборе текста (сейчас не так акутально - ибо многие IDE савми ставят эти скодбки причём не только конечные, но и начальные), а так же сокращении числа зарезервированных слов, которые нужно учить - это что касабельно языка Си - там как раз всё более менее лаконично спроектировано. Извращения начались с языка C++ - я, как и Вы, терпеть не могу!
В унификации скобок есть преимущество - при рефакторинге текста с несколькими вложенными блоками - проще эти скобки "переставлять" и удалять, чем кучу разноимённых операторов конца блока.

Но сейчас есть ещё пара важных преимуществ фигурных скобок:

1. Они позволяют синтаксически чётко выделять места - где расположен программный код. Который в лексике современных языков часто воспринимается как продолжение значений данных. То есть операторы языка просто являются командами, которым на вход подаются такие блоки кода - такая логика построения программ позволяет делать его лексику очень изящной, простой и достаточно мощно и универсально расширяемой. Особенно это круто смотрится при применении макросов (когда язык позволяет) - которым не нужно задумываться о том как разграничиваются блоки кода в контексте вызова.
Очень круто ещё и сделано в Kotlin - где если у функции последний параметр имеет тип "body" (то есть принимающий выражение программного кода) то его можно опустить и тогда следующий справа за вызовом такой функции код (в т.ч. в программных скобках) будет автоматически передан в эту функцию - получается крутой гибрид функционально-императивного стиля программировния. Особенно когда это единственный аргумент функции и её можно вызвать без скобок просто как "команду языка"

2. Ещё одно важное преимущество выделение кода в блооки - это их применения в разных синтаксических струкутрах определений объектов языка (не только классов но и функций, например). когда определение заголовка, скажем, функции чётко отделяется от её тела - тогда между телом и, скажем, списком аргументов - можно размешать различные ключевые слова и прочие директивы - например правостороннее определение типа возвращаемого значения. И это в будущем лего расширяется.
Вот например в 1С
Функция МояФункция() экспорт возврат 1; КонецФункции 

Где здесь тело функции?
Ну понятно - что просле слова экспорт, а почему именно после - почему экспорт относится ещё к заголовку а является ключевым слово внутри функции
И если разработчику языка в будущем понадобится добавить ещё директивы (например "ПовторноеИспользование", или расширить варианты экспорта - "ВнутреннийЭкспорт" - только внутри текущего контекста объекта) - то вставить их в области слова "экспорт" будет уже очень затруднительно - ибо может пересечься с программным кодом модуля.
Вот и 1С стала расширять директивы функций другим путём (ставя их слева с амперсендом):
&НаСервере Функция МояФункция() экспорт возврат 1; КонецФункции 


Тут, конечно, уже, дело вкуса - но я за то, чтобы директивы были справа - и могу это аргументировать!

А было бы так - вопросов бы не было
Функция МояФункция() &!Приватный&НаСервере&НаКлиенте&ВнешнееСоединение&ПовторноеИспользование&ВозвращаемыйТип(Число(1,0))
{ возврат 1; }  


А у питона вообще нет программных скобок - набирать текст легче - а вот красиво его по своем форматировать, расширять (декораторы питона ужасны) и анализировать готовый текст - уже не так приятно!
16. Perfolenta 204 19.02.20 19:31 Сейчас в теме
(15)
Нет, дело не в экономии памяти. Изначально было дело в экономии в наборе текста

тут я с вами не согласен, т.к. сам в те времена боролся за экономию каждой буквы, когда текст программы тупо не влезал в буфер памяти... а набрать слово end не на много труднее, чем нажать Shift+{

В унификации скобок есть преимущество - при рефакторинге текста

а вот тут я с вами полностью согласен... при любой автоматической обработке кода скобочки лучше...
но при чтении кода человеком это уже не так однозначно... если обе скобки не в пределах видимости или много уровней вложенности, то человек теряется... попробуйте посчитать сколько тут нулей 00000000000000000000... трудная задача, глазам не за что зацепиться... это из той же психологической оперы, что и множество скобок...

Где здесь тело функции?
Ну понятно - что просле слова экспорт, а почему именно после

самое главное, что и вам понятно и компилятору понятно, проблема только у разработчика компилятора... на мой взгляд, слово Экспорт было изначально не удачно прилеплено, его часто даже не видно, когда окно редактора не слишком широкое... у меня, в Перфоленте, есть такая же проблема с указанием типа функции, он тоже справа указывается... как и с Экспортом в 1С это решается возможностью переноса на следующую строку, если название функции длинное или параметров много...
Казалось бы можно как в Си тип слева указывать, но тут тоже есть подводный камень, сегодняшние типы могут сами очень длинно записываться и тогда сама функция уезжает слишком вправо...

Вот и 1С стала расширять директивы функций другим путём (ставя их слева с амперсендом)

Слева для нас приятнее, мы же слева на право читаем...

Они позволяют синтаксически чётко выделять места - где расположен программный код.

проблема в том, что в современных языках фигурные скобочки применяются не только для блоков кода, но и для других нужд, например, для инициализаторов, для шаблонов строк и т.д.... и при беглом осмотре не всегда глаз может быстро выделить где что... скобок становится много... IDE конечно помогает облегчить чтение...
я в Перфоленте принял, что круглые скобки - параметры, квадратные - индексаторы, фигурные - инициализаторы...

А было бы так - вопросов бы не было
Функция МояФункция() &!Приватный&НаСервере&НаКлиенте&ВнешнееСоединение&ПовторноеИсп­ользование&ВозвращаемыйТип(Число(1,0))
{ возврат 1; }

С точки зрения формальной логики вы правы, но читая как человек, приходишь к мысли, что ты ведь не машина...

П.С. много сотен лет ученые мужи создавали разные методики формальной записи знаний, в том числе и алгоритмов... но самые совершенные из этих способов оказались слишком не человеческими... вот мы и балансируем теперь где-то на грани, между формальным и человеческим... идеальной модели не будет... идеально будет, когда машина станет понимать человеческую речь с достаточной точностью... но до этого еще далеко... да и может плохо кончиться :)
27. Darklight 32 25.02.20 14:40 Сейчас в теме
(16)

Так как мне есть что сказать на эту тему я написал очень длинный ответ, занявший более 30 страниц чистого текста. Но этот разговор явно не соответствует теме исходной новости. Поэтому я этот текст постараюсь тогда оформить в виде статьи (куда, если Вы не будете против) вставлю некоторые Ваши цитаты (с указанием Вашего авторства; ссылку на Ваш проект тоже дам, хотя пока не планирую выстраивать статью вокруг вашего проекта – а хочу абстрагировать). И буду там давать, в ответ на эти цитаты, развёрнутые ответы, с примерами и картинками. Ибо для меня эта тема очень важна и интересна и тут у мен есть свои взгляды, хоть я их в одной, даже такой большой, статье изложить не с могу. Тем более, что у меня уже есть наработки для большого цикла статей – посвящённых моему виденью того, каким должен быть язык программирования в гипотетической платформе 1С: Предприятие 9 – лет так через 20-30 (если он останется самобытным, но в то же время будет подстраиваться под мировые тренды). Возможно, некоторой здешней аудитории это обсуждение так же будет интересно – и такая статья привлечёт их внимание. Ну, а может быть изложенные мною мысли найдут воплощение в чьих-либо будущих проектах. Ну а ещё – а хочу там сделать голосование – было бы интересно узнать мнение широкой аудитории.
Но тут, я всё-таки, сейчас дам очень краткие ответы (не очень содержательные, и возможно вырванные из контекста – ведь так оно и будет) – итоговые мысли по вашим цитатам. И считаю, что дальнейшее обсуждение, в рамках данного сабжа лучше завершить, в силу того, что это уже полный оффтопик. Ну а дальше – ждите статью.
Итак, очень-очень кратко отвечаю:

тут я с вами не согласен, т.к. сам в те времена боролся за экономию каждой буквы, когда текст программы тупо не влезал в буфер памяти... а набрать слово end не на много труднее, чем нажать Shift+{

Ну, те времена давно прошли и нынче не актуальны. Вот Visual Studio сейчас неплохо умеет вставлять скобки.

А в 1С – язык «русский», а в русском языке «беда» с окончаниями – со склонением словесных скобок всё очень неудобно.


а вот тут я с вами полностью согласен... при любой автоматической обработке кода скобочки лучше...
но при чтении кода человеком это уже не так однозначно... если обе скобки не в пределах видимости или много уровней вложенности, то человек теряется... попробуйте посчитать сколько тут нулей 00000000000000000000... трудная задача, глазам не за что зацепиться... это из той же психологической оперы, что и множество скобок...

Просто не стоит писать такой вложенный код. Нужно разбивать код на более мелкие автономные фрагменты. IDE тут в помощь.

А что словесные скобки – тут ничем не помогут. Я точно так же могу написать кучу вложенных чередующихся блоков «если» и «цикл» – и так же в них легок запутаюсь сам (не то, что другой программист, который потом это будет разгребать). И не только я так пишу и путаюсь.

Да, фигурные скобки тут не помогут – но и словесные не спасают! Тут другие решения.

Вообще книгу Роберта Мартина «Чистый код» нужно всем читать! Путь это не 1С и написана книга весьма сурово и категорично – но всё равно – чтение очень полезное!

А в остальном тут должна помогать сама IDE.


Где здесь тело функции?
Ну понятно - что после слова экспорт, а почему именно после
самое главное, что и вам понятно и компилятору понятно, проблема только у разработчика компилятора...

Вот из-за различных просчётов на первых этапах развития языка появляются всякие гадкие и некрасивые конструкции на последующих этапах его развития. Потому что иначе возникают всякие неоднозначные траблы при синтаксическом разборе.


на мой взгляд, слово Экспорт было изначально не удачно прилеплено, его часто даже не видно, когда окно редактора не слишком широкое... у меня, в Перфоленте, есть такая же проблема с указанием типа функции, он тоже справа указывается... как и с Экспортом в 1С это решается возможностью переноса на следующую строку, если название функции длинное или параметров много...

Оно Вам так надо видеть? Лично мне все вот эти директивы при просмотре кода не особо важны. Важные пояснения лучше делать в комментарии перед функцией, и правильно называть саму функцию. Что не важно программисту, который использует этот код как потребитель – то, значит, не и важно вовсе, и не нуждается в каком-то особом выделении (т.е. такие директивы важны чисто для компилятора).
о горизонтальной прокрутке и длине строки в редакторе

Вообще тут да, палка о двух концах. На самом деле и справа не очень удобно и слева не очень красиво (более детально этот вопрос я освещу в статье, а пока просто один пример):

Левосторонние (на отдельной строке) привязки (гипотетических) директив

Правосторонние привязки (на разных строках)


Правосторонние привязки (в одну строку)


Для меня самого, по-прежнему, открыт вопрос того где лучше размещать директивы. Но, я за правое размещение. А если нужно видеть что-то важное – пусть в этом помогают комментарии и IDE.

И ещё – зачем вообще их просматривать в коде? Для анализа API? Для этого должна использоваться синтакс-справка (автогенерируемая) и интелли-сайнс (всплывающая подсказка). И программист может помочь сгенерировать правильно – указав советующие директивы:

Пример

Это только пример – возможны и другие подходы (более подробно – напишу в статье; как и ещё 7 других аргументов против желания выносить директивы в левую сторону).

Ну ещё - можно просто разрешить размещать директивы как слева, так и справа. Но тогда нужно как раз особо будет актуален вопрос разделения блоков кода – в т.ч. начала тела функции от её заголовка (куда будут отнесены директивы на их границе, если её не будет).
Другое дело – вот так (правостороннее размещение директив):

Функция МояФункция() &Контекст{Сервер,Клиент,!Мобильный,Внешний,Внутренний}&Кешировать(20*60)&ВозвращаемыйТип(Строка)
{
    возврат «Привет»;
}


Тело функции явно обозначено областью с фигурными скобками, и отделено от заголовка.


Казалось бы можно как в Си тип слева указывать, но тут тоже есть подводный камень, сегодняшние типы могут сами очень длинно записываться и тогда сама функция уезжает слишком вправо...

Вот именно. Проблема, как и с директивами. Лично я тут строго за правостороннее размещение ограничений типов. В 1С просто этой проблемы нет (т.к. язык с динамической типизацией, без возможности указывать ограничения на типы - как, скажем в Python – где при наличии динамической типизации это всё-таки возможно, с 3-ей редакции, через декораторы). Типы (а-ля 1С) действительно могут быть очень длинными «Тип(ДокументСсылка.РеализацияТоваровУслуг)». А если бы в 1С были классы…

Конечно, знать тип возвращаемого значения функции гораздо важнее чем директивы. Это, на самом деле, важно и для языков с динамической типизацией.

Выхода здесь два (я за использование сразу обоих):
Назначать длинным именам типов более короткие псевдоними типа.
Альтернативный (дополняющий) вариант предлагает вынести длинные описания типов в отдельное место (без образования псевдонимов), скорее всего, верхнем левостороннем варианте размещения над основным определеним (в примере ниже – над функцией, в т.ч. для аргументов):

Пример

Но на мой взгляд, по крайней мере, что касается аргументов, этот вариант ничем не лучше правостороннего размещения типов.


Вот и 1С стала расширять директивы функций другим путём (ставя их слева с амперсендом)

Слева для нас приятнее, мы же слева на право читаем...

Я не спорю и пишем и читаем слева на право – тут важно только размещать и видеть слева наиболее важную информацию, да так, чтобы она не сильно мешала видеть другую, тоже важную информацию, размещённую правее.


Фигурные скобки позволяют синтаксически чётко выделять места - где расположен программный код


проблема в том, что в современных языках фигурные скобочки применяются не только для блоков кода, но и для других нужд, например, для инициализаторов, для шаблонов строк и т.д.... и при беглом осмотре не всегда глаз может быстро выделить где что... скобок становится много... IDE конечно помогает облегчить чтение...
я в Перфоленте принял, что круглые скобки - параметры, квадратные - индексаторы, фигурные - инициализаторы...


Инициализаторы – это просто частный случай программных блоков. По сути – это тоже программный код – просто написан в определённом формате и представляет собой не поток инструкций, а выражения (в программный код обычно бывает двух типов: «поток инструкций» и «единое выражение»). И на основе этого выражения (я про Ваши инициализаторы) компилятор выстраивает программный код – в виде конечных инструкций. Секция инициализации – это просто особый способ записи программных выражений – из частей, каждая из которые, к тому же, сама может быть программным выражением (уже записываемом в обычном, для таких выражений, формате).

Поэтому, лично я воспринимаю всё, что написано в фигурных скобках как программный код (либо в виде «потока инструкций» либо в виде «выражения»). И то и другое – требует специфического (контекстного) лексического разбора. Посмотрите как фигурные скобки разбирает современный язык – Kotlin.

А было бы так - вопросов бы не было
Функция МояФункция() &!Приватный&НаСервере&НаКлиенте&ВнешнееСоединение&ПовторноеИсп­-ользование&ВозвращаемыйТип(Число(1,0))
{ возврат 1; }


С точки зрения формальной логики вы правы, но читая как человек, приходишь к мысли, что ты ведь не машина...


Почему же – как раз расположенный справа сложный набор команд препроцессора и компилятора уедет за пределы беглого взгляда при анализе кода, и не будет отвлекать от более важного – определения самой функции и её API. Об этом выше я написал уже.


П.С. много сотен лет ученые мужи создавали разные методики формальной записи знаний, в том числе и алгоритмов... но самые совершенные из этих способов оказались слишком не человеческими... вот мы и балансируем теперь где-то на грани, между формальным и человеческим... идеальной модели не будет... идеально будет, когда машина станет понимать человеческую речь с достаточной точностью... но до этого еще далеко... да и может плохо кончиться :)

Языки программирования пока далеки от литературной речи. И на данный момент являются просто прослойкой между программистом и бинарным кодом инструкций процессора (а точнее – в актуальном мире, чаще всего, между промежуточным машинным языком или байткодом; хотя есть и чисто интерпретируемые языки – у которых интерпретатор на лету превращает текст программы во внутренние инструкции, вызывая в дальнейшем те или иные встроенные функции).

А насчёт понимания машинами человеческой речи – лично я не думаю, что именно эта технология что-то кардинально изменит во взаимодействии с программистом. Тут могут только два этап эволюции:
Появятся AI смарт-помощники в IDE, которые будут на лету анализировать что пишет программист (в т.ч. с углублённым статистическим анализом), и сразу предлагать готовые решения завершения отельных блоков кода. И выполнять другие строго заданные сервисные функции (основанные на поиске по базе знаний и заложенным схемам действия).

И да – для всего этого будет активно применяться живое общение (устное и письменное). Ждать наступления этой эры уже не так уж долго – думаю в Visual Studio это появится (в таком объёме) уже к середине века (а сам смарт-ассистент там появится уже к 2030 году ну максимум в 30-х годах; в 20-х годах его будут «отлаживать» в офисных продуктах – это уже почти 100% точно). Но по сути – это всё ещё будет просто инструменты, упрощающие ввод и изменённые текста. И это просто будет часть редактора.


А, вот, когда AI сможет, на основе хотя бы формализованного тех задания, самостоятельно генерировать текст программы (уже без участия программиста). То настанет новый этап эволюции компьютерных систем. Программисты тут уже почти не будут писать программный код (вернее останется ниша низкоуровневого программирования – для формирования некоторых библиотек, которые далее будет использоваться искусственным интеллектом). Высокоуровневый код (для бизнес-логики) – будет создаваться людьми все реже и реже – в основном только тогда, когда в каких-то областях AI ещё не поднатаскается – но он быстро будет это всё навёрстывать.
Практически 100% всего прикладного кода и решать почти все прикладные задачи – и такие программисты будут уже не востребованы.
К XXII веку AI активно перетянет на себя большую часть всех сфер занятости людей (по крайней мере, не требующих физического труда – да то, проблемы будут лишь в ограниченных областях).

Суть сказанного в том, что по сути нет нужды создавать уж очень «человечный» синтаксис языка, в смысле – более похожий на человеческую речь. На первом этапе это скорее даже будет мешать (перегружая глаза и мозг лишней информацией). А на втором этапе – уже и не особо нужно будет – описательные языки – это всё-таки не языки программирования. Ну а далее – и вовсе не будет нужно – там AI сами будут в процессе общения с ними создавать и выполнять алгоритмы (уже не прибегая даже к языкам программирования).


Ну вот, хотел написать коротко – а всё равно вышел очень длинный ответ
28. Perfolenta 204 25.02.20 15:03 Сейчас в теме
(27) да, вы самый интересный собеседник из всех которые у меня были за время создания языка Перфолента... будь вы у меня лет на 10 раньше, то и язык пошел бы во многом по другому пути...
Используйте любые мои цитаты, как вам будет необходимо...

Извиняюсь, у меня на этой неделе крайне мало времени, не могу подробно разобрать этот ваш комментарий, надо над ним поразмышлять, замечу только, что согласно вашей классификации я принял в Перфоленте левосторонние привязки с предпочтением на отдельной строке...
например, вот так у меня выглядят разные атрибуты классов, методов, параметров и возвращаемого значения:
&ВидноВсем, 
ИмпортМетода("user32.dll"){ .EntryPoint="FindWindowExW"}
Функция FindWindowExW(hWndParent тип ЦелУкз, 
                      hWndChildAfter тип ЦелУкз, 
                      &MarshalAs(UnmanagedType.LPWStr) lpszClass тип Строка, //параметр с атрибутом
                      &Новый MarshalAs(UnmanagedType.LPWStr){} Знач lpszWindow тип Строка //параметр с атрибутом
                      ) тип ЦелУкз
КонецФункции


//добавим к параметрам метода собственный атрибут АнглСиноним
&ВидноВсем
Функция СобратьБит32( &АнглСиноним("HighDigits") Знач СтаршиеРазряды тип Бит16, 
                      &АнглСиноним("LowDigits")  Знач МладшиеРазряды тип Бит16
                      ) &АнглСиноним("ReturnValue") тип Бит32 //к возвращаемому параметру тоже можно применить атрибуты
    Возврат (Бит32(СтаршиеРазряды) << 16) БитИли МладшиеРазряды
КонецФункции

Показать

чем-то похоже на ваши примеры... расцветка кода, конечно, пострадала при вставке в текст комментария, т.к. это расцветка 1С... но выглядит все еще более менее..
29. Darklight 32 25.02.20 18:08 Сейчас в теме
(28)Да, это как-то типа "верхнелевосторонний" подход (термин придуман на ходу); а по аргументам - смешанный "левосторонний" (директивы) + "правосторнний" (тип); и выглядит это не красиво; и даже если Вы вставите скриншот из своей IDE (что было бы уместно) - дело это не изменит. Причём смешанный подход - не такой как я предложи - когда можно и слева и справа размещать - без разницы, а фиксированный - что-то слева, что-то справа - это ещё хуже. И так не только с аргументами; ведь, например (тут просто нет этого в Вашем примере), директиву "экспорт" Вам пришлось оставить справа (для сохранения пресловутой но почти бесполезной совместимости с классическим синтаксисом; хотя я как раз за правое размещение).

Я в комментарии написал - что тут есть свои плюсы и минусы (и даже намекнул, что считаю "правосторонний" подход более удачным и современным) - более подробно - в статье напишу (текст уже написан - нужно оформить - особенно картинки правильных отображений в IDE - там много чего я "напридумывал" и вырезал из комментария).

Кстати, левосторонний подход - больше тяготеет к синтаксису языка Си, который Вы так не любите. Впрочем, в том же Kotlin аннотации как модификаторы доступа, взятые из C++ и С# - тоже левосторонние - что лично мне не нравится - но Увы - сейчас это массовое явление в языках программирования
30. Perfolenta 204 25.02.20 19:23 Сейчас в теме
(29)
директиву "экспорт" Вам пришлось оставить справа

у меня нет полной совместимости с 1С и поэтому нет директивы Экспорт...
вместо нее применяется атрибут &ВидноВсем, слева или сверху...
справа у меня только тип...
Я не ожидаю, что вам понравится мой подход, т.к. у нас с вами слишком разные вкусы... но я пытаюсь из ваших слов полезные зерна отобрать... например, вот этот ваш пример мне нравится:
Функция МояФункция(
                                     А &Описание(“Аргумент А – бла бла бла”), 
                                     Б &URI(“help1c://Какойто_раздел”), 
                                     В &Тип(Число(10,2)), 
                                     Г &Перем, 
                                     Д &Режим(Исходящий,Ссылка) &Описание(“Сюда будет помещен результат), 
                                     Е &Где(ТипЗнч(_)=Тип(Число) И  _ > 1), //Тут всё описание контрака сгенерируется автоматически
                                     Ж &Тип(ДокументОбъкт.МойДоумент1)&Сервер&Поумолчанию(неопределено) &Описание(“Аргумент доступен только в серверном контексте – впрочем это тоже автоматически сгенерируется”),
                                     З &Контекстный(“ГруппаКонтекста”) = “Это аргумент передаётся только именовано”,
                                     К &СписокАргументов
                                    ) 
    возврат «Привет»;
КонецФункции
Показать

единственное, что тип тут как атрибут приходится объявлять, но если подумать, то может это и не плохо...
Однако, попробуйте к нему справа или снизу приписать список атрибутов самого метода и уже не так красиво получается... хочешь, не хочешь, а на компромиссы какие-то идти придется...
Я уже вряд-ли сильно поменяю свой язык, меня просто не хватит на такой подвиг... мне бы его просто доделать до рабочего варианта... а работы еще много в списке задач... я не ожидал, что сделать современный язык программирования это такой объем работы... но все же настроен довести до полной готовности... вот-вот версию 0.5 выпущу в свет...
31. Darklight 32 26.02.20 10:27 Сейчас в теме
(30)Это пример лишь часть из большого числа примеров и вариантов - всё остальное покажу в статье, когда сделаю (там есть и примеры для классов).
Поэтому тип как атрибут, в предлагаемой, мной концепции, как раз не является единственным вариантом (просто - как атрибут его можно и слева написать - это к слову, что я пропагандирую возможность двустороннего размещения атрибутов без ограничений - хоть может это и не очень хорошо - как я уже сказал - тут я сам ещё не пришёл к чёткому выбору - но правосторонее размещение мне обоснованно нравится куда больше).
А тип.... его можно и так объявить (пока я за бОльшую свободу - т.е. считаю все варианты указания типа для аргумента "В" допустимыми одновременно, но не считаю что всё-таки стоит их все допускать):
1. В &Тип(Число(10,2)),
2. &Тип(Число(10,2)) В
3. В : Тип(Число(10,2))
4. В : Число(10,2)
5. В Число(10,2) //думаю что двоеточие вообще можно опустить для типов - если они справа - а вот слева уже так нельзя (ибо может быть путаница в идентификаторах, хотя если запретить без разделителя справа - можно разрешить слева "Число(10,2) В" - но надо-ли; в общем этот вариант мне меньше всего нравится (неважно справа или слева тип без разделителя)
6. Тип(Число(10,2)):В //думаю такой вариант тоже возможен (главное - Тип() - обязательно, и написание слитно с ":" тоже)
7. В : 'Число(10,2)' //Через литерал типа
8. В 'Число(10,2)'
9. 'Число(10,2)' В //Вот тут чётко литерал типа слева не спутаешь с идентификатором
10 'Число(10,2)' : В //С двоеточием-разделителем всё тоже понятно где литерал типа, а где идентификатор аргумента
11. В тип Число(10,2)) //И Ваш вариант, в принципе, тоже возможен - вместо разделителя ":" - разделитель ключевое слово "тип", хотя, Вы знаете, что я против избытка ключевых слов - особенно там, где уже устоялись (в других языках) более короткие табулярные обозначения, к которым нет всеобщей ненависти среди программистов
12. В тип Тип(Число(10,2))) //"До кучи"
13. В тип 'Число(10,2))' //"До кучи"; а вот слева уже так тип не разместишь: "'Число(10,2))' тип В" тут уже полная околесина выходит
14. 'ДокументОбеъкт.МойДоумент1' Ж //Просто ещё один пример с типом-документом
15. Ж : Модуль1.ВложенныйМодуль1.Класс1 //Ещё один пример с типом-классом
16. Ж ОпределяемыйТип.МойТип1 //Пример с определяемым типов из дерева метаданных (ну я всё-таки про фреймворк 1С: Предприятие пишу); хотя тут "ОпределяемыйТип" может быть просто пространством имён (или модулем) - а "МойТип" - просто псевдонимом для другого типа
17. Ж тип ПланВидовХарактеристик.МойПВХ1.ТипЗначения //Я против будущего развития ПВХ, но если надо - то вот так можно с их типом связаться (я думаю; возможно окончание ".ТипЗначения" можно опустить - но я бы не стал - но это уже другой вопрос; если не пропускать - тогда, возмодно, нужно будет и так писать "ОпределяемыйТип.МойТип1.ТипЗначения" просто для унификации, хотя тут это совсем не требуется)
18. Л : Тип({Число(10,2), ДокументОбеъкт.МойДоумент1, Модуль1.ВложенныйМодуль1.Класс1}) //Составной тип? //Слабо сделать в перфоленте как в 1С? Было бы круто!
19. 'Число(10,2), ДокументОбеъкт.МойДоумент1, Модуль1.ВложенныйМодуль1.Класс1' Л
20. Тип({Число(10,2), ДокументОбеъкт.МойДоумент1, Модуль1.ВложенныйМодуль1.Класс1}):Л
21. Л тип {Число(10,2), ДокументОбеъкт.МойДоумент1, Модуль1.ВложенныйМодуль1.Класс1}

Любопытно - что даже если "тип" не будет ключевым словом - в моей идеологии варианты 12, 13, 17 21 будут возможны (идея почерпнута с Kotlin и скомбинирована с Nemerle) - как? - вот пример:
"Л Тип {Число(10,2), ДокументОбеъкт.МойДоумент1, Модуль1.ВложенныйМодуль1.Класс1}"
Он эквивалентент (почему - ниже поясню) вот такой записи:
Л : Тип ({Число(10,2), ДокументОбеъкт.МойДоумент1, Модуль1.ВложенныйМодуль1.Класс1})
В такой записи "Тип" - это макрофункция, принимающая (в одной из перегрузок) один аргумент типа - "Выражение", заданное форматом Массив типов (дженерик запись такой функции "функция Тип(Врж : Выражение<Массив,Тип>) : Тип &Макро"). Такое выражение означает, что макрофункция "Тип(Врж)" ,будет вызвана (препроцессором) когда ей на вход будет передано выражение, которое будет представлять собой линейный массив элементов типа "Тип" (по умолчанию разделитель элементов массива ",") - таковым выражением является запись "{Число(10,2), ДокументОбеъкт.МойДоумент1, Модуль1.ВложенныйМодуль1.Класс1}" - формат определяется в реализации макротипа "Выражение<ТКоллекция, ТЭлемент>" - ну суть не в этом.
Так вот эта макрофункция генерирует результат типа "Тип" - который препроцессор уже передаст компилятору вот так (через литерал-типа)
"Л : '{Число(10,2), ДокументОбеъкт.МойДоумент1, Модуль1.ВложенныйМодуль1.Класс1}'" (ну это несколько условная запись - т.к. препроцессор немного по другому , скорее всего, передаст - но суть должна быть ясна).

Теперь почему у нас "тип {}" превращается в "Тип({})" - это синтаксический сахар, если у функции (любой) последний аргумент является типом Выражение - то его можно записать не как аргумент - а как выражение справа от функции, а если в ней нет других аргументов - то и круглые скобки можно пропустить - вызов функции становится похож на вызов команды "Тип {выражение}" - это фишка из Kotlin (ну может ещё где раньше была - не знаю), просто я её усовершенствовал для любых выражений.

Ну а про пропуск ":" я уже писал слева - тут препроцессор сам догадается где идентификатор и где тип - и добавить разделитель для компилятора (у которого уже всё должно быть однозначно). То есть препроцессор тут выполняет и функции лексера.

Кстати, "Тип(Врж : Выражение<Массив,Тип>) " можно представить более продвинуто: "Тип(Врж : Массив<Тип>) "
Где у макротипа "Массив" будет специальный конструктор (имя конструктора свопадает с именем типа - это для ясности) "Массив<ТЭлемент>(Врж : Выражение<ТЭлемент>)" - который и разбирает это выражение - генерирую массив




А вот такие варианты (без разделителя типа) уже под вопросом - я бы не стал так делать
Л {Число(10,2), ДокументОбеъкт.МойДоумент1, Модуль1.ВложенныйМодуль1.Класс1}
{Число(10,2), ДокументОбеъкт.МойДоумент1, Модуль1.ВложенныйМодуль1.Класс1} Л

В общем атрибуты я пропагандирую размещать слева и справа без ограничений (хоть и считаю что их всегда нужно размещать справа), а вот типы - я всё-таки считаю лучше разрешить размещать только справа, так же я считаю, что идентификатор должен всегда быть отделён от типа (если он объявлен не через директиву), лучше через ":", а ключевое слово "тип" я считаю лишним - просто потому что большинство уже привыкли к ":" (ну тут я могу лукавить конечно), и само двоеточие ещё можно много где задействовать в схемах со схожей семантикой "привязки ограничения или уточнения/определения/формата" (да хоть вот так сообщить($"Значение переменной {В:Число(10)} отформатировано = {В:формат(ЧЦ=10; ЧДЦ=0; ЧРГ=' '; ЧГ=)" //думаю слово "формат" тут вообще можно опустить - но суть не в нём). Или, например, при наследовании, привязки реализации интерфейсов: "Класс МойКласс : КлассПредок, Интерфейс1, Интерфейс2 {тело класса}" - формально здесь тот же смысл, что и при объявленнии типа переменной (аргумента, возвращаемого значения функции или чего-либо ещё): вводится идентификатор "МойКласс" вида "Класс", определяемый как имеющий структуру (тип) "КлассПредок" и требующий наличия структуры контрактов (интерфейсов) "Интерфейс1" и "Интерфейс2" (ну а в теле определения класса добавляются собственные члены данного определяемого объекта, который сам станет типом; а Вам для этого пришлось ввести новое ключевое слово "Родитель"

Класс МойКласс Родитель КлассПредок 
    //....
КонецКласса


Правда при работе с классами без него обойтись правда тяжеловато будет - оно нужно будет уже в теле класса - для однозначного обращения к членам класса-родителя.
Про реализацию классами интерфейсов я, что-то, не нашёл как у Вас сделано в Перфоленте.

И да, когда я ранее думал о классах в 1С - я точно так же думал определять наследование как и Вы - если стараться сделать расширенный синтаксис языка максимально более близким к стилю классического 1С.
Но, позже - всё-таки стал склоняться к иному стилю - более далёкому от стиля 1С - и более близкому, к Kotlin и C# (и немного Ruby, Scala, Nemerle) - но без многих элементов старого наследия языка Си и C++ которые мне совсем не нравятся. Привнося и свои идеи тоже. У меня даже несколько незаконченных (и не опубликованных) статей на эту тему есть. Как-нибудь закончу и опубликую
32. Perfolenta 204 26.02.20 12:27 Сейчас в теме
(31) по типу вы рассмотрели 21 вариант, представьте объем моих мучений по каждому аспекту языка :)
то что получилось в конце, оказалось совсем не таким, как первый вариант, с которого я начинал...
и эти мучения продолжаются... вы сказали, что не увидели как реализованы интерфейсы... а все потому, что я сейчас третий вариант работы с интерфейсами реализую... и надо сказать, что он снова компромиссный и не во всем мне нравится...

Составной тип? //Слабо сделать в перфоленте как в 1С? Было бы круто!

теоретически сделать можно, но это будет не совместимо с Net, чего не хочется допускать... хотя, с оговоркой только о внутреннем использовании, наверное можно...

В общем атрибуты я пропагандирую размещать слева и справа без ограничений (хоть и считаю что их всегда нужно размещать справа), а вот типы - я всё-таки считаю лучше разрешить размещать только справа

я вписался в эти ограничения :) атрибуты слева, тип справа...

так же я считаю, что идентификатор должен всегда быть отделён от типа (если он объявлен не через директиву), лучше через ":", а ключевое слово "тип" я считаю лишним - просто потому что большинство уже привыкли к ":" (ну тут я могу лукавить конечно)

тут есть одна проблемка... те кто привыкли к : вряд-ли пойдут на русский язык программирования... они уже прочно застряли в англоязычном программировании... а слово тип пишется и читается очень естественно... я же не только делаю язык, я еще и пишу на нем... слово тип ни когда не раздражало меня при наборе или чтении текста... я обычно так и меняю язык, когда при написании программы что-то начинает раздражать или казаться неудобным, тогда и переделываю синтаксис...
33. Darklight 32 26.02.20 14:05 Сейчас в теме
(32)
по типу вы рассмотрели 21 вариант, представьте объем моих мучений по каждому аспекту языка :)

Я не просто рассмотрел, я написал, что их все можно допустить одновременно (хоть и с оговоркой что не считаю что все их нужно реализовывать в языке). Например, не вижу смысла (т.е удобства) писать типы слева, но со мной явно далеко не все согласятся, даже если я приведу кучу доводов против левостороннего размещения и контраргументов за правостороннее - но тут всё тоже самое что с директивами - а Вы, вот, за левостороннее размещение директив. А 21 вариант получился (на самом деле ещё больше - т.к. я не стал приводить варианты где тип задан строкой как в 1С; а так же варианты с типизацией через директивы, принадлежащие владельцу (в данном случае - функции)) - просто потому что тема типизации одна из самых ёмких на варианты - с другими аспектами синтаксиса всё как-то по-проще.

теоретически сделать можно, но это будет не совместимо с Net, чего не хочется допускать... хотя, с оговоркой только о внутреннем использовании, наверное можно...

Что-то я не вижу больших проблем с совместимостью. Что Вы тут под "Net" вообще понимаете? Вон, в .NET CLS нет, например, понятия нуллабельных типов - но это не помешало их добавить в C# - причём с разной реализацией для стековых (типов значений) и для ссылочных (классов) типов! Причём для ссылочных - это чисто языковая фишка - за пределами C# никак не выделяющаяся (и формально создающая небольшую проблему интеграции библиотек, даже созданных на C#) - Хотя при рефлексии такого типа спец атрибут в IL код всё-таки помещается - значит и другие языки тоже могут на него опереться и поддерживать нуллабельность.
Аналогично с кортежами - тоже чисто языковая фишка.
Да и свойства классов c геттерами и сеттерами тоже отсутствуют в .NET CLS
Вот про дженерик типы только не помню есть ли они с .NET CLS или это тоже - эмуляция.

И, мне кажется, "cишные" юнионы в .NET CLS (или всё же в CLR, потому что в CTS их как раз нет, но в целом IL код их позволяет вводить, а runtime-движок использовать) как раз не запрещены. Нужно только языковую обёртку сделать. И хоть какие-то (не прямые, но определённые в .NET CLS) средства работы с такими типами из других языков. Впрочем, сделать можно и без юнионов (хотя unsafe code union структуры можно вроде бы даже в C# определять - хоть и криво).
А ещё, в C# же есть динамические типы переменные (но не поля/свойства) - чисто языковая фишка. Разве что не производительная при работе со стековыми типами. Но ведь в составных типах бывает нужда явно не из-за желания получить высокую производительность - да и скастить их в конкретный стековый тип ведь не проблема - и далее уже работать с максимальной производительностью стековых типов.


я вписался в эти ограничения :) атрибуты слева, тип справа...

Имхо - "ни рыба, ни мясо" - и идентификаторы вправо уезжают, и типы всё-равно не всегда будет видно без скроллинга. Причём на мой взгляд - типы видеть важнее, чем директивы (поэтому когда я пишу директивы справа я определение типа размещаю справа, но левее директив - но тогда директивы получается относятся к этому определению привязки типа - но это решается проталкиванием директив к ближайшему допустимому ими владельцу при препроцессинге).

тут есть одна проблемка... те кто привыкли к : вряд-ли пойдут на русский язык программирования... они уже прочно застряли в англоязычном программировании... а слово тип пишется и читается очень естественно... я же не только делаю язык, я еще и пишу на нем... слово тип ни когда не раздражало меня при наборе или чтении текста... я обычно так и меняю язык, когда при написании программы что-то начинает раздражать или казаться неудобным, тогда и переделываю синтаксис...

Обратная проблемка - а зачем выбирающим язык - вообще выбирать Ваш? Сейчас как раз в этом и вся фишка - джуны выбирают язык для изучения с перспективой в дальнейшем устроиться на высокооплачиваемую работу (и чаще всего это работа за границей или для заграничных заказчиков). Там русский язык никому не нужен - он будет лишь помехой. Увы - мировой стандарт общения сейчас английский - а в программировании - это не просто стандарт - это фактически 100% охват. Даже китайцы с индусами пишу код внутренних программ (и часто комментарии) на английском - а это уже больше половины всех программистов в мире - а для них - это не родной язык.

Ну допустим, язык с русским текстом можно рассмотреть как учебный для..... скажем младших школьников (потому что старшие уже выучат основы английского языка и им важнее закреплять владение техническим английским через программирование).
Но тут опять же дилемма - школьники сначала будут привыкать к одним правилам форматирования семантических конструкций - а потом придётся привыкать к другим - ну может это не так уж и критично (ибо неизбежно - при переходе на другие языки), но так ли часто в странах СНГ фигурирует вариант где для отделения идентификатора от типа используется ключевое слово? Только в VB.NET ("Dim MyVar As Integer") - но VB.NET не так уж популярен за пределами США, тем более в СНГ.
А вот, чтобы у языка была коммерческая привлекательность - в нём должны быть какие-то хитры фишки - которые смогли бы ярко выделить его на фоне других. А то так и останется язык - чисто академическим (ну как максимум даже). Вон Nemerle - таковым и остался (несмотря на фишки). А Scala - ели ели пробился в коммерческую нишу - и занял там небольшую долю. А вот, Python - пример, где нешибко навороченный язык, без подержки крутых компаний сумел подняться почти на вершину популярности! Иут всё не однозначно... Причём для изучения детям по Python даже книжки прикольные есть!

Теперь о выборе ключевого слова. "Тип" уж очень конкретизирующий выбор (хоть и поначалу кажущийся очевидно удачным) - иб слово сразу становится узко связанным с контекстом - в отличии, скажем, от "As" - "Как" - которое может применяться в очень широком смысле - да хоть для приведения типа: "перем Пер2 = Пер1 как Целое" - кажется так у Вас в Перфоленте кастинг задаётся. Но вот - уже два лишних ключевых слова. А захотите форматирование при выводе строки сделать - что ещё третье ключевое слово введём? А захотите ввести псевдоним типа - ещё ключевые слова понадобятся? А для определения инициализации массива сразу значениями - ещё ключевые слова. А для быстрой инициализации полей объекта класса - ещё?

Как Вы поняли - вообще против большого числа ключевых слов. Считаю, что они усложняют синтаксис языка - делают его менее универсальным и мене лаконичным (но я, всё-таки, за то, чтобы во всём знать меру - а не так как в Си - где действительно ключевых слов не так уж много (особенно если не считать встроенные в ядро функции за ключевые слова), впрочем там синтаксис действительно не очень сложный и не перегруженный - в отличии от C++).

Ну а минимизацию ключевых слов я компенсирую широким применением директив (они же атрибуты, декораторы и аннотации). Результат тот же - а реализация другая - если ключевые слова - это скорее команды компилятору - выполнить действие и/или задать контекст выполнения синтаксического разбора. То директивы - это лишь метки - свойства, которые присоединяются к инструкциям как маркеры (в т.ч. параметризованные) - просто носители данных - которые включаются в метаданные программы, а так же которые могут быть учтены при обработки инструкций (с которыми они связаны) препроцессором, компилятором и линкером (ну и очень гибко учтены самой IDE, а в некоторых случаях учтены и средой выполнения).

Причём программист может ввести свои директивы - они будут так же помещены в метаданные. А кроме того - могут быть обработаны макросами при препроцессинге, и даже компилятором - если к нему будут подключены соответствующие расширения - т.е. тут получается полная свобода к расширению всего процесса сборки приложения. Ну и в runtime такие программисткие директивы тоже могут быть проанализированы через рефлексию метаданных - и оказать влияние на работу алгоритмов. Причём при препроцессинге состав директив обрабатываемых выражений может произвольно меняться (и этим могут управлять макросы, да и компилятор тоже может добавить доп. директивы). А вот фиксированные ключевые слова такой свободы уже не дадут. Причём я упрощаю и сами метеоданные - когда у объекта метаданных уменьшается число видов связанных с ним меток - только до директив (по сути они вообще могут определять в метаданных всё, кроме основного идентификатора и вложенных членов: и допустимые типы значения, и родителя, и контракты (интерфейсы, ограничения), и модификаторы доступа, и синонимы, и акторы, и т.п.

Более того, в некоторых случаях - я "подменяю" ключевые слова - на вызовы макрофункций - как было мной показано в предыдущем комментарии - выглядит очень изящно. И да - программист тут тоже вправе вводить свои макрофункции - ограниченно расширяя синтаксис языка - если ему будет угодно (и как мне кажется - не превращая код в абстрактную околесицу - тут далеко до жуткой гибкости шаблонов С++ с кучей непонятных ошибок при компиляции; макрофункции - это достаточно жёсткий в применении инструмент - берущий истоки из возможностей языка Nemerle; жЁсткий, но НЕ жестОкий).
34. Perfolenta 204 26.02.20 15:19 Сейчас в теме
(33)
я написал, что их все можно допустить одновременно (хоть и с оговоркой что не считаю что нужно

так в этом и проблема... допустить все варианты не реально, а выбрать конкретные трудно, т.к. каждый имеет достоинства и недостатки...

тема типизации одна из самых ёмких на варианты - с другими аспектами синтаксиса всё как-то по-проще

с каждым конкретным аспектом может и проще, но если учесть их количество.... испытал на своей шкуре... :)

"ни рыба, ни мясо" - и идентификаторы в право уезжают, и типы всё-равно не всегда будет видно без скроллинга. Причём на мой взгляд - типы видеть важнее, чем директивы.

да, к сожалению, продукт компромисса... но все же сказать "Переменная А тип Целое" естественнее, чем "тип Целое Переменная А"... поэтому тип справа... а вот Видно всем, т.е. атрибуты, точно могли бы быть и справа... "Переменная А тип Целое ВидноВсем" - нормально звучит... я выбрал слева только потому, что у всех языков-прототипов атрибуты слева... не захотел ломать шаблон... это ведь тоже важно, люди ожидают, что будет слева...

а зачем выбирающим язык - вообще выбирать Ваш?

это верный вопрос... но если его взять в расчет, то ни каких новых языков делать не стоит... уже есть все, на любой вкус... но это как мода на обувь, хочется нового, а в реальности по кругу, острые носки, круглые носки, загнутые носки, квадратные носки и снова острые...
Я рассчитываю на новичков, которым будет легко изучить все основные понятия и программировать прямо в изученных терминах....
прочитал в книге слово Класс и пишешь Класс...
и на программистов 1С, задачи которых иногда выходят за рамки платформы... прикинув, они должны выбрать более знакомый язык, или Односкрипт или Перфоленту в зависимости от задачи...

Причём программист может ввести свои директивы - они будут так же помещены в метаданные.

все это уже есть в Перфоленте... т.к. есть в Net... атрибуты и рефлексия поддерживаются...

Вон, в .NET CLS нет, например, понятия нуллабельных типов

зато они есть в Net Framework, а значит почти во всех Net языках они доступны... то же самое с кортежами, со свойствами и т.д...
А вот составного типа нет... как он должен быть устроен еще думать надо... то ли это какая-то коллекция типов должна быть, то ли еще как... не знаю... но этот тип надо будет в Runtime поддерживать... самый простой вариант это сделать класс СоставнойТип в стандартной библиотеке, но это примитивное решение со многими недостатками... вот если бы его как-то от типа Type унаследовать, но тут надо голову ломать, как это сделать...

А захотите форматирование при выводе строки сделать - что ещё третье ключевое слово введём? А захотите ввести пвесвдоним типа - ещё ключевые слова понадобятся? А для определения инициализации массива сразу значениями - ещё ключевые слова. А для быстрой инициализации полей объекта класса - ещё?

вы абсолютно правы... каждый раз страдаю и долго думаю, прежде чем ввести новое ключевое слово... иногда выкручиваюсь без него, а иногда не могу...
однако, любой язык потому и язык, что у него есть хотя бы базовый словарь... и не факт, что маленький словарь лучше большого... лучше тот, который выразительнее описывает то, что должен описывать...
в языках программирования распространено создание новых слов - идентификаторов, но это каждый раз, в каждой новой программе, свой язык... иногда лучше иметь больше слов в базовом словаре, чем каждый раз изучать новый язык... (из-за этого и макросы не особо любимы)... библиотеки популярны не только из-за функционала, но и в большой мере из-за стандартизованного расширения языка... если у вашего языка изначально большой словарь, возможно понадобится меньше библиотечных расширений...
всякая палка о двух концах...
35. Darklight 32 26.02.20 17:00 Сейчас в теме
(34)
так в этом и проблема... допустить все варианты не реально, а выбрать конкретные трудно, т.к. каждый имеет достоинства и недостатки...

Вот поэтому я пропагандирую гибкость - когда можно допустить максимум - но при этом дать настоятельные рекомендации по использованию - чтобы чётко программисты понимали плюсы/минусы тех или иных форм реализации своих мыслей.
Ну и, я, как сторонник правостороннего размещения - ещё бы настаивал на приоритетном применении именного правостороннего варианта (не запрещая левостороннее, хотя в некоторых случаях - всё же рекомендовал - верхнелевостороннее - например для директив функций/классов - но это не обязательно), и именно его применял бы в офф. документации. Ну а IDE настраивал по умолчанию так - чтобы в ней с правосторонним размещением было работать удобнее с левосторонним (в классических редакторах) - но не вставлял бы палки для желающих работать с левосторонним (и по возможности делал и для них бы тоже настройки - упрощающие такую работу) - подробности в отдельной статье напишу.

да, к сожалению, продукт компромисса...

Поэтому у меня тут всё справа - ибо, например, идентификаторы аргументов для меня важнее их типов и директив (хотя сишника кажется типы важнее - вон в докмуентации по Си часто и идентификаторы аргументов вообще отсутствую в заголовке функции - вот чёрт голову сломит пока разберёшься за что отвечают эти функции и что в их сиогнатурные типы подавать надо).

но все же сказать "Переменная А тип Целое" естественнее, чем "тип Целое Переменная А"

Кстати, в классическом Си (да часто в С++) было принято определять не только тип переменной перед идентификатором переменной, но описание типа - перед именем типа (обычно для структурных типов, но это не обязательно)

typedef struct 
{
    int a,b;
} MYRECORD; //Псевдоним структурного типа

MYRECORD record; //Объявили переменную типа MYRECORD 



ИМХО - выглядит ужасно - так куда лучше:

struct MYRECORD; //Шаблон структурного типа
{
    int a,b;
} 

MYRECORD record; //Объявили переменную типа MYRECORD 


Вот поэтому я считаю, что идентификаторы должны быть всегда в начале - а все детали их определения - уже следовать за ними, включая типы - как в Pascal (нет, даже object pascal не эталон - ибо там какие-то директивы пишутся слева - какие-то справа - хаос):

TMyClassDescendant = class(TMyClass)
    private class procedure MyVirtualMethod(const Color: Graphics.TColor); override;
  end;


А хотелось бы так (в терминах Object Pascal):

TMyClassDescendant = class(TMyClass)
    procedure MyVirtualMethod(Color: Graphics.TColor const); override; private; class; //Хотя ";" тут явно лишние
  end;


я выбрал слева только потому, что у всех языков-прототипов атрибуты слева... не захотел ломать шаблон... это ведь тоже важно, люди ожидают, что будет слева...

Вот тут да - не поспоришь. Увы - это настолько уже прижилось - что изменить это будет очень сложно. Поэтому я за оба варианта реализации в языке - но всё-равно пропагандирую правостороннее - может, при правильной подаче и резонансе нового языка - оно и перещёлкнет этот устоявшийся "недостаток" в мозгах хотя бы нового поколения программистов! Ведь - всё-таки не все языки следуют идиологии Си - где тип указывается слева от идентификатора (впрочем так было ещё и до Си - это очень древняя форма указания типа - как и отделение его двоеточием).
Я в статье - напишу - почему же я так сильно настаиваю на правостороннем декларировании, и как это всё можно очень красиво обыграть в IDE!

это верный вопрос... но если его взять в расчет, то ни каких новых языков делать не стоит... уже есть все, на любой вкус...

Неправда - я смело утверждаю - всё что есть - всё дерьмо - которое морально устареет за полвека (правда Си и С++ уже долго держатся - но С++ правда активно развивается - правда часто не в лучшую сторону, а Си - скорее держится за счёт популярности C++ и простоты реализации компилятора - для специфического оборудования)! Но C++ уже давно потерял пальму первенства. А среди системных языков сейчас появляются куда более интересные языки, ещё более мощные и куда более надёжные как С++ без заметного проседания производительности - например Rust (хотя язык тоже очень сложный в освоении - но куда более статически предсказуемый чем С++).

зато они есть в Net Framework, а значит почти во всех Net языках они доступны... то же самое с кортежами, со свойствами и т.д...

Опять вопрос - а что такое "Net Framework"? - в целом это просто набор проприетарных windows библиотек (в первую очередь заточенных именно под C# - хоть и доступных на других языках платформы windows)! да к тому же - уже отмирающий!
И опять-таки, Вы бы просто посмотрели рефлектором во что превращается код С# с указанными мной сущностями - поймёте - что это чисто языковые фишки - за которыми стоят вполне себе классические обёртки. Практически - синтаксический сахар.
И нет проблемы аналогично обернуть составные типы - кстати - обратите внимание на Scala - там есть подобие оных - и Scala - умеет компилироваться в IL и подключать .NET библиотеки (правда там какие-то ограничения есть - давно не изучал вопрос).

вариант это сделать класс СоставнойТип

Посмотрите (рефлектором), всё-таки, для начала как на C# имулируются "сишные" юнионы, пускай и в unsafe code.
Ну а в IL - так вообще полная свобода представления - не так важно - во что оно компилируется - важно как это выглядит внутри языка. ну да - при интеграции с другими языками тут будут проблемы - нужны просто обходные пути.

На крайняк - в ".NET CTS" есть тип "System.Object" - он универсален для всех ссылочных типов - а ".NET CLR" поддерживает боксинг для типов-значений.

Останется лишь обернуть это в что-то типа:

[StructuredType]
class Structured 
{
      private System.Collections.List<System.Type> _Types; //Примитивная реализация
      private System.Object? _value;
      public System.Type Type() => _value != null ? typeof(_value ) : UndefinedType  //UndefinedType - специальный тип для "неопределено"
      public T GetValue<T>() => (T)_vlaue; //ну тут ещё проверку на тип надо добавить
      public void SetValue<T>(T Value) {_value = value} //ну тут ещё проверку на тип надо добавить
      //Для некоторых примитивных типов тут ещё ограничения на формат (квалификаторы) добавить нужно
}
Показать


переменные этого можно ещё специальным атрибутом оборачивать (с перечислением всем поддерживаемых типов).
естественно - это только внутренняя реализация - а внутри языка Перфолента - тип должен быть представлен несколько иначе - по-сути - тут надо генерировать ещё и интерфейс - который будет включать в себя доступ ко всем членам составного типа (с контролем типа и переадресацией вызова к _value с оотвествующим кастингом). Ну а для реализации - генерировать ещё один класс (на базе приведённого выше) - реализующий этот интерфейс - тогда будет выглядеть как в 1С - все члены будут обобщённо доступны - в IDE - но в runtime несовместимые вызовы будут генерировать исключения. Впрочем с C# 8 отдельный наследуемый класс для реализации интерфейса уже не обязателен - т.к. сам интерфейс может включать в себя всю реализацию - но каждый составной тип всё равно придётся наследовать от базового класса и подключать к нему нужный интерфейс.

если у вашего языка изначально большой словарь, возможно понадобится меньше библиотечных расширений...

Мне кажется - сейчас в современных языках иная тенденция - упрощение синтаксиса языка - и расширение того, что можно сделать библиотеками! Примеры: Python, Kotlin, Go, JavaScript да даже С++ во многом на библиотеки операется - хотя синтаксическая база ключевых слов у него не малая накопилась за годы улучшений.
Макросы хороши - когда их правильно в язык вводят и не злоупотребляют! И не надо их путать с шаблонами С++ - они ужасны!
А большой словарь - это скорее отталкивающий фактор, чем притегательный - изучать его сложнее! Ошибаться с ним, как ни странно, легче!

иногда лучше иметь больше слов в базовом словаре, чем каждый раз изучать новый язык...

если так ставится вопрос - значит у языка просто плохо проработана семантическая модель - и авторы не хотя её дорабатывать - значит язык почти мёртв!
36. Darklight 32 26.02.20 18:11 Сейчас в теме
(35)Добавка-исправление к примеру реализации составному типу на языке C#

class TypeUndefined 
    {
        private static TypeUndefined _undefined = new TypeUndefined();
        public static TypeUndefined Undefined => _undefined;
    };

    class Global
    {
        public static System.Type UndefinedType = typeof(TypeUndefined);
        public static TypeUndefined  Undefined => TypeUndefined.Undefined;
    }

    class Structured
    {
        protected System.Collections.Generic.List<System.Type> _Types; //Примитивная реализация списка допустимых типов составного типа (пока в примере не используется)
        protected System.Object? _value;
        public System.Type Type() => _value != null ? _value.GetType() : Global.UndefinedType;  //UndefinedType - специальный тип для "неопределено"
public virtual T Cast<T>(out bool Ok) { Ok = true; return (T)(object)Global.Undefined; } //Кастинг или возврат хранящегося типа к заданному - если не возможно - флаг Ok=false
        public virtual System.Object Convert<T>(T val, out bool Ok) { Ok = true; return _value; } //Кастинг заданного значения к допустимому составному типу и возврат результата - если не возможно возвращает Global.Undefined и флаг Ok=false
        public T GetValue<T>() => (T)_value; //ну тут ещё проверку на тип надо добавить и допустимый кастинг типа
        public bool SetValue<T>(T Value) { _value = Value; return true; } //ну тут ещё проверку на тип надо добавить
                                                           //Для некоторых примитивных типов тут ещё ограничения на формат (квалификаторы) добавить нужно
    }

    interface IMyStructeredType
    {
        public T GetValue<T>();
        public bool SetValue<T>(T Value);
        public System.Int16 AsInt16 => GetValue<System.Int16>();
        public System.String AsString => GetValue<System.String>();
        public bool SetValue(System.Int16 val) => SetValue<System.Int16>(val);
        public bool SetValue(System.String val) => SetValue<System.String>(val);

      public bool TryFormat(Span<char> destination, out int charsWritten, ReadOnlySpan<char> format = default, IFormatProvider? provider = null) 
       => AsInt16.TryFormat(destination, out charsWritten, format, provider); //Член Int16, тут не хватает проверки на реальный тип, и генерации исключения, когда тип не совместим и приведение не возможно

      //другие члены "структуры"  Int16

      public String Trim() => AsString.Trim(); //Член String, тут не хватает проверки на реальный тип, и генерации исключения, когда тип не совместим и приведение не возможно
      //другие члены "класса"  Strting
    }

class MyStructeredType : Structured, IMyStructeredType
    {
        public MyStructeredType(System.String val) : base() => SetValue<System.String>(val);
        public MyStructeredType(System.Int16 val) : base() => SetValue<System.Int16>(val);
        public static implicit operator System.Int16(MyStructeredType val) => ((IMyStructeredType)val).AsInt16;
        public static implicit operator System.String(MyStructeredType val) => ((IMyStructeredType)val).AsString;
        public static implicit operator MyStructeredType(System.Int16 val) => new MyStructeredType(val);
        public static implicit operator MyStructeredType(System.String val) => new MyStructeredType(val);

        //навереное надо явно реализовать и методы типов из интерфейса
    }


        void test()
        {
            MyStructeredType sti = 10;
            System.String sts = sti;
        }
Показать
38. Perfolenta 204 27.02.20 02:12 Сейчас в теме
(36) да, где-то так я и сам это видел...
у меня в стандартной библиотеке Перфоленты до сих пор еще болтается тип УниТип, который был как раз для этих целей создан, но потом я от него всю библиотеку вычистил в пользу обычного типа Объект...
Во-первых, работает быстрее, во-вторых, было много нюансов с использованием такого типа в языке, в конструкторах, в неявных преобразованиях и т.д., которые в конце концов привели к отказу от него...
стандартный объект языка 1С ОписаниеТипов у меня в стандартной библиотеке тоже есть и местами используется для совместимости...
но в целом, мне этот путь не по душе...
скорее всего, переименую свой УниТип в СоставнойТип и слегка допилю функционал, чем и ограничусь...
39. Darklight 32 27.02.20 09:39 Сейчас в теме
(38)Ну так оставляйте "System.Object" (хотя по хорошему - нужно больше стараться использовать дженерик типы - вот тогда уж точно будет быстрее: при работе с типами значений - очень даже заметно быстрее). Суть то не в этом - ведь "MyStructeredType" - это же наследник от "System.Object" - значит с ним совместим. Такой класс должен применяться только когда в языке используется составной тип! Объявление составного типа в языке тут же должно привести к статической типогенерации (ну если объявление статическое, динамическое создание составного типа - соответственно, динамическая типогенерация; в примере выше класс "MyStructeredType" и интерфейс "IMyStructeredType" генерируются компилятором для при объявлении составного типа а-ка "Тип({Целое16,Строка})") и в итоговый IL код просто вставляется использование сгенерированного типа. И далее он просто передаётся туда, где принимается "System.Object". Никаких проблем. Такой класс, по сути, нужен только для обёртки составных типов для интеграции с другими библиотеками.

Внутри одной библиотеки (да и нескольких - если они на Перфоленте) - всё можно сделать в IL куда проще - без обёрток. Но раз нужна интеграция - придётся оборачивать то, что не поддерживается в других языках. Аналогично в C# c нулабельными типами значений и с кортежами, и с динамическими типами - не все другие .NET языки это поддерживают (по крайней мере не сразу) - и там эти объекты доступны только через обёртки. А вот, например, именованные поля в кортежах, доступные в С# вообще вроде бы только в C# поддерживаются - и из других языков так с ними вообще нельзя работать до сих пор (только через рефлексию).

Тут всем не угодишь - тут главное, чтоб была хоть какая-то интеграция, ну и в своём языке всё было "чики-пики".
41. Perfolenta 204 27.02.20 11:38 Сейчас в теме
(39)
хотя по хорошему - нужно больше стараться использовать дженерик типы

да, я уже создал в стандартной библиотеке коллекции похожие на коллекции 1С, но обобщенного типа: Массив<Т>, Множество<Т>, Очередь<Т>, ПриоритетнаяОчередь<ТКлюч, ТЗначение>, Соответствие<ТКлюч, ТЗначение>, Стек<Т>, Структура<Строка, ТЗначение>... в дополнение к обычным... причем часть из этих коллекций сделал потокобезопасной...

А вот, например, именованные поля в кортежах, доступные в С# вообще вроде бы только в C# поддерживаются

в VB тоже поддерживаются, но немного по своему... я в Перфоленте пока не сделал... отложил на потом...

Объявление составного типа в языке тут же должно привести к статической типогенерации

тут есть проблема... у C# и VB в Net Framework есть поддержка, встроенные Compiler Services.. а у Перфоленты естественно нет... сейчас компилятор Перфоленты ни как не связан со стандартной библиотекой Перфоленты и может использоваться без неё... пока не хочется их привязывать друг к другу... у меня даже встроенные функции языка на лету генерируются без использования стандартной библиотеки... часть из них инлайном вставляется, а часть в виде отдельных функций реализована... компилятор вставляет в ЕХЕ только те функции, которые использованы в программе...
А вот с типом такой трюк не прокатит, т.к. тогда этот тип нельзя будет использовать из написанных на перфоленте библиотек... короче, есть над чем подумать... возможно, сам компилятор тоже стоит сделать библиотекой, на которую можно ссылаться при использовании классов определенных в нем... это будет простой выход из положения, хотя обычно так не делают...
43. Darklight 32 27.02.20 16:58 Сейчас в теме
(41)
тут есть проблема...

Простите, я в компиляторах не особо шарю, язык IL тоже не знаю. Поэтому проблему не понимаю. Просто представлю - что если при компиляции введено выражение - определяющее составной тип - то в IL код надо вставить инструкции, определяющие тип, эквивалентный чему-то похожему на вышеприведённый тип класса "MyStructeredType" (имя соотвественно будет автогенерируемое) и интерфейс (вроде бы просто абстрактный класс в IL), . А там где на он будет использоваться - вставить указание на этот класс, и использовать его методы (в т.ч. через интерфейс). Ну ей богу - не понимаю в чём загвоздка.

У меня в одном проекте тоже есть генерация типов классов (причём на основе рефлексии динамических библиотек - где дано просто описание нужных сущностей, причём по сути не важно на каком языке (это может быть и Перфолента) - главное - это унифицированные метаданные .NET) - просто я не компилирую их сразу в IL - я генерирую текст на языке C# (через шаблоны VS T4 - вся рефлексия внутри алгоритмов шаблонов) - а дальше уже компилирую классическим компилятором в dll и подключаю их к проекту. Пока это всё идёт как единая сборка решения в VS - в будущем - это будет просто приложение - компоновщик dll компонент из нескольких источников, которые комбинируются вместе. И все эти сгенерированные типы должны будут использоваться в программе - куда эта компонента будет подключаться (на данный момент - это для контекста OneScript делается).

Аналогично Вы - можете генерировать типы - в отдельную библиотеку - а потом линковать её к основному проекту.
46. Perfolenta 204 27.02.20 19:34 Сейчас в теме
(43)
Аналогично Вы - можете генерировать типы - в отдельную библиотеку - а потом линковать её к основному проекту.

тогда уже можно прямо в выходную сборку запихнуть... зачем отдельную делать...
я о другом, допустим у меня в двух разных программах определен тип Тип({Целое, Строка, Документ.Счет})
фактически это будут два разных типа... в каждой программе свой.. а вот если бы они на одну библиотеку ссылались, то было бы хорошо... но тогда мне надо эту библиотеку делать обязательной, или не будет составных типов...
конечно и так можно, я просто еще не решил как лучше...

(на данный момент - это для контекста OneScript делается)

это очень интересно... если будет доступен исходник, то обязательно посмотрю... может попытаюсь на Перфоленте переписать... мне на данном этапе это полезно... когда переписываю с других языков вижу недостатки в своем и исправляю их...
49. Darklight 32 28.02.20 17:23 Сейчас в теме
(46)
я о другом, допустим у меня в двух разных программах определен тип Тип({Целое, Строка, Документ.Счет})

Ну я почти Вас понял, ну почти...
Всё равно не понимаю в чём трабла. За пределами Перфоленты - да будут неудобства. А внутри Перфоленты всё будет скрыто от пользователя (думаю компилятор разберётся, что это одинаковые типы (хотя бы по метаданным) и сделает приведение типов - когда один в другой будут присваивать).
Если это разные программы - то и фиг с ними с разными сгенерированными типами.
Если это библиотеки - в которых независимо объявили формально одинаковые типы - ну и что?

Добавляем конструктры в базовый класс

class Structured
    {
        public Structured() { }
        public Structured(Structured From)
        {
            _Types.AddRange(From._Types);
            _value = From._value;
        }

...

}
Показать


Так как C# не наследует конструкторы - дублируем их в производном классе (это заиморочки C# с IL генерацией будет проще):

 class MyStructeredType : Structured, IMyStructeredType
    {
        public IMyStructeredType Self => this;

        public MyStructeredType() : base() { }
        public MyStructeredType(Structured From) : base(From) { }

...

}
Показать


Всё - могу легко копировать один одно значение в другое (ну тут ещё сравнения всякие надо сделать - но это уже отдельная тема - понаследовать некоторые относительно важные сервисные встроенные интерфейсы):

MyStructeredType a1 = 1;
MyStructeredType2 a2 = new MyStructeredType2(a1);

Увы, в C# нельзя сделать перегрузку приведения типа с типа базового класса.
50. Darklight 32 28.02.20 17:24 Сейчас в теме
(46)Другое дело - что это в 1С в динамических переменных одно значение просто копируется в другую переменную как есть. А если приёмником будет реквизит фиксированного составного типа - то его типы не обновляются - а значение присвоится только если его можно принять - ну дабавим ещё пару методов в исходный класс:

class Structured
    {

      ...

   public bool SetValue<T>(T Value) { _value = Value; return true; } //ну тут ещё проверку на тип надо добавить
                                                                          //Для некоторых примитивных типов тут ещё ограничения на формат (квалификаторы) добавить нужно       
        public System.Object GetValue() => _value ?? Global.Undefined;
        public bool SetValue(System.Object val)
        {
            var type = val.GetType();
            if (!_Types.Contains(type)) //Тут нужна более сложная логика кастинга типа
                return false;

            _value = val;
            return true;
        }
    }     
Показать


В с генерируемом сделаем вот такую перегрузку оператора

class MyStructeredType : Structured, IMyStructeredType
    {
        public static MyStructeredType operator ^(MyStructeredType Acceptor, Structured Source) => Acceptor.SetValue(Source.GetValue()) ? Acceptor : Acceptor;

    }


Теперь могу присваивать значение с контролем типа у приёмника:

MyStructeredType a1 = "";
MyStructeredType2 a2 = 1;

MyStructeredType a1 ^= a2; //Ну только базовый класс нужно расширить, чтобы число конвертировалось в строку.

Вся логика в базовом классе - всё остальное - синтаксический сахар. В самой Перфоленте всё можно сделать прозрачным. А при интеграции с другими языками - да - понадобятся обёртки в возможности этих языков.


Фуф - удалось разместить пост после разбиения на два сообщения!
52. Perfolenta 204 28.02.20 20:12 Сейчас в теме
(50)
Другое дело - что это в 1С

вы правы, в 1С, в самом языке, составных типов не существует... они только на уровне свойств прикладных объектов существуют...
т.е. там скорее всего просто в методе присваивания значения свойству тип проверяется и всё...
Ничто не мешает разработчикам на Перфоленте в своих классах делать так же...
Сейчас решил, что пока не буду делать составной тип, просто доработаю имеющийся в моей стандартной библиотеке класс УниТип (универсальный тип), что бы ему можно было ограничения типа при присваивании задавать... думаю этого достаточно будет, если кому-то понадобится...
Конечно, это не так круто, как мы с вами обсуждали... я себе в конец списка задач записал примерный план создания типа с ограничением присваивания.. но с низким приоритетом... когда-нибудь сделаю...
В реальности это будет просто тип Объект (со спец. синтаксисом написания), для которого компилятор будет проверять возможность присваивания на этапе компиляции.... без поддержки во время выполнения...
тогда и с внешним миром проблем не будет, за исключением того, что внешний мир сможет любое значение присвоить... а внутри программы можно будет только заданные типы присвоить...
37. Perfolenta 204 27.02.20 01:50 Сейчас в теме
(35)
Неправда - я смело утверждаю - всё что есть - всё дерьмо - которое морально устареет за полвека

я с вами согласен, но я уже точно знаю, что реакция на любой новый язык будет примерно такая: половина скажет "полное дерьмо", вторая половина скажет "круто", но не попробует написать ни строчки, и только десяток энтузиастов реально попробуют что-то делать, зададут несколько вопросов, и только единицы сделают что-то работающее и позволят устранить по ходу дела какие-то баги....
А пример OneScript показывает, что сначала на языке надо хотя бы что-то полезное написать, что бы люди сначала просто пользовались, а по ходу дела уже втягивались, медленно втягивались в процесс роста кодовой базы...
Без рекламного бюджета, только на то, что бы много людей узнало о языке, могут уйти годы... это все грустно, но это реальность...

Опять вопрос - а что такое "Net Framework"? - в целом это просто набор проприетарных windows библиотек (в первую очередь заточенных именно под C# - хоть и доступных на других языках платформы windows)! да к тому же - уже отмирающий!

ну, тут вы не правы... Net Framework это основа, начиная с примитивных типов и заканчивая всеми модными штучками... то, что его почистили от привязки к Винде и назвали Core, а теперь еще раз перевыпустят под названием Net 5, ничего не меняет... там примерно один и тот же набор плюшек, постоянно растущий...
Я, по бедности, решил Core пропустить, буду сразу на Net 5 переходить, когда выпустят...
если мне кто-то предложит не использовать Net Framework, как бы он не назывался, то мне только застрелиться останется...

ну да - при интеграции с другими языками тут будут проблемы - нужны просто обходные пути.

ради составного типа мне не хочется создавать проблемы... тем более, что есть еще много не решенных задач, на которые просто времени не хватает... в список задач я конечно это записал, но он такой большой, что когда руки дойдут даже предположить страшно... я, вон, в своей стандартной библиотеке симметричные методы шифрования реализовал, а за асимметричные примерно пол года, как не могу взяться... ну нет времени, а ведь надо взять и сделать...

А большой словарь - это скорее отталкивающий фактор, чем притегательный - изучать его сложнее

я стараюсь, что бы мой словарь не выходил за рамки обычной книжной терминологии... плюс некоторые слова языка-прототипа 1С... или в крайнем случае других популярных языков-прототипов...
мой язык пока не мертв, он пока только рождается... как положено, в муках...
40. Darklight 32 27.02.20 10:01 Сейчас в теме
(37)
ну, тут вы не правы... Net Framework это основа, начиная с примитивных типов и заканчивая всеми модными штучками... то, что его почистили от привязки к Винде и назвали Core, а теперь еще раз перевыпустят под названием Net 5, ничего не меняет..

В том то, и дело, что ".Net Framework" сейчас версии 4.8 - и это проприетарная windows платформа библиотек и среды выполнения. То что ".NET CORE" и ".NET 5" - это уже несколько другие платформы. У них другое устройство основы и другие библиотеки, и свои стандарты.

ради составного типа мне не хочется создавать проблемы...

Это узкие проблемы. Они не касаются именно Перфоленты. А только интеграции с другими языками (это проблемы других языков). И так всегда бывает - когда создаёшь что-то особое, чего нет у других. И этого не стоит бояться.
И, как я уже много раз Вам говорил. У языка должны быть якорные фишки - изюминки - чего нет у других - которые будут привлекать искушённую аудиторию - а она уже потянет за собой остальных! Пока Ваш язык слишком сильно похож на VB хоть и на русском (намеренно не сравнил с 1С). И посему, привлекать серьёзных программистов к нему просто почти нечем. Привлекать 1С-овцев можно - но сложно - ибо зачем им это? Для решения внеплатформенных задач и экономии лицензий - есть конкурент - OneScript, к нему можно писать внешние компоненты. Да, вот, на Перфоленте для него действительно можно писать внешние компоненты не уходя далеко от синтаксиса 1С. Эту нишу занять можно. Обе программы написаны на ".NET Framework" (хотя OneScript имеет ".NET Core" реализацию), а значит очень гибко совместимы при интеграции. А вот писать компоненты для 1С Предприятие 8 - на Перфоленте не особо перспективно - ибо они не будут Native - а тут сейчас именно такие ВК в моде.

Вот если бы Перфолента легла в основу альтернативного учётного фреймворка - а-ка конкурента "1С Предприятие 8" - тогда да - тут и бизнес модель построить можно было бы - вот только реальные перспективы пока не высоки. Хотя да, это было бы круто! Но тут нужна большая команда единомышленников. И финансирование.
42. Perfolenta 204 27.02.20 12:01 Сейчас в теме
(40)
То что ".NET CORE" и ".NET 5" - это уже несколько другие платформы.

уже почти все классы, которые только можно, перетянули из Net Framework в Core, так что почти одно и то же.. при переносе кода в Core и обратно проблем совсем не много возникает, если не использовалось что-то жестко виндовое...

Вот если бы Перфолента легла в основу альтернативного учётного фреймворка - а-ка конкурента "1С Предприятие 8" - тогда да - тут и бизнес модель построить можно было бы - вот только реальные перспективы пока не высоки.

будет язык, буду строить бизнес-модель... а пока только к версии 0.5 приближаюсь... даже форм готовых еще не сделал... только заготовки :) первый конструктор форм уже есть, но еще не доделан и в свет не выпущен...
хотя англоязычным вариантом форм и сейчас можно пользоваться почти без ограничений... но это не годится... только русскоязычный вариант считается...

Пока Ваш язык слишком сильно похож на VB хоть и на русском

он и на C# похож и на 1С, и на Питон местами, и не известно на что больше... скорее на все современные языки сразу... у меня часто поддерживается оба варианта синтаксиса, и из C# и из VB.... и с операциями то же самое, стараюсь поддержать из C# то, чего нет в VB, и наоборот... а из 1С уж тем более... есть и оригинальные операторы, которых нет ни у кого...
есть такой интересный сайт Проект Эйлера... я часто там что-то решаю на Перфоленте и сравниваю с решениями на других языках... очень часто остаюсь доволен своим языком и это радует... или что-то дорабатываю в языке и библиотеке, что бы задача решалась красиво...
иногда прикольно выглядит, например:
       Пт=Новый ПостроительТекста
        Пт{"73167176531330624919225119674426574742355349194934"}
        Пт{"96983520312774506326239578318016984801869478851843"}
        Пт{"85861560789112949495459501737958331952853208805511"}
        Пт{"12540698747158523863050715693290963295227443043557"}
        Пт{"66896648950445244523161731856403098711121722383113"}
        Пт{"62229893423380308135336276614282806444486645238749"}
        Пт{"30358907296290491560440772390713810515859307960866"}
        Пт{"70172427121883998797908792274921901699720888093776"}
        Пт{"65727333001053367881220235421809751254540594752243"}
        Пт{"52584907711670556013604839586446706324415722155397"}
        Пт{"53697817977846174064955149290862569321978468622482"}
        Пт{"83972241375657056057490261407972968652414535100474"}
        Пт{"82166370484403199890008895243450658541227588666881"}
        Пт{"16427171479924442928230863465674813919123162824586"}
        Пт{"17866458359124566529476545682848912883142607690042"}
        Пт{"24219022671055626321111109370544217506941658960408"}
        Пт{"07198403850962455444362981230987879927244284909188"}
        Пт{"84580156166097919133875499200524063689912560717606"}
        Пт{"05886116467109405077541002256983155200055935729725"}
        Пт{"71636269561882670428252483600823257530420752963450"}
        мас=Пт.ВСтроку.ВМассивСтрок.ЗначенияКТипу<Целое>.ВМассив

Показать
44. Darklight 32 27.02.20 17:05 Сейчас в теме
(42)Хоть бы пояснили - что это за абракадабра. Пока ничего изящного в ней не вижу
45. Perfolenta 204 27.02.20 19:12 Сейчас в теме
(44) что тут пояснять-то... построитель текста заполняется строками, потом из этого получается массив целых чисел...
с теоретической точки зрения тут нет ничего необычного или интересного...
просто когда написал стало смешно, получился чёрный квадрат в синей рамочке... я же написал "прикольно выглядит"...
47. Darklight 32 28.02.20 16:56 Сейчас в теме
(45)Я просто хотел понять - в чём смысл этой красоты - я и в C# могут - разве что придётся чутка типовые классы допилить - ибо есть некоторые ограничения расширения (в языке C# - например нельзя сделать метод расширения для перегрузки оператора, а базовые классы запечатаны для наследования), поэтому, вот так расширяю построитель текста:

public class StringBuilderEx
{
StringBuilder _sb = new StringBuilder();

public StringBuilderEx Append(String str)
{
_sb.Append(str);
return this;
}

public static StringBuilderEx operator +(StringBuilderEx sb, String str) => sb.Append(str+'\n');
public override string ToString() => _sb.ToString();

}

А потом вот так делаю тоже самое:

var arr = new StringBuilderEx()
arr += "73167176531330624919225119674426574742355349194934";
arr += "96983520312774506326239578318016984801869478851843";
arr += "85861560789112949495459501737958331952853208805511";
arr += "12540698747158523863050715693290963295227443043557";
arr += "66896648950445244523161731856403098711121722383113";
arr += "62229893423380308135336276614282806444486645238749";
arr += "30358907296290491560440772390713810515859307960866";
arr += "70172427121883998797908792274921901699720888093776";
arr += "65727333001053367881220235421809751254540594752243";
arr += "52584907711670556013604839586446706324415722155397";
arr += "53697817977846174064955149290862569321978468622482";
arr += "83972241375657056057490261407972968652414535100474";
arr += "82166370484403199890008895243450658541227588666881";
arr += "16427171479924442928230863465674813919123162824586";
arr += "17866458359124566529476545682848912883142607690042";
arr += "24219022671055626321111109370544217506941658960408";
arr += "07198403850962455444362981230987879927244284909188";
arr += "84580156166097919133875499200524063689912560717606";
arr += "05886116467109405077541002256983155200055935729725";
arr += "71636269561882670428252483600823257530420752963450";
var mas = arr.ConvertAllStr().ToArray();

System.Decimal[] mas = Array.ConvertAll<System.String,System.Decimal>(arr.ToString().Split('\n'), new Converter<System.String, System.Decimal>((System.String a) => System.Decimal.Parse(a)));

Да, чутка длиннее - ну тут всё дело только в отсутствии пары готовы библиотечных функций, в длинных именах типов

Можно и проще - без построителя текста

public class ArrayEx<T>
{
public List<T> _arr = new List<T>();

public ArrayEx<T> Add(T str)
{
_arr.Add(str);
return this;

}

public static ArrayEx<T> operator +(ArrayEx<T> arr, T str) => arr.Add(str);
public override string ToString() => _arr.ToString();

protected R Parse<R>(T s)
{
Type t = typeof®;
System.Reflection.MemberFilter d = (System.Reflection.MemberInfo m, object n) => m.Name.ToString() == n.ToString();
var m = t.FindMembers(System.Reflection.MemberTypes.Method, System.Reflection.BindingFlags.Public | System.Reflection.BindingFlags.Static, d, "Parse");
if (m.Length==0)
throw new System.NotSupportedException();

return ®(object)t.InvokeMember(m[0].Name, System.Reflection.BindingFlags.Public | System.Reflection.BindingFlags.Static | System.Reflection.BindingFlags.InvokeMethod, null, null, new object[1] { s });
}

protected System.Numerics.BigInteger Parse(string s)
{
var b = new byte[s.Length];
var sp = s.AsSpan();
for (int i=0; i<s.Length; i++)
b[i] = byte.Parse(sp.Slice(i,1));

Span<byte> sb = new Span<byte>(b);

return new System.Numerics.BigInteger(sb,true,true);
}

public List<R> ConvertAll<R>() => _arr.ConvertAll<R>(new Converter<T, R>((T a) => Parse<R>(a)));
public List<System.Numerics.BigInteger> ConvertAllStr() => _arr.ConvertAll<System.Numerics.BigInteger>(new Converter<T, System.Numerics.BigInteger>((T a) => Parse(a.ToString())));
}


var arr = new ArrayEx<System.String>();
arr += "73167176531330624919225119674426574742355349194934";
arr += "96983520312774506326239578318016984801869478851843";
arr += "85861560789112949495459501737958331952853208805511";
arr += "12540698747158523863050715693290963295227443043557";
arr += "66896648950445244523161731856403098711121722383113";
arr += "62229893423380308135336276614282806444486645238749";
arr += "30358907296290491560440772390713810515859307960866";
arr += "70172427121883998797908792274921901699720888093776";
arr += "65727333001053367881220235421809751254540594752243";
arr += "52584907711670556013604839586446706324415722155397";
arr += "53697817977846174064955149290862569321978468622482";
arr += "83972241375657056057490261407972968652414535100474";
arr += "82166370484403199890008895243450658541227588666881";
arr += "16427171479924442928230863465674813919123162824586";
arr += "17866458359124566529476545682848912883142607690042";
arr += "24219022671055626321111109370544217506941658960408";
arr += "07198403850962455444362981230987879927244284909188";
arr += "84580156166097919133875499200524063689912560717606";
arr += "05886116467109405077541002256983155200055935729725";
arr += "71636269561882670428252483600823257530420752963450";
var mas = arr.ConvertAllStr().ToArray();

Сначала хотел парсить в Decimal (в т.ч. вообще универсальным парсером - но динамические вызовы это медленно, в такие числа в decimal не влезают) - потом сделал конвертирование строки в System.Numerics.BigInteger.

Но всё-равно - зачем так сложно когда можно просто вот так:

var ss = @"73167176531330624919225119674426574742355349194934
96983520312774506326239578318016984801869478851843
85861560789112949495459501737958331952853208805511
12540698747158523863050715693290963295227443043557
66896648950445244523161731856403098711121722383113
62229893423380308135336276614282806444486645238749
30358907296290491560440772390713810515859307960866
70172427121883998797908792274921901699720888093776
65727333001053367881220235421809751254540594752243
52584907711670556013604839586446706324415722155397
53697817977846174064955149290862569321978468622482
83972241375657056057490261407972968652414535100474
82166370484403199890008895243450658541227588666881
16427171479924442928230863465674813919123162824586
17866458359124566529476545682848912883142607690042
24219022671055626321111109370544217506941658960408
07198403850962455444362981230987879927244284909188
84580156166097919133875499200524063689912560717606
05886116467109405077541002256983155200055935729725
71636269561882670428252483600823257530420752963450".Replace(" ", "");

var mas = Array.ConvertAll<System.String, System.Numerics.BigInteger>(ss.Split("\r\n"), new Converter<System.String, System.Numerics.BigInteger>((String target)=>
{
var b = new byte[target.Length];
var sp = target.AsSpan();
for (int i = 0; i < target.Length; i++)
b[i] = byte.Parse(sp.Slice(i, 1));

Span<byte> sb = new Span<byte>(b);

return new System.Numerics.BigInteger(sb, true, true);
}
));
51. Perfolenta 204 28.02.20 19:37 Сейчас в теме
(47) согласитесь, что все ваши варианты выглядят забористей моего :)
у меня в Перфоленте тоже можно разными способами решить эту задачу, в т.ч. похожими на ваши (числа сократил для наглядности):
1)
мас = @"73167176531330624919225119674426
96983522623957831801698480186947
85861560789112949495459501737958"@ _
.Заменить(Символы.ВКПС,"").ВМассивСтрок.ЗначенияКТипу<Целое>.ВМассив

2)
мас = "73167176531330624919225119674426
      |96983520312774506326239578318016
      |85861560789112949495459501737958" _
.Заменить(Символы.ВКПС,"").ВМассивСтрок.ЗначенияКТипу<Целое>.ВМассив

3)
мас = Новый ПостроительТекста{
      "73167176531330624919225119674426",
      "96983520312774506326239578318016",
      "85861560789112949495459501737958"} _
.ВСтроку.ВМассивСтрок.ЗначенияКТипу<Целое>.ВМассив

я при создании синтаксиса много таких задачек порешал и вполне компактно они у меня записываются... еще вот лямбды доделаю и будет полный фарш...
53. Perfolenta 204 28.02.20 20:34 Сейчас в теме
(51) в догонку... есть еще способ с регулярным выражением:
мас = "73167176531330624919225119674426
      |96983520312774506326239578318016
      |85861560789112949495459501737958" _
.ПолучитьСовпадения("[0-9]").ЗначенияКТипу<Целое>.ВМассив
54. Darklight 32 29.02.20 11:36 Сейчас в теме
(51)Согласитесь - всё это просто решается на уровне библиотек, которыми вы дополняете свой языке - я на C# могу такие же функции сделать и написать так же красиво - LINQ мне в помощь!
В данном случая - вся соль в "ЗначенияКТипу<Целое>" - я ведь тоже могу сделать такую функция расширения и объявить псевдоним типа "System.Numerics.BigInteger" - и всё будет так же компактно (как уже показано мной с функцией "ConvertAllStr()").
55. Perfolenta 204 29.02.20 14:05 Сейчас в теме
(54) всё верно, вы можете на любом современном языке сделать... на то они и современные... но речь идет о поставке "из коробки"... и я пытаюсь добиться, что бы из коробки большое количество стандартных задач на Перфоленте решалось удобно...
Это отнимает очень много времени... функция ЗначенияКТипу<Целое> не сама ведь придумалась... как и десятки других полезностей...
И дело не только в функциях библиотеки...
Компилятор тоже помогает...
Например, вот эти два кусочка:
Пт = Новый ПостроительТекста{
      "73167176531330624919225119674426",
      "96983520312774506326239578318016",
      "85861560789112949495459501737958"}

и
Пт=Новый ПостроительТекста
        Пт{"7316717653133062491922511967"}
        Пт{"9698352031277450632623957833"}
        Пт{"8586156078911294949545950173"}

одна и та же задача решена двумя способами...
это синтаксический сахар языка... использование инициализатора...
Вам пришлось эмулировать это и все равно не так просто получилось...
Совсем уж что-то необычное для языка трудно придумать, но вот таких мелочей у меня в языке много...
Не знаю, почему вам хочется принизить мои труды, вы уже использовали для этого разные слова вроде "абракадабра, ни рыба ни мясо"... я не обижаюсь... я понимаю причины... но у меня есть и поклонники, которые меня морально поддерживают и что-то пишут на Перфоленте, пока по мелочам, но я им чрезвычайно благодарен...
И Вам благодарен, т.к. наша с вами дискуссия то же очень полезна для меня и для Перфоленты...
56. Darklight 32 02.03.20 10:12 Сейчас в теме
(55)
всё верно, вы можете на любом современном языке сделать... на то они и современные... но речь идет о поставке "из коробки"... и я пытаюсь добиться, что бы из коробки большое количество стандартных задач на Перфоленте решалось удобно...
Это отнимает очень много времени... функция ЗначенияКТипу<Целое> не сама ведь придумалась... как и десятки других полезностей...

Встроенные библиотеки - это хорошо, но при выборе языка не играет ключевой роли (хоть биьлиотеки - это и важно). Сейчас активно развивается идеология быстро устанавливаемых пакетов библиотек (например система NUGET) - тут вообще не важно на каком языке написаны библиотеки - главное это совместимость среды их выполнения с проектом, где они будут использоваться. Не важно, для какого языка.
Но да, разработчики языков пишут свои встроенные библиотеки - либо чтобы подчеркнуть изящество своих языковых конструкций, либо... чтобы оправдать что в их языке нет каких-то языковых фишек, других языков - потому что это всё можно сделать так же изящно - но на библиотеках, не перегружая сам язык. Ну или, просто - пытаясь привлечь публику библиотечных сахаром - мол у нас в комплекте идут крутые библиотеки, здорово облегчающие жизнь в рядке специфических ситуаций программирования - но это чистой воды читерство.

Компилятор тоже помогает...
Например, вот эти два кусочка

Вот первый выглядит лучше второго даже, а второй ничуть не лучше (по восприятию и набору кода) чем
arr += "73167176531330624919225119674426574742355349194934";
arr += "96983520312774506326239578318016984801869478851843";

Да, C# так не может. Вот, в той, универсальной концепции обработки выражений, что я выше уже предложил - это было бы как раз плюнуть. Даже построитель текста не пришлось бы модернизировать. Да и массивы тоже - при применении концепции методов расширителей классов (в развитии до конструкторов расширителей классов - когда к массиву можно было бы добавить макро-конструктор-расширение - принимающее выражение, и производящий на его основе инициализацию).

Вам пришлось эмулировать это и все равно не так просто получилось...

Куда уж проще ввести просто строкой

Но инициализатор массива я тоже мог использовать - но вряд ли будет проще строки, но и хуже вашего варианта тоже не будет
Инициализация массива строк на C#

далее это можно и в построитель текста передать(только зачем) или в библиотечную функцию - для конвертации массива строк в массив чисел.
Инициализаторы - это хорошо, я против них ничего не имею.

Совсем уж что-то необычное для языка трудно придумать

Вот мне не трудно.
Те же составные типы я Вам предложил.
Идея универсальной обработки выражений.
Или макрофункции.
Или вот, я об этом не писал - есть ещё идея сквозной передачи параметров во вложенные функции, с их расширением у вложенных (без изменения синтаксиса аргументов промежуточных функций) - отличная концепция для применения парадигмы "Dependency injection" - чего в 1С ОЧЕНЬ не хватает.
Или идеи временного глобально/локального переназначения конструкторов типов или вызовов функций.
И много чего ещё я могу придумать для языка - чего нет (или почти нет) у других - что могло бы стать крутыми якорными фишками языка!
И как сделано асинхронное программирование - мне, например, пока ни понравилось ни в одном языке программирования! И у меня тут есть полно своих идей!

Не знаю, почему вам хочется принизить мои труды, вы уже использовали для этого разные слова вроде "абракадабра, ни рыба ни мясо"... я не обижаюсь... я понимаю причины... но у меня есть и поклонники, которые меня морально поддерживают и что-то пишут на Перфоленте, пока по мелочам, но я им чрезвычайно благодарен...

Простите, ни в коем мере не пыталась принизить Ваши труды. Делать свой язык программирование - задача не простая, но, не особо.... ээээ.... "чистая" что-ли - новый язык всегда будут критиковать и поливать грязью! Надеюсь Ваш язык я грязью не поливал. А критика - ну Вы же знаете что оно полезна! Надеюсь рамки разумного я тоже не переступил.
Я лишь высказывал своё мнение - оно моё и ничьё больше. Я его Вам не навязываю. У меня просто "зуб" на все языки программирования! Я ни один не выгораживаю - у меня ко всем, известным мне, языка тонны претензий! И есть свои концепции языков (нескольких), и даже для них я точно так же могу сам же написать кучу претензий. Просто так я устроен - у меня очень критические взгляды на всё, даже на себя.
А хотите мнение сообщества - пишите статью - приводите концептуальные примеры синтаксиса - устраивайте голосование!
57. Perfolenta 204 02.03.20 11:37 Сейчас в теме
(56)
Вот первый выглядит лучше второго даже, а второй ничуть не лучше

второй вариант синтаксиса тоже очень полезен бывает, например, вот этот фрагмент кода
ХД  = Новый ХешированиеДанных(ХешФункция.SHA256)
ХД.Добавить(Ключ)
ХешКлюча = ХД.ХешСумма.Буфер

он позволяет записать так
ХешКлюча = Новый ХешированиеДанных(ХешФункция.SHA256){Ключ}.ХешСумма.Буфер

или вот, создадим веб страничку с таблицей
Пт = Новый ПостроительТекста{@"        
<!do ctype html>
<ht ml>
<head>
<title>"@,Заголовок,@"</title>
</head>
<body>
<table>
"@}
Для Инд1=0 По Таблица.ВГраница(0)
  Пт{"<tr>"}       
  Для Инд2=0 По Таблица.ВГраница(1)
      Пт{"<td align=""center"">", Таблица[Инд1,Инд2], "</td>"}         
  КонецЦикла  
  Пт{"</tr>"}        
КонецЦикла  
Пт{@"
</table>
</body>
</html>
"@}        
//сохраним и откроем в браузере
ЗапуститьПриложение(ФС.ЗаписатьВоВременныйФайл(Пт.ВСтроку,".html"))  
Показать

Инициализатор обеспечивает гораздо лучшую наглядность, краткость и скорость работы, чем без него... (расцветка кода тут выглядит ужасно, т.к. это не код 1С, еще и портит некоторые строки, но думаю вы поймете где что)


Но да, разработчики языков пишут свои встроенные библиотеки - либо чтобы подчеркнуть изящество своих языковых конструкций, либо... чтобы оправдать что в их языке нет каких-то языковых фишек

мне кажется, что встроенные библиотеки просто дают базовый словарь, который будут знать все разработчики на этом языке... в моем случае это еще важнее, т.к. на русском языке библиотек пока просто нет... (хотя, стоп, есть такие... например расширение Бром к 1С написано на C# и имеет русскоязычные имена объектов, методов и свойств... легко может быть использовано из Перфоленты...)
Стандартная библиотека не покроет все нужды, но она должна покрыть базовые потребности...

И много чего ещё я могу придумать для языка - чего нет (или почти нет) у других - что могло бы стать крутыми якорными фишками языка!

Жаль, что вы не пишите язык... моя реализация ваших идей может вам и не понравиться, т.к. вкусы наши слишком различны, это мы уже давно с вами поняли...

И как сделано асинхронное программирование - мне, например, пока ни понравилось ни в одном языке программирования!

я себе придумал вот такую конструкцию, но пока не реализовал... только пару экспериментов провел...
Асинхронно
    //любой код выполняющийся асинхронно, например
    ВызовАсинхроннойПроцедуры(Параметр1)
Завершение
    //какой-то код после завершения асинхронного кода
КонецАсинхронно

есть конечно сложности в реализации над которыми я еще думаю... но скорее всего получится сделать именно так...
58. Darklight 32 02.03.20 17:53 Сейчас в теме
(57)
Асинхронно
//любой код выполняющийся асинхронно, например
ВызовАсинхроннойПроцедуры(Параметр1)
Завершение
//какой-то код после завершения асинхронного кода
КонецАсинхронно


Где-то я нечто-подобное уже видел (Python Trio) - асинхронное программирование в питомниках (контейнерах) - но не могу сказать, что очень понравилось, хоть и определённый смысл в этом есть
59. Perfolenta 204 02.03.20 21:39 Сейчас в теме
(58)
Где-то я нечто-подобное уже видел (Python Trio)

спасибо, статья интересная оказалась, хотя там и много воды, но зато прекрасные острова... :)
про Python Trio я раньше не слышал...
моя реализация оператора Асинхронно была задумана скорее как некий симбиоз замыкания и Task... без ожидания завершения фоновой задачи основным потоком... секция Завершение просто должна выполниться в основном потоке... но к тому моменту сама процедура в которой находится оператор Асинхронно уже могла давно завершиться...
у меня есть статья по многопоточности в Перфоленте http://promcod.com.ua/Article.asp?code=20200209191724066229
в которой я более-менее описал то, что уже хорошо и стабильно работает по многопоточности... (правда в той версии, которая вот-вот выйдет... статью я опубликовал немного раньше времени...)
если хотите, почитайте...
а статья, на которую вы указали, возможно повлияет на мою реализацию оператора Асинхронно, там есть над чем подумать... еще бы времени на эти размышления где-то взять :)
основная работа оставляет крохи на Перфоленту...
5. starik-2005 3033 22.01.20 09:58 Сейчас в теме
(3) а что тут автору объяснять? В действительности в С без внешней библиотеки (тот самый инклюд) не вывести этот "хеллоу ворлд", в питоне библиотека эта уже типа "автоматом" прилинкована. int и return в правильной программе обязаны быть, ибо "void main()" g++ уже без доппараметров не скомпилит - ему нужен и int, и аргументы функции, return, конечно, можно опустить, но это не есть хорошо, т.к. программа должна возвратить "0", если все "ОК".
AlexSinichenko; +1 Ответить
8. AlexSinichenko 22.01.20 10:25 Сейчас в теме
(5) все верно, но это уже тонкости каждого отельного компилятора которые мы опускаем, мы в целом же язык пытаемся сравнить, да и никто не говорит, что printf() нужно вызывать именно в теле главной функции, это может быть и самописная VOID функция (процедура) которая не требует возврата значения в принципе. Что касается питона здесь мы как никто другой знаем, что если "в питоне библиотека эта уже типа "автоматом" прилинкована" то мы жертвуем драгоценными ресурсами, т.к. там еще много чего "прилинковано" изначально (на что в самом С нам дано право выбора, ликновать или нет), все это в принципе может не используется в процессе выполнения кода (но тем не менее заранее подключено, грузится в память, компилируется увеличивая вес конечной программы и т.д.), в питоне мы уже лишены права выбора что линковать, а что нет, по мне так это очевидные минусы...
9. starik-2005 3033 22.01.20 12:13 Сейчас в теме
(8)
в питоне мы уже лишены права выбора что линковать, а что нет, по мне так это очевидные минусы
Питон в большинстве своем работает как интерпретатор, поэтому там уже все загружено в память, которую это все - да - яростно жрет. Но оно ее уже сожрало, так что для нашей программы линковка для выполнения не нужна - достаточно иметь интерпретатор.

С другой стороны, если мы, например, используем PyPy или cPython, то у нас происходит трансляция в программу на C, в которую также система включает все эти библиотеки, но при компиляции и последующей линковке неиспользуемые библиотеки будут пропущены, так что ровно то на то и выходит, но код в питоне будет лаконичнее (типа (а, б) = (б + а, а) - так на С не напишешь).

Питон хорош количеством примеров для различных библиотек, кучей фреймворков с неплохой документацией, синтаксическим сахаром, отличными функциональными возможностями, базовыми типами для списокв, кортежей, разнообразных массивов и прочим - в С это все в библиотеках можно найти, но это будет сложнее (пример тому - разбирался с zip, и это было не так сложно, как XML - там жесть, ибо описание библиотеки для работы с ним в С++ достаточно слабо отвечает на вопрос о том, как прочитать схему и отвалидировать по ней файл).

В общем питон - супер-штука, но в умелых и пытливых руках и С/С++ - очень даже отличный язык - тот же glut - ваще улет!
AlexSinichenko; +1 Ответить
17. Perfolenta 204 19.02.20 19:40 Сейчас в теме
(9) уже давно, популярность языка зависит не столько от его синтаксиса, сколько от наличия мощных и хорошо документированных библиотек... народ просто берет готовое и приспосабливает под свои нужды...
а если честно, то очень многие библиотеки Питона написаны на Си... в какую копилочку положим заслуги? Трудно сказать, скорее обоим языкам надо воздать должное...
10. Alligator84 74 23.01.20 07:35 Сейчас в теме
Ну не 15 лет стажа:-), конечно, но автору публикации благодарность!
Думаю цель была не в субъективном анализе статьи автором, а довести информации сообществу.
Познавательно.
11. dock 44 23.01.20 08:57 Сейчас в теме
Вот всегда так... С/С++, питон, Джава...
Где 1С в рейтинге?
13. Perfolenta 204 19.02.20 17:04 Сейчас в теме
(11) Странный вопрос, если учесть, что в России живет всего-лишь около 2% населения планеты...
в 1С, конечно, есть английский синтаксис, но на нем написано слишком мало кода, что бы считать, что такой язык вообще существует...
Было бы интересно подсчитать рейтинг использования языков на территории России, может быть плюс некоторые страны СНГ... тогда стал бы понятен процент 1С...
Только уехавших за бугор брать в этот рейтинг не надо, т.к. у них уже нет выбора, только английский...
18. dock 44 19.02.20 20:08 Сейчас в теме
(13) Представительства 1С уже есть на ВСЕХ континентах (и до Австралии тоже добрались). Как минимум представлена 1 типовая конфигурация полностью на английском языке (не интерфейсная часть, а исходный код). В ОАЭ (Эмираты) 1С используется на гос. уровне.
На текущий момент 1C ERP вполне себе конкурент и пресловутому SAP!
Поэтому совсем не странный вопрос :) Никто не говорит даже о первой десятке, но хотя бы просто "засветиться" уже должен.
А пока наблюдается полный игнор...
19. acanta 19.02.20 20:28 Сейчас в теме
Интерпретатор сравнивают с компиляторами. 1с это макрос, встроенный в документ. Мы же не сравниваем документ к примеру договор в формате Ворда с питоном.
21. Perfolenta 204 20.02.20 11:19 Сейчас в теме
(19) на счет макроса вы явно загнули :)
любая конфигурация 1С это уже супер-пупер гигантский макрос....
а серьезно,
сравнивается популярность языков, а не их возможности... Питон, как и 1С, тоже интерпретатор...
22. acanta 20.02.20 12:10 Сейчас в теме
(21) и офис в этом смысле проигрывает только в настройках доступа к отдельным листам/ячейкам отдельным пользователям и количеством разных паролей на один макрос.
25. Perfolenta 204 20.02.20 16:07 Сейчас в теме
(22) дело не в офисе... сам офис вполне можно сравнить с 1С... дело в том, что вы макросом называете...
Программу на языке 1С ни как нельзя назвать макросом... ни даже набором макросов... впрочем как и приложение на языке VBA в офисе тоже макросом не является...
23. dock 44 20.02.20 15:04 Сейчас в теме
(19) И да, в рейтинге участвует javaScript, PowerShell, PostScript и т.д. ...
Тот же ABAP (если кто забыл, это из SAP) занял 31-е место.
Что Вы там говорили о сравнении интерпретатора с компиляторами?
20. Perfolenta 204 20.02.20 10:35 Сейчас в теме
(18) Это, кстати, тоже интересно, какое число инсталляций 1С за рубежом... наверняка с САПом не сравнимое... 1С сравнительно недавно вышла на этот рынок...
24. dock 44 20.02.20 15:18 Сейчас в теме
(20)
какое число инсталляций 1С за рубежом... наверняка с САПом не сравнимое...
А может как раз наоборот. Но тут уж виновата специфика SAP - этот продукт рассчитан на холдинги и корпорации, даже для среднего бизнеса это "не подъемно". У 1С на порядок более широкий рынок.
26. Perfolenta 204 20.02.20 17:20 Сейчас в теме
(24) может и наоборот... я же говорю, интересно было бы узнать сколько инсталляций 1С за рубежом...
12. user660224_laa 5 28.01.20 15:11 Сейчас в теме
да! Когда 1С уже поднимется в рейтинге?
48. Darklight 32 28.02.20 17:15 Сейчас в теме
(46)Почему-то не могу ответить на это пост. Содержательный комментарий не сохраняется. Один уже потеря. Второй написал - та же беда.
Отправлю в личку
Забавно - в личку тоже не отправлятся
Оставьте свое сообщение

См. также

В программу подготовки спортивных программистов вошли бег и скорость печати

Новость ИТ-Новость

Пятничное: в России вступил в силу стандарт подготовки по дисциплине «спортивное программирование». В стандарт вошли требования к физическим показателям спортсменов и скорости набора текста.

16.02.2024    642    VKuser24342747    2       

1

Росстандарт утвердил протокол LoRaWAN для интернета вещей

Новость ИТ-Новость

Федеральное агентство по техническому регулированию и метрологии (Росстандарт) утвердило национальный стандарт протокола LoRaWAN RU, таким образом он получил официальный статус. Технология используется для беспроводной передачи данных между устройствами интернета вещей.

19.01.2024    423    VKuser24342747    0       

2

Новый закон откладывает на год вступление в силу изменений в порядок регистрации на сайтах

Новость Законодательство ИТ-Новость

12 декабря вступил в силу Федеральный закон, меняющий срок, к которому все владельцы сайтов должны внести изменения в порядок авторизации пользователей на сайте. Закон вводит переходный период до 1 января 2025 года.

20.12.2023    602    VKuser24342747    2       

1

Вышло крупное обновление для Android Studio

Новость Мобильные приложения ИТ-Новость

Новая версия Android Studio под номером 2023.1 получила имя Hedgehog. Появились возможности контролировать производительность приложений и управлять подключенными устройствами.

07.12.2023    716    VKuser24342747    2       

3

GitHub опубликовал результаты ежегодного исследования проектов с открытым исходным кодом

Новость GitHub ИТ-Новость

GitHub собрал данные об Open Source проектах в рамках ежегодного исследования Octoverse. Компания изучила географию репозиториев, используемые языки программирования и нейросети, а также активность сообщества.

15.11.2023    486    VKuser24342747    1       

2

Некоммерческие проекты смогут получить бесплатный доступ к GigaChat API

Новость ИТ-компания ИТ-Новость

Компания «Сбер» заявила, что будет бесплатно предоставлять доступ к API нейросети для генерации текста GigaChat для некоммерческих проектов. Однако для них будет ограничено число доступных токенов.

01.11.2023    598    VKuser24342747    2       

3

Состоялся релиз свободной среды разработки Geany 2.0

Новость ИТ-Новость Программист

Вышла новая версия Geany 2.0. Обновление затронуло внешний вид программы, расширило поддержку файлов и сторонних проектов, добавило новые способы работы с кодом.

25.10.2023    691    VKuser24342747    0       

1

Минцифры подготовило критерии по выбору оператора реестра провайдеров хостинга

Новость Минцифры ИТ-Новость Роскомнадзор

Минцифры подготовило проект постановления, которое утверждает требования к организации, претендующей на статус оператора реестра провайдеров хостинга.

25.10.2023    356    VKuser24342747    0       

1

Минцифры составило алгоритм действий для компаний, у которых не работает VPN

Новость Минцифры ИТ-Новость

Минцифры подготовило разъяснения для российских организаций, у которых возникли перебои в работе VPN-сервисов для клиентов и сотрудников из-за блокировки запрещенных ресурсов Роскомнадзором.

24.10.2023    611    VKuser24342747    0       

0

«Сбер» объявила о доступности SberLinux OS Server для российских компаний

Новость Импортозамещение ИТ-Новость

«СберТех», дочерняя компания «Сбера», объявила о предоставлении доступа к собственной серверной операционной системе SberLinux OS Server российским компаниям. ОС включена в реестр отечественного ПО.

20.10.2023    821    VKuser24342747    0       

2

Минцифры внесло изменения в проект правил идентификации клиентов веб-хостингов

Новость Минцифры ИТ-Новость Роскомнадзор

Минцифры подготовило изменения в пакет документов, которые устанавливают новые требования для провайдеров хостинга. Ведомство расширило перечень допустимых методов идентификации клиентов.

18.10.2023    454    VKuser24342747    0       

1

Google выпустила финальную версию Android 14

Новость Android Google ИТ-Новость

Google выпустила новую версию мобильной ОС Android 14. Изменения затронули настройки внешнего вида и безопасности. Были расширены возможности камеры и инструментов для хранения данных.

12.10.2023    672    VKuser24342747    0       

1

Яндекс объявил об открытии исходного кода DataLens

Новость Аналитика ИТ-Новость Яндекс

BI-система Yandex DataLens теперь развивается в опенсорс. Код продукта выложен для всех на GitHub. Любой желающий сможет развернуть DataLens на своем железе и доработать его под свои сценарии применения.

03.10.2023    1363    ЕленаЧерепнева    1       

6

Роскомнадзор создаст реестр хостинг-провайдеров

Новость Минцифры ИТ-Новость Роскомнадзор

Минцифры подготовило несколько проектов постановлений, которые утверждают правила ведения реестра поставщиков хостинг-услуг, а также новые требования к провайдерам.

02.10.2023    560    VKuser24342747    0       

1

«СберТех» представил репозиторий GitVerse с ИИ-помощником для написания кода

Новость Импортозамещение ИТ-Новость Программист

«СберТех» начал прием заявок на тестирование веб-сервиса для публикации ИТ-проектов GitVerse. Платформа подходит для разработки программ с открытым и закрытым кодом.

26.09.2023    765    VKuser24342747    2       

1

ИП и юрлица смогут использовать смартфон для создания и замены электронной подписи

Новость ИТ-Новость ФНС Цифровая подпись

ФНС внесла изменения в правила оформления электронной подписи руководителя организации и ИП. Станет возможным продлевать ее и записывать при помощи мобильного устройства.

18.09.2023    415    VKuser24342747    1       

1

Журнал IEEE Spectrum опубликовал рейтинг популярности языков программирования

Новость ИТ-Новость Языки программирования

Журнал Института инженеров электротехники и электроники IEEE Spectrum подготовил рейтинг самых популярных языков программирования в 2023 году. Статистика разделена на три категории.

01.09.2023    1260    VKuser24342747    4       

2

В бета-версии Microsoft 365 появилась поддержка языка Python для Excel

Новость ИТ-Новость Языки программирования

С помощью библиотек и средств визуализации Python можно будет манипулировать данными Excel, а затем использовать полученные результаты в формулах, диаграммах и сводных таблицах.

28.08.2023    642    VKuser24342747    0       

2

Специалисты Калифорнийского университета установили, что боты справляются с CAPTCHA лучше, чем люди

Новость ИТ-Новость

Международная группа исследователей изучила эффективность тестов CAPTCHA. Ученые пришли к выводу, что технология больше мешает людям, потому что боты научились с ней справляться.

24.08.2023    1140    VKuser24342747    23       

2

Google Chrome начнет поддерживать квантово-устойчивые алгоритмы шифрования

Новость Google Безопасность ИТ-Новость

В версии Google Chrome 116 появится поддержка алгоритмов шифрования, устойчивых к попыткам дешифрации при помощи квантовых вычислений. Технология объединяет преимущества классической и инновационной криптографии.

24.08.2023    464    VKuser24342747    0       

1

В реестр российского ПО включен первый комплекс обработки больших данных

Новость Импортозамещение Минцифры ИТ-Новость Реестр ПО

Минцифры внесло в реестр отечественного ПО программно-аппаратный комплекс «Скала-Р», предназначенный для обработки больших данных. Это первый комплекс с таким функционалом, включенный в перечень.

22.08.2023    452    VKuser24342747    0       

1

Microsoft внедрила новые функции в GitHub Copilot и анонсировала Windows Copilot

Новость GitHub Искусственный интеллект

ИИ-помощник для разработчиков GitHub Copilot теперь не только в реальном времени анализирует код, предлагает варианты для его улучшения и помогает найти решение проблем в разработке, но и  показывает ссылки на репозитории, из которых взят код. 

17.08.2023    1136    VKuser24342747    0       

1

В JetBrains разработали ИИ-помощника для аналитиков данных

Новость Аналитика Искусственный интеллект

JetBrains представила нейросеть Ask AI для онлайн-блокнота Datalore. Виртуальный ассистент способен генерировать код на нескольких языках, предлагать доработки и упрощать процесс аналитики данных. 

16.08.2023    649    VKuser24342747    0       

1

Исследование: ChatGPT дает неправильный ответ на половину вопросов о программировании

Новость Искусственный интеллект ИТ-Новость

Чат-бот OpenAI ошибается в 52% случаев, когда отвечает на вопросы по программированию. Однако делает это так убедительно, что пользователи не замечают ошибки. 

14.08.2023    986    VKuser24342747    5       

3

Минцифры проведет эксперимент по цифровизации «жизненного цикла» госслужащего

Новость Минцифры ИТ-Новость

Минцифры подготовило постановление о проведении эксперимента по внедрению ИТ в управление «жизненным циклом» госслужащего. Ведомство намерено автоматизировать все этапы работы сотрудников госструктур.

04.08.2023    547    VKuser24342747    0       

2