собственно нужно ли в 1с добавить возможность необязательного определения типа переменной

функция СоеднитьСтроки(перваяСтрока:Строка, ВтораяСтрока:Строка):Строка
возврат перваяСтрока+ВтораяСтрока;
КонецФункции

соответственно код СоеднитьСтроки(1,"") не скомпилируется!

что будет с кодом, если нужен составной тип из пяти справочников и трех документов?

просто не указываешь

но если очень надо четко ограничить то перечисляешь все.

Если бы они были нужны, то их бы уже сделали.

(3) в питоне 3.0 сделали относительно недавно

тут меня пугает мысль что 1с в 9.0(8.4?) сделает жесткую типизацию для обеспечения компиляции и соответственно выигрыша в скорости раз в 10 (на серверном коде)

(4) вот как сделает - так и будем репу чесать.... а пока - не паримся

(0)
Было бы хорошо, я только за. К примеру TypeScript же не зря появился, крупные проекты на голом javascript уже стало невозможно писать.
Заодно исчезли бы эти костыли для интеллисенса, в виде

#Если клиент и не клиент
   таб = Новый Таблица;
#КонецЕсли

6+ Тот же Angular2 на TypeScript
https://vsavkin.com/writing-angular-2-in-typescript-1fa77c78d8e8#.5x65uatmh

(4) В Питоне как и в TypeScript для Intellisense и контроля синтаксических ошибок

(3) Они нужны. Очень ускоряют написание кода за счет Intellisense  и уберегает от ошибок

В семерке
Перем тз; //:ТаблицаЗначений


часто используется

(4) не будет выигрыша

(0) Я первым пунктом указал
Кто что хочет от 1С

(8) В снегопате уже есть именно эта фича.
Intellisense для параметров процедур/функций

Можно здесь хотелку для снегопата попросить: сделать пункт контекстного меню - "Типизировать переменную для Intellisense" с выбором возможных типов, который добавляет эту конструкцию?

(0) современные пртги 2 и "2" не отличать
Поэтому должно скомпилиться

Типизацию добавить с "use strict" ? Зачем?

(14)+ Да еще и в паскаль/дельфи стайл почему то... Логичнее в VB стайл тогда


функция СоеднитьСтроки(перваяСтрока как Строка, ВтораяСтрока как Строка) как Строка
   возврат перваяСтрока+ВтораяСтрока;
КонецФункции


Функция Печать(Ссылка как Документ.РеализацияТоваровУслуг) как ТабличныйДокумент Экспорт




да ну накуй...

Паскаль детектед

В (0) в смысле
У вас-то бейсик

хотя, пуркуа бы и не па, собственно?.. В принципе нормально.

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

Тип.ТабличныйДокумент Печать(Тип.ДокументСсылкаРеализацияТоваровУслуг Ссылка)

и от процедур наиух отказаться

Во-во, процедуры зло

Делегаты еще нужны

(12)
Попробую

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

+(26) как в js

Вот кстати, работа Visual Studio Code c TypeScript'ом, к которому подключены описания типов от 1С, примерно на 1:05 явная типизация переменной.
https://www.youtube.com/watch?v=vJnZPLe67Aw

да вообще - нах всё, пусть вместо языка 1С будет js

+(29) и я всё прощу

(29) Лучше TypeScript

(31) да пох, пусть TypeScript

Действительно пофих TypeScript|JavaScript ибо одно в другое штатно компилится

Но идея сделать фреймворк 1С в стиле фреймворка .Netи разрешить писать на любой языке из списка (причем конвертер из коробки между языками)...

(34)+ Общими будут только описание структуры метаданных/базы данных и формочек на xml/json

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

(34) не-не-не, дэвдблэйн! Пусть - как щас, но с js|ts и всё. Остальное все не надо, остальное все хорошее.

(36) Ну MS то сделал для зоопарка языков (C#, VB.Net, J# etc) под CLR

(37) Так оно и будет как счас в виде конфигуратора, просто если хочешь то можешь конфигуририть прямо в текстовых файликах

(37) открой для себя унпак - конфигури в текстовых файликах

(38) так сперва сделали виртуальную машину. А потом на них языки натянули. С 1С - ситуация обратная.

(41) да там переписывать просто доуя ))

(40) да в курсе, но проблема что сначала приходится назад собирать в конфу и только потом на запуск/отладку

вот было бы как в nodejs где оно сразу

(35) Неее. TypeScript в JavaScript, а вот обратно нет.
Вернее можно, но все типы будут any. Ну и интерфейсы и прочая лабуда в JavaScript отсутствует. Хотя нужно смотреть новые версии

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

Делегаты это вообще кошмар нета.....
того, кто их придумал надо .... (плохое сделать)

лучше функции высших порядков

Добавление определения типа позволяет избежать ошибок на стадии написания кода, когда вместо одного значения в функцию передаётся другое.
Конечно, если писать префикс типа в имени переменной, то никакого определения типа не нужно.
Просто, описание составного типа через {Тип1,Тип2} будет выглядеть не очень удобно из-за того, что типы в 1С очень длинные.

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

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

Кому нравится ригидность и контроль - тайпскрипт, для адептов самодисциплины - джиэс.

(49) плюсану. Ситуаций, когда вместо нужного типа передается ненужный, лично у меня по пальцам пересчитать.
А вот об отсутствии возможности внутрь цикла по обработке чего-нибудь передать вместе с объектом для обработки еще и  указатель на функцию, которой надо этот объект обработать,  - день через день скучаю. И плачу кровью, когда приходится писать ЕслиТоИначеЕслиТоБлятьИначеГоспадиЁбтвоюМать

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

(51) Выполнить медленно!

(52) Ну, естественно, сначала компилляется, а потом исполняется, но, вся конвертация на нём написана.

P.S. а ещё очень хочется функция с переменным числом параметров, чтоб не пихать их в массив перед функцией.

(53) тогда именованные картежи (если имена не указаны, то обращение как к массиву)
a={1,2,3,4}

мояфункция(а) эквивалентно мояфункция(1,2,3,4)
а вообще для этого есть фиксированные структуры.

(53) Ааа тоже понял прелести js ))

(55) Я на нём писал, ещё когда восьмёрки не было, и "переменное число параметров" это единственное, что в нём хорошего - по всему остальному - это очень грустно.

(56) Ну JS тоже развивается и сейчас это совсем не те скрипты что были когда то.

(56) я на 1с писал когда еще 8 не было, 1с унылое гуано (для некоторых разъяснение - это ирония)

посмотрите с++ 17 по удобству он сильно догнал встроенный язык 1с.

(47) Можно добавлять синонимы.
(53) Это и в C? params есть.
В 1С можно использовать параметры по умолчанию
(57) Но типизацию пока не вводят. TypeScript компилируется  в JS нужной версии.
Но на самом деле WebAssembly
https://habrahabr.ru/company/infopulse/blog/304362/

Может вытеснить JS

(47) "Лучше бы сделали определение дочерних типов, чтобы можно было задать числовой тип, скажем, Цена и везде его использовать, а когда нужно будет поменять разрядность, просто поменять в определении типа."
Так есть же. Определяемые типы.

(0) Не вижу смысла

(50)
Это пока работаешь один над не очень большим проектом. А когда проект большой, да несколько разрабов разного уровня - проще как-раз типизировать.

(0) Если Ложь Тогда док=Документы.ПриходнаяНакладная.ПустаяСсылка; КонецЕсли

Все хинты после этого начинают работать...

(63) если у тебя на 1С большой проект на несколько разрабов, то проще у тебя уже не будетт. Всё твое проще уже было...

(65)
Ну, в-принципе соглашусь, в том ключе, что добавлять в 1с ТОЛЬКО одну типизацию, не добавляя остальных плюшек (хотя бы интерфейсов, наследования и виртуальных методов) - мало что даст. Как говорится, "к полумерам не привык".

занафейкуя?

Функция СоеднитьСтроки(перваяСтрока, ВтораяСтрока)
  возврат ""+перваяСтрока+ВтораяСтрока;
КонецФункции

Ни?

Начать можно с самого полезного - опциональная типизация при передаче параметров.

Например
РассчитатьСумму(ВалютаНовая, Сумма:Число, ВалютаСтарая)
Т.е. для железно известных типов мы их указываем и интерпретатор и синтакс-контроль выдают ошибки проверки типа в этом.

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

Например, когда сначала присваивается строка, потом число, а потом ссылка. Такого же почти не бывает?

(67) Угу. При этом если перваяСтрока будет не строка, то получим строковое представление, что иногда не соответствует ожиданию.

Интерес же больше представляет классы

КлонироватьТз(ТзОриг:ТаблицаЗначений): ТаблицаЗначений

Ты сразу получаешь Intellisense  и синтаксическую проверку методов итд.
  Это значительно ускоряет написание кода и отладки за счет синтаксической проверки.

(70)

Если Ложь Тогда тзОриг = Новый ТаблицаЗначений; КонецЕсли;

После этого набор тзОриг и точки выводит все контекстные подсказки именно по таблицам значений.

На месте 1С я бы ввел ключевое слово Типизация:

Типизация тзОриг ТаблицаЗначений;

С этой же целью... А то "Если Ложь" выгладит как-то неаккуратно.

Лучше бы преобразование типов как в семерке сделали (хотя бы опционально)

(71) Это понятно, но все это через одно место.

Типизация в методе лучше
КлонироватьТз(ТзОриг:ТаблицаЗначений): ТаблицаЗначений


Так же можно и типизацию вводить

тз:ТаблицаЗначений=ВызватьНетипизированнуюФункцию();


Все придумано давно

Или
Тз=ТаблицаЗначений(ВызватьНетипизированнуюФункцию());