()
Так как мне есть что сказать на эту тему я написал очень длинный ответ, занявший более 30 страниц чистого текста. Но этот разговор явно не соответствует теме исходной новости. Поэтому я этот текст постараюсь тогда оформить в виде статьи (куда, если Вы не будете против) вставлю некоторые Ваши цитаты (с указанием Вашего авторства; ссылку на Ваш проект тоже дам, хотя пока не планирую выстраивать статью вокруг вашего проекта – а хочу абстрагировать). И буду там давать, в ответ на эти цитаты, развёрнутые ответы, с примерами и картинками. Ибо для меня эта тема очень важна и интересна и тут у мен есть свои взгляды, хоть я их в одной, даже такой большой, статье изложить не с могу. Тем более, что у меня уже есть наработки для большого цикла статей – посвящённых моему виденью того, каким должен быть язык программирования в гипотетической платформе 1С: Предприятие 9 – лет так через 20-30 (если он останется самобытным, но в то же время будет подстраиваться под мировые тренды). Возможно, некоторой здешней аудитории это обсуждение так же будет интересно – и такая статья привлечёт их внимание. Ну, а может быть изложенные мною мысли найдут воплощение в чьих-либо будущих проектах. Ну а ещё – а хочу там сделать голосование – было бы интересно узнать мнение широкой аудитории.
Но тут, я всё-таки, сейчас дам очень краткие ответы (не очень содержательные, и возможно вырванные из контекста – ведь так оно и будет) – итоговые мысли по вашим цитатам. И считаю, что дальнейшее обсуждение, в рамках данного сабжа лучше завершить, в силу того, что это уже полный оффтопик. Ну а дальше – ждите статью.
Итак, очень-очень кратко отвечаю:
тут я с вами не согласен, т.к. сам в те времена боролся за экономию каждой буквы, когда текст программы тупо не влезал в буфер памяти... а набрать слово end не на много труднее, чем нажать Shift+{
Ну, те времена давно прошли и нынче не актуальны. Вот Visual Studio сейчас неплохо умеет вставлять скобки.
А в 1С – язык «русский», а в русском языке «беда» с окончаниями – со склонением словесных скобок всё очень неудобно.
а вот тут я с вами полностью согласен... при любой автоматической обработке кода скобочки лучше...
но при чтении кода человеком это уже не так однозначно... если обе скобки не в пределах видимости или много уровней вложенности, то человек теряется... попробуйте посчитать сколько тут нулей 00000000000000000000... трудная задача, глазам не за что зацепиться... это из той же психологической оперы, что и множество скобок...
Просто не стоит писать такой вложенный код. Нужно разбивать код на более мелкие автономные фрагменты. IDE тут в помощь.
А что словесные скобки – тут ничем не помогут. Я точно так же могу написать кучу вложенных чередующихся блоков «если» и «цикл» – и так же в них легок запутаюсь сам (не то, что другой программист, который потом это будет разгребать). И не только я так пишу и путаюсь.
Да, фигурные скобки тут не помогут – но и словесные не спасают! Тут другие решения.
Вообще книгу Роберта Мартина «Чистый код» нужно всем читать! Путь это не 1С и написана книга весьма сурово и категорично – но всё равно – чтение очень полезное!
А в остальном тут должна помогать сама IDE.
Где здесь тело функции?
Ну понятно - что после слова экспорт, а почему именно после
самое главное, что и вам понятно и компилятору понятно, проблема только у разработчика компилятора...
Вот из-за различных просчётов на первых этапах развития языка появляются всякие гадкие и некрасивые конструкции на последующих этапах его развития. Потому что иначе возникают всякие неоднозначные траблы при синтаксическом разборе.
на мой взгляд, слово Экспорт было изначально не удачно прилеплено, его часто даже не видно, когда окно редактора не слишком широкое... у меня, в Перфоленте, есть такая же проблема с указанием типа функции, он тоже справа указывается... как и с Экспортом в 1С это решается возможностью переноса на следующую строку, если название функции длинное или параметров много...
Оно Вам так надо видеть? Лично мне все вот эти директивы при просмотре кода не особо важны. Важные пояснения лучше делать в комментарии перед функцией, и правильно называть саму функцию. Что не важно программисту, который использует этот код как потребитель – то, значит, не и важно вовсе, и не нуждается в каком-то особом выделении (т.е. такие директивы важны чисто для компилятора).
о горизонтальной прокрутке и длине строки в редакторе |
|---|
| в редких случаях, можно и прокрутить горизонтально текст программы: кстати, недавно подарили мышку, имеющую боковой доп. ролик – реально оценил удобство горизонтальной прокрутки, хоть и редко она нужна; а ещё я предпочитаю ультра широкоформатные мониторы и/или два монитора – тоже очень удобно, и бред это всё – про макс «80» символов в строке, а дальше нужно переносить код на следующую строку – хотя, конечно не бред, но не такое уж это строго должно быть правило). |
Вообще тут да, палка о двух концах. На самом деле и справа не очень удобно и слева не очень красиво (более детально этот вопрос я освещу в статье, а пока просто один пример):
Левосторонние (на отдельной строке) привязки (гипотетических) директив |
|---|
Функция МояФункция(
&ТолькоЧтение
А,
&Исходящий
Число(10,2)
Б,
&Перем
В = неопределено,
&СписокАргументов
Г
)
возврат «Привет»;
КонецФункции
Показать |
Правосторонние привязки (на разных строках) |
|---|
Функция МояФункция(
А &ТолькоЧтение,
Число(10,2)
Б: Число(10,2) &Исходящий,
В &Перем = неопределено,
Г &СписокАргументов
)
возврат «Привет»;
КонецФункции
Показать |
Правосторонние привязки (в одну строку) |
|---|
Функция МояФункция( А &ТолькоЧтение, Б: Число(10,2) &Исходящий, В &Перем = неопределено, Г &СписокАргументов)
возврат «Привет»;
КонецФункции
|
Для меня самого, по-прежнему, открыт вопрос того где лучше размещать директивы. Но, я за правое размещение. А если нужно видеть что-то важное – пусть в этом помогают комментарии и IDE.
И ещё – зачем вообще их просматривать в коде? Для анализа API? Для этого должна использоваться синтакс-справка (автогенерируемая) и интелли-сайнс (всплывающая подсказка). И программист может помочь сгенерировать правильно – указав советующие директивы:
Пример |
|---|
Функция МояФункция(
А &Описание(“Аргумент А – бла бла бла”),
Б &URI(“help1c://Какойто_раздел”),
В &Тип(Число(10,2)),
Г &Перем,
Д &Режим(Исходящий,Ссылка) &Описание(“Сюда будет помещен результат),
Е &Где(ТипЗнч(_)=Тип(Число) И _ > 1), //Тут всё описание контрака сгенерируется автоматически
Ж &Тип(ДокументОбъкт.МойДоумент1)&Сервер&Поумолчанию(неопределено) &Описание(“Аргумент доступен только в серверном контексте – впрочем это тоже автоматически сгенерируется”),
З &Контекстный(“ГруппаКонтекста”) = “Это аргумент передаётся только именовано”,
К &СписокАргументов
)
возврат «Привет»;
КонецФункции
Показать |
Это только пример – возможны и другие подходы (более подробно – напишу в статье; как и ещё 7 других аргументов против желания выносить директивы в левую сторону).
Ну ещё - можно просто разрешить размещать директивы как слева, так и справа. Но тогда нужно как раз особо будет актуален вопрос разделения блоков кода – в т.ч. начала тела функции от её заголовка (куда будут отнесены директивы на их границе, если её не будет).
Другое дело – вот так (правостороннее размещение директив):
Функция МояФункция() &Контекст{Сервер,Клиент,!Мобильный,Внешний,Внутренний}&Кешировать(20*60)&ВозвращаемыйТип(Строка)
{
возврат «Привет»;
}
Тело функции явно обозначено областью с фигурными скобками, и отделено от заголовка.
Казалось бы можно как в Си тип слева указывать, но тут тоже есть подводный камень, сегодняшние типы могут сами очень длинно записываться и тогда сама функция уезжает слишком вправо...
Вот именно. Проблема, как и с директивами. Лично я тут строго за правостороннее размещение ограничений типов. В 1С просто этой проблемы нет (т.к. язык с динамической типизацией, без возможности указывать ограничения на типы - как, скажем в Python – где при наличии динамической типизации это всё-таки возможно, с 3-ей редакции, через декораторы). Типы (а-ля 1С) действительно могут быть очень длинными «Тип(ДокументСсылка.РеализацияТоваровУслуг)». А если бы в 1С были классы…
Конечно, знать тип возвращаемого значения функции гораздо важнее чем директивы. Это, на самом деле, важно и для языков с динамической типизацией.
Выхода здесь два (я за использование сразу обоих):
Назначать длинным именам типов более короткие псевдоними типа.
Альтернативный (дополняющий) вариант предлагает вынести длинные описания типов в отдельное место (без образования псевдонимов), скорее всего, верхнем левостороннем варианте размещения над основным определеним (в примере ниже – над функцией, в т.ч. для аргументов):
Пример |
|---|
&АргументТип(А, Число(10,2,Неотрицательное))
&АргументТип(Б, ДокументОбъект.ПоступлениеДопРасходов)
&АргументТип(В, {ДокументСсылка.ПоступлениеТоваровУслуг, ДокументСсылка.ОприходованиеТоваров, ДокументСсылка.ПриходныйТоварныйОрдер})
&АргументТип(Г) { Конфигурация1.МодульУправления.ПодМодульДоступа.РазделСлужебныхКлассов.КлассНаблюдатель.ВложенныйКлассПозицияНаблюдения, НЕОПРЕДЕЛЕНО, БУЛЕВО}
&ВозвращаемыйТип{ДокументСсылка.ПоступлениеТоваровУслуг, ДокументСсылка.ОприходованиеТоваров, ДокументСсылка.ПриходныйТоварныйОрдер, Число(10,2,Неотрицательное)}
Функция МояФункция (А, Б, В, Г)
КонецФункции
Показать |
Но на мой взгляд, по крайней мере, что касается аргументов, этот вариант ничем не лучше правостороннего размещения типов.
Вот и 1С стала расширять директивы функций другим путём (ставя их слева с амперсендом)
Слева для нас приятнее, мы же слева на право читаем...
Я не спорю и пишем и читаем слева на право – тут важно только размещать и видеть слева наиболее важную информацию, да так, чтобы она не сильно мешала видеть другую, тоже важную информацию, размещённую правее.
Фигурные скобки позволяют синтаксически чётко выделять места - где расположен программный код
проблема в том, что в современных языках фигурные скобочки применяются не только для блоков кода, но и для других нужд, например, для инициализаторов, для шаблонов строк и т.д.... и при беглом осмотре не всегда глаз может быстро выделить где что... скобок становится много... IDE конечно помогает облегчить чтение...
я в Перфоленте принял, что круглые скобки - параметры, квадратные - индексаторы, фигурные - инициализаторы...
Инициализаторы – это просто частный случай программных блоков. По сути – это тоже программный код – просто написан в определённом формате и представляет собой не поток инструкций, а выражения (в программный код обычно бывает двух типов: «поток инструкций» и «единое выражение»). И на основе этого выражения (я про Ваши инициализаторы) компилятор выстраивает программный код – в виде конечных инструкций. Секция инициализации – это просто особый способ записи программных выражений – из частей, каждая из которые, к тому же, сама может быть программным выражением (уже записываемом в обычном, для таких выражений, формате).
Поэтому, лично я воспринимаю всё, что написано в фигурных скобках как программный код (либо в виде «потока инструкций» либо в виде «выражения»). И то и другое – требует специфического (контекстного) лексического разбора. Посмотрите как фигурные скобки разбирает современный язык – Kotlin.
А было бы так - вопросов бы не было
Функция МояФункция() &!Приватный&НаСервере&НаКлиенте&ВнешнееСоединение&ПовторноеИсп-ользование&ВозвращаемыйТип(Число(1,0))
{ возврат 1; }
С точки зрения формальной логики вы правы, но читая как человек, приходишь к мысли, что ты ведь не машина...
Почему же – как раз расположенный справа сложный набор команд препроцессора и компилятора уедет за пределы беглого взгляда при анализе кода, и не будет отвлекать от более важного – определения самой функции и её API. Об этом выше я написал уже.
П.С. много сотен лет ученые мужи создавали разные методики формальной записи знаний, в том числе и алгоритмов... но самые совершенные из этих способов оказались слишком не человеческими... вот мы и балансируем теперь где-то на грани, между формальным и человеческим... идеальной модели не будет... идеально будет, когда машина станет понимать человеческую речь с достаточной точностью... но до этого еще далеко... да и может плохо кончиться :)
Языки программирования пока далеки от литературной речи. И на данный момент являются просто прослойкой между программистом и бинарным кодом инструкций процессора (а точнее – в актуальном мире, чаще всего, между промежуточным машинным языком или байткодом; хотя есть и чисто интерпретируемые языки – у которых интерпретатор на лету превращает текст программы во внутренние инструкции, вызывая в дальнейшем те или иные встроенные функции).
А насчёт понимания машинами человеческой речи – лично я не думаю, что именно эта технология что-то кардинально изменит во взаимодействии с программистом. Тут могут только два этап эволюции:
Появятся AI смарт-помощники в IDE, которые будут на лету анализировать что пишет программист (в т.ч. с углублённым статистическим анализом), и сразу предлагать готовые решения завершения отельных блоков кода. И выполнять другие строго заданные сервисные функции (основанные на поиске по базе знаний и заложенным схемам действия).
И да – для всего этого будет активно применяться живое общение (устное и письменное). Ждать наступления этой эры уже не так уж долго – думаю в Visual Studio это появится (в таком объёме) уже к середине века (а сам смарт-ассистент там появится уже к 2030 году ну максимум в 30-х годах; в 20-х годах его будут «отлаживать» в офисных продуктах – это уже почти 100% точно). Но по сути – это всё ещё будет просто инструменты, упрощающие ввод и изменённые текста. И это просто будет часть редактора.
А, вот, когда AI сможет, на основе хотя бы формализованного тех задания, самостоятельно генерировать текст программы (уже без участия программиста). То настанет новый этап эволюции компьютерных систем. Программисты тут уже почти не будут писать программный код (вернее останется ниша низкоуровневого программирования – для формирования некоторых библиотек, которые далее будет использоваться искусственным интеллектом). Высокоуровневый код (для бизнес-логики) – будет создаваться людьми все реже и реже – в основном только тогда, когда в каких-то областях AI ещё не поднатаскается – но он быстро будет это всё навёрстывать.
Практически 100% всего прикладного кода и решать почти все прикладные задачи – и такие программисты будут уже не востребованы.
К XXII веку AI активно перетянет на себя большую часть всех сфер занятости людей (по крайней мере, не требующих физического труда – да то, проблемы будут лишь в ограниченных областях).
Суть сказанного в том, что по сути нет нужды создавать уж очень «человечный» синтаксис языка, в смысле – более похожий на человеческую речь. На первом этапе это скорее даже будет мешать (перегружая глаза и мозг лишней информацией). А на втором этапе – уже и не особо нужно будет – описательные языки – это всё-таки не языки программирования. Ну а далее – и вовсе не будет нужно – там AI сами будут в процессе общения с ними создавать и выполнять алгоритмы (уже не прибегая даже к языкам программирования).
Ну вот, хотел написать коротко – а всё равно вышел очень длинный ответ
