Имеет ли терминология программирования встроенную тенденцию от ясности?

Question

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

То есть, за исключением терминологии. Дело не в том, что есть много жаргонного слова (которое приходит с изучением любого нового языка / технологии), а в том, что используемые термины кажутся либо неуклюжими, неясными, либо излишне сложными. «Массив» кажется довольно простым для объяснения кому-то только из-за его названия, по сравнению с, скажем, множеством IEnumerable.

Но это выходит за рамки определенного языка / платформы. Возьмите ниже:

• функции / подпрограммы и методы
• ошибок и исключений
• временные таблицы против общих табличных выражений
• пользовательские таблицы и схемы (в SQL Server)

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

Итак ... Все ли "хорошие" названия уже взяты?

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

Или я совершенно неправ, и мое сознание просто извращено от изучения Бейсика в детстве (согласно Дейкстре)?

Answer 1

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

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

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

Answer 2

Большинство этих слов не имеют одинакового значения. Если вы возьмете функцию против метода:

A function , насколько я понимаю, это нечто стоящее в одиночестве с использованием императивного языка, такого как C, или функции JavaScript, которая не связана с объектом.

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

Answer 3

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

Как вы сказали, все эти термины не являются точными синонимами, каждый из них означает что-то свое. Например, «список» (для меня) подразумевает связанный список, где я могу иметь повторяющиеся значения. «Массив» подразумевает, что я не могу иметь повторяющиеся значения. Другие языковые люди не соглашались бы со мной здесь, вызывая противоположность того, что мы хотим в общении: паритет идей.

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

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

Слишком много "перегрузок":)

Answer 4

Или я совершенно неправ, и мое сознание просто извращено от изучения Бейсика в детстве (согласно Дейкстре)?

Да, это, вероятно, причина.

Answer 5

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

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

Answer 6

Я думаю, это очень сильно зависит от сообщества разработчиков.

Например, PHP практически не содержит жаргонных слов. Вероятно, это связано с тем, что php-сообщество заинтересовано в том, чтобы получать страницы в браузере, а не думать о чем-то «оригинальном», чтобы добавить их в тезис.

У Perl есть свой собственный странный, но ясный жаргон («благослови этот объект»?), Который, вероятно, является отражением того, насколько отчетливым и причудливым является Ларри Уолл.

C ++ и Java, вероятно, являются худшими нарушителями для «изобретения новых слов для колеса». «Упорство», вероятно, худший пример; действительно ли нам нужна еще одна терминология для «записи в файл». Вероятно, это связано с большим количеством членов сообщества Java / C ++, которые пытаются придумать «оригинальные» темы для них, а не как выводить страницы в браузер.