Динамическая или статическая типизация?

Не интересно...

я за венгерскую нотацию

Все что нужно знать о статической типизации:

CurrentKeyByte := byte(PTR(THandle(Key) + j)^);

В С++ все еще жесче.

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

var

  ТипВариантыГенерацииЗаданийНаСканирование: OleVariant;
  LocalDispatch: OleVariant;
  ЭтоГенерацияПоСтрокам: Boolean;
  ЭтоГенерацияПоОтветственнымИНоменклатуре: Boolean;
  ЭтоГенерацияПоОтветственным: Boolean;
  ЭтоГенерацияПоТипамМарок: Boolean;
  ВыборкаПервыйУровень, ВыборкаВторойУровень, ВыборкаТретийУровень: OleVariant;
  ОбходРезультатаЗапросаПоГруппировкам: OleVariant;
  НовоеЗадание, ВыборкаТовары, СтрокаЗадания: OleVariant;
  РезультатПроведения, АСФОбщегоНазначения, АСФОбщегоНазначенияКлиентСервер
    : OleVariant;
  ДокументМенеджер: OleVariant;
  ПредставлениеДокумента: String;
  ИменаКолонокСвертки: string;
  ТаблицаРезультата, ТаблицаСвертки, СтрокаСвертки, СтруктураПоиска,
    МассивСтрок, ТекущаяТаблицаРезультата: OleVariant;
  i, Count: integer;
  СоответствиеЗаданийПоРежимамСканированияDataMatrix: OleVariant;
  РежимСканирования: integer;
  ЭтоПерезаполнение: Boolean;
  ЗаданиеСсылка: OleVariant;
  ЗапрещенПодборАналоговСерии, СканироватьEANПриОтборе,
    ЕстьНемаркируемаяПродукция: Boolean;
  АСФПодсистемаТСДПереопределяемый, КолонкаТаблицыРезультата,
    СтрокаТаблицыРезультата, ВидыАПНеМаркируемые: OleVariant;
  МассивНоменклатур, МассивВидовЭлементовТМЦ, СоответствиеВидовАП,
    ТипалкВидыЭлементовТМЦ, СоответствиеВидовНоменклатуры: OleVariant;
  ЭтоКонфигурацияАСФ, ЭтоКонфигурацияСемействаКТ2000,
    ЭтоКонфигурацияСУчетомЕГАИС1С: Boolean;
  АСФОбщегоНазначенияПовторноеИспользование, СтрокаТаблицы, ВидПродукцииАП
    : OleVariant;
  РезультатПоиска, ВидНоменклатуры, ВидЭлементаТМЦ: OleVariant;

(4) Это на какой дельфи написано что кириллица в именах переменных?

(5) На любой с поддержкой unicode, где то с середины 2000-[

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

Ошибок нубских меньше когда переменная не того типа, явное приведение, хз что не нравится в (3)

(5) Имена переменных, функций. Юниты не пробовал, но наверное тоже работает

(6) (8) В таком стиле на кириллице я на Java и C# писал да, а вот на Delphi почему то нет.
Вероятно потому что Delphi 7 юзал обычно до Lazarus.

(7) меня всегда забавляло когда (a!=b) не равно (a!==b)

(10) Таки да все логично в одном случае сравниваются значения а в другом указатели

(7) Особенно весело, когда меняется тип в среде.
Ну, например, размерность адреса с 4 байт до 8 и ты должен все свои Cardinal на THandle при работе с памятью поменять.

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

(12) Бывает. Особенно последнее что ну никто же код 1С77 не пытаются на 8-ке да?

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

(13) Не пытается. Но 8ка стабильна уже 17 лет, монолитна, охеренна и обратно совместима.
Ты попробуй какой-нибудь код 2005 года запустить на любой современной среде разработки.

Вообще или в 1С? И именно статическая или просто строгая?
В 1С строгая нафиг не нужна. А вообще статическая для меня более ламповая. Строгость, ближе к бинарному коду - вот это все. Но это чисто эстетически, так сказать.
Если быстро что-то залампичить на "клеевом" уровне - проклянешь. Окупается только на больших и серьезных проектах или проектах с особыми требованиями.
А на скриптовых языках ака 1С строгость при необходимости можно добавлять по вкусу. Как с тем же js было. Статическими они от этого ессно не станут.

За нее.

либо ты умеешь готовить плов, либо не умеешь. а какая там типизация - дело второе.

кстати странно 1С революционного больше ничего не предлагает раньше 6.0 потом поколение 7.х далее 8.х которое затянулось...
слухов нет что ни будь новое готовят?

(11) не совсем, я имел в виду JS

(a!=b) - сравнение с приведением типов (например 1!="1" выдаст ложь, то есть он число считает идентичным строке)
(a!==b) - строгое сравнение с учетом типов (например 1!="1" выдаст истина, то есть он число не равным строке)

(19) 1С совершенна.

(19) Говорят, будет орфографический плагин, который исправляет "что ни будь" на "что-нибудь"

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

(15) TBlockSerial из тех годов на днях вполне успешно в ВК скомпилился

(22) ещё бы он исправлял опечатки в коде и помогал именовать переменные вида ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокументИмениНуралиеваБорисаГеоргиевича, то цены б ему не было.

(21) :-) только что посмотрел в 2002 году вышла первая бета версия восьмерки через пару лет будем 20 летие справлять:-), конечно платформа развилась сильно с тех пор, но подход остался прежним. С развитием современных конфигураций да и технологий уже чувствуется тормоза да и неудобство разработки.

(26) Поставь EDT если хочешь по настоящему потр...ться

(27)+ Особенно весело когда конфа типа ERP обратно изменения из конфигуратора грузишь в EDT

(27) уже ковырял правда давно, это извращение...

(28) так в том то и дело , пора что то совершенно новое делать, правда не уверен что 1с это надо им и так хорошо.Конкуренты особо не форсировано не лезут ибо рынок не тот.

(30) думаю нужно снимать слой абстракции в виде встроенного языка (хотя не знаю как и во что он сейчас преобразуется), думаю как вариант Java или Python + феймворк 1с чтобы проще с бизнес логикой и базами данных работать

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

(32) Дык EDT же

Я проголосую, но подозреваю что от этого голосования ничего не изменится

(32) Ты не поверишь, но это настраивается в обычном конфигураторе.

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

(35) Можно, пожалуйста, тыкнуть носом? Мне тоже интересна эта фишка.
Вроде тако только при приске видел.

(32) в Конфигураторе : Сервис - Параметры - Модули - Редактирование "Текущий идентификатор" и "Выбранный идентификатор"

(32) (37) http://iantonov.me/page/1spredprijatie-83-malenkaja-no-poleznaja-nastrojka-redaktora-koda-dobavljaem-podsvetku-vydelennyh-identifikatorov-koda

(38) (39) Ай спасибо!

(38) (39) спасибо!

(41) Дима, как ты жил без этого все эти годы? :) Если мне не изменяет память, то Андрей Габец на каком-то совсем новичковом курсе в самом первом занятии показывает этот трюк, иначе кодить тяжко - не видно ж ничего.

(42) я не хожу на новичковские курсы :)

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

до меня так и не дошло - что такое указатели и нафига вообще они нужны )))

в статической типизации самое страшное это дженерики

(3) и чо эта галиматья делает?

+(46) или это от балды

(46) привидение типов

(48) Привидение? Шматрочиком?

ОФФ:
Каких-то типов убили и из них получились отличные привидения)))

(48) Какое то странное приведение получилось. Как будто писалось методом тыка в 5 утра после бессонной ночи :)

хотя еж описал строгую типизацию. а статическая не всегда строгая

(35) Вот я, кстати, ума не приложу, почему это не настроено в стандартной палитре изначально. Только злой умысел в голову приходит :)

(52) да. байт приводить к байту это очень строго :)

(54) У вас плохо с Дельфи.

В (3) - получения байта данных из указателя со смещением.
Можно загнать все в TMemoryStream, конечно, но у тебя может и не быть Classes

(45) А чем дженерики то не угодили. Для ссылочных типов компилится один класс на все классы. Для валуе типов будет для каждого типа свой.
По поводу типизации например в TypeScript это аннотации. https://ru.hexlet.io/blog/posts/kak-ispolzovat-annotatsii-tipov-v-faylah-javascript
Типизация прежде всего удобна для интеллисенсе (когда методы длинные и не ошибиться), ну и контроль типов.
В том же C# есть dynamic. Я за смешанную и с утиной типизацией типа аннотаций

(55) что еще за указатели со смещением? нововведение какое то для Android?
А так работать не будет что ли?

CurrentKeyByte := PByte(Key + j)^;

.

(57) Естественно, будет. В (3) - просто пример того, как можно написать и это будет корректно.

(59) Ну галиматью писать можно и с типами и без типов

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

(61) Да прям. Это от языка зависит. Вот паскаль и си оба с типами, но в паскале так не извращаются как в си. Go тоже с типами, но там извращений нету почти. В JavaScript типизации строгой нету, но запутать могут похлеще чем сишники. Вот в 1С язык дубовый. Там всё просто и понятно.

(59) в (3) пример тех самых "Мудацких приведений"

(64) Да, именно.

Проблема не в типах,а в выделении под них памяти.
Статическая типизация от выделения памяти не совсем спасает,так как статический объект,это структура.

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

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

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

Опять же,в Си++ приведение типов работает куда лучше,чем в 1с - можно приводить строку в булево и будет работать,ах простите,строка в Си - это указатель на массив байтов или слов.

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

(0) статическая типизация это зло, которое приводит к костылям, навроде дженериков в джаве

В java типизация спасает?
А базовый тип object все очень любят использовать,чтобы запихать все,что угодно.

К сожалению,есть алгоритмы,где число и типы параметров определяются в процессе работы.

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

(68) интересно кто это любит в java использовать object? За такое вообще говоря руки отрывают.

Несмотря на то что я ща на питоне пишу, однозначно статическая

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

пофиг

Динамическая типизация ничего кроме тормозов и бардака не дает. Она появилась только от ленивости писать много буков. Если нужна скорость выполнения и порядок то статическая типизация, а если тяп ляп и готово, то питон.

(15) 8-ка и осталась на уровне 2005 г )))))

на самом деле,динамическая типизация и ее отсутствие это разные вещи.
в javascript даже толком проверить,что за обьект мы получили,сложно.
опять же,традиция java проверять на null,хотя тип обьекта задан и компиллятор не пропустит передать что-то другое.

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

(14) 1с это JIT-компилятор следовательно статическая типизация не влияет на производительность, поэтому и не нужна одинэсникам

я за

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

(74) Это вы вон, фузиновцам рассказывайте.

(78) удобно как раз динамически, мало букв. или как в (4) предлагаете

(80) удобно если речь идет о скриптах (например сборки) и фронтенде (например сайтах). В сложных проектах когда отсутствует типизация время доработок увеличивается в разы. А что еще хуже во столько же раз падает их надежность. Собственно поэтому серверная часть (бизнес-логика) на сложных проектах это практически всегда статическая типизация (Java / C# / C++). Хотя да, есть исключения, которые, правда, как правило подтверждают общее правило.

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

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

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

(81) "В сложных проектах когда отсутствует типизация время доработок увеличивается в разы. А что еще хуже во столько же раз падает их надежность"

А конкретный пример привести можешь? По-моему всё с точностью до наоборот, из-за жесткой типизации в трубу улетает туева хуча времени

(84) Узка твоя точка зрения. И страшно далека она от народа.

(85) примеры? Хочу увидеть конкретную ситуацию, когда жесткая типизация ускоряет скорость разработки

(86) Не. У меня бисер кончился. И апельсины тоже.

В той же джаве всё усыпано дженериками. Которые по своей сути являются попыткой убежать от жесткой типизации

(87) всё с тобой ясно

(3) а да ты пасквильщик!

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

(91) еще один кто путает статичность и строгость
Приведение типов не зависит от статичности

Глянем мультфильм

https://www.youtube.com/watch?v=CHkEX73P2Pk
он не про статическую типизацию, и даже не про ИТ. Но наглядно демонстрирует контраст, уживающийся рядом друг с другом. Что-то подобное со статической типизацией в Java. С одной стороны типы как бы статичные, с другой стороны легко можно послать лесом всю эту статичность, используя суперклас Object или дженерики

(86) Не понял вопрос. Как минимум скорость разработки увеличивается потому что не надо гадать что за параметр можно передавать чтобы не получить "Поле X не определено" (ну или по ошибке передать не тот параметр, но это уже к надежности, хотя если посмотреть с точки зрения того что ошибку надо исправлять возвращаемся к скорости).

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

(95) "скорость разработки увеличивается потому что не надо гадать что за параметр можно передавать"

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

Статическая типизация усложняет жизнь.
Особенно, в маленьких проектах.

(97) + я помню, когда-то давно писал программы на языке "С". Как нужно было изгаляться с этими указателями.

Я вот не помню, чтобы в сложном чужом проекте класса УПП я испытывал проблемы, что в процедуру не знал, какой тип передавать, ибо в комментах к процедуре есть описание всех ее параметров. Кроме того, иногда сознательно необходимо было передавать другой тип, например вместо ВыборкиИзРезультатаЗапроса Структуру.

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

(96) "подогнать нужный тип" это как? Типа "тупой, но очень сильный". Если вы передадите не тот тип вы с очень большой вероятностью получите ошибку поле не найдено. И скорее всего если у вас не подходит тип у вас какая та ерунда в архитектуре и вы рано или поздно но получите проблемы.