Является ли венгерская запись обходным решением для языков с недостаточно выразительной статической типизацией? [закрыто]

В статье Эрика Липперта Что случилось с венгерской нотацией? Он заявляет, что цель Венгерской нотации (хороший вид) состоит в том, чтобы

расширить понятие «тип», чтобы охватить семантическую информацию в дополнение к информации представления представления.

Простым примером будет префикс переменной, представляющей X-координату с «x», и переменной, представляющей Y-координату с «y», независимо от того, являются ли эти переменные целыми числами или числами с плавающей запятой или чем-то еще, так что при случайной записи xFoo + yBarкод явно выглядит неправильно.

Но я также читал о системе типов Haskell, и кажется, что в Haskell можно сделать то же самое (то есть «расширить концепцию типа, чтобы охватить семантическую информацию»), используя фактические типы, которые компилятор проверит для вас. Таким образом, в приведенном выше примере xFoo + yBarв Haskell будет невозможно выполнить компиляцию, если вы правильно разработали свою программу, поскольку они будут объявлены как несовместимые типы. Другими словами, похоже, что система типов Haskell эффективно поддерживает проверку во время компиляции, эквивалентную венгерской нотации

Итак, является ли венгерская нотация просто вспомогательным средством для языков программирования, чьи системы типов не могут кодировать семантическую информацию? Или венгерская нотация предлагает нечто помимо того, что может предложить статическая система типов, такая как Haskell?

(Конечно, я использую Haskell в качестве примера. Я уверен, что есть другие языки с аналогично выразительными (rich? Strong?) Системами типов, хотя я не сталкивался ни с какими.)

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

Я бы сказал "Да".

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

1. Эта информация важна.
2. Эта информация не важна.

Давайте сначала начнем со случая 2: если эта информация не важна, тогда венгерская нотация - это просто лишний шум.

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

Что возвращает нас к цитате Эрика Липперта:

расширить понятие «тип», чтобы охватить семантическую информацию в дополнение к информации представления представления.

На самом деле, это не «распространение концепции типа», что является понятием типа! Вся целью типов (как инструмент проектирования) является кодирование семантической информации! Представление хранения является деталью реализации , которая обычно не относится к типу на всех . (И, в частности, язык ОО не может принадлежать типу, поскольку независимость представления является одной из основных предпосылок для ОО.)

Все назначение типов (как инструмента проектирования) - это кодирование семантической информации

Мне понравился этот ответ, и я хотел продолжить этот ответ ...

Я ничего не знаю о Haskell, но вы можете выполнить что-то вроде примера xFoo + yBarна любом языке, который поддерживает некоторую форму безопасности типов, такую ​​как C, C ++ или Java. В C ++ вы можете определять классы XDir и YDir с перегруженными операторами «+», которые принимают только объекты своего собственного типа. В C или Java вам нужно будет выполнить добавление, используя функцию / метод add () вместо оператора «+».

Я всегда видел венгерскую нотацию, используемую для информации о типе, а не семантику (за исключением того, что семантика может быть представлена ​​типом). Удобный способ запомнить тип переменной в те времена, когда раньше «умные» редакторы программирования, которые так или иначе отображали тип для вас прямо в редакторе.

Я понимаю, что фраза «Венгерская нотация» стала означать нечто иное, чем оригинал , но я отвечу «нет» на вопрос. Именование переменных с семантическим или вычислительным типом не делает то же самое, что типизация в стиле SML или Haskell. Это даже не бинт. Взяв C в качестве примера, вы можете назвать переменную gpszTitle, но эта переменная может не иметь глобальной области видимости, она может даже не представлять собой точку для строки с нулевым символом в конце.

Я думаю, что более современные венгерские нотации имеют еще большее отклонение от строгой системы вывода типов, потому что они смешивают «семантическую» информацию (например, «g» для глобального или «f» для флага) с вычислительным типом (указатель «p», « я "целое число, и т. д.). Это просто заканчивается как нечестивый беспорядок, когда имена переменных имеют только смутное сходство с их вычислительным типом (который изменяется со временем), и все они выглядят настолько похожими, что вы не можете использовать" следующее соответствие "для найти переменную в определенной функции - они все одинаковы.

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

C, потомок BCPL, имеет различные типы для целых чисел, указателей, символов и т. Д. Это в некоторой степени лишает базовую венгерскую нотацию (вам не нужно кодировать имя переменной, если это int или указатель), но семантика за пределами этого уровня все еще не может быть выражена как типы. Это привело к различию между тем, что было названо «Системы» и «Приложения» венгерским. Вам не нужно было указывать, что переменная была int, но вы могли использовать кодовые буквы, чтобы указать, является ли int, скажем, координатой x или y или индексом.

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

Например, в известной статье Джоэлса, в которой хвалят Apps Hungarian, он использует пример префикса usдля небезопасной строки и sдля безопасной (закодированной в html) строки, чтобы предотвратить HTML-инъекцию. Разработчик может предотвратить ошибки внедрения HTML-кода, просто тщательно проверив код и убедившись, что префиксы переменных совпадают. Его пример в VBScript, ныне устаревшем языке, который изначально не допускал пользовательских классов. В современном языке проблема может быть исправлена ​​с помощью пользовательского типа, и это действительно то, что Asp.net делает с HtmlStringклассом. Таким образом, компилятор автоматически найдет ошибку, что намного безопаснее, чем полагаться на человеческое зрение. Очевидно, что язык с пользовательскими типами исключает необходимость использования «Apps Hungarian» в этом случае.

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

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

По сути, нам нужны какие-то строго типизированные typedef для уничтожения полностью венгерской нотации на этих языках (UoM в стиле F # также может это сделать)

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

В те мрачные дни было полезно узнать, какой тип переменной, где она используется. При правильном обслуживании (БОЛЬШОЙ, если из-за отсутствия инструментов рефакторинга) венгерская нотация дала вам это.

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

Правильный!

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

Дополнительные "я", "д" и "?" префиксы просто делают код менее читабельным и могут вводить в заблуждение - например, когда «коровник» меняет тип iaSumsItems с Integer на Long, но не беспокоит рефакторинг имени поля.