Почему популярные языки программирования не используют некоторый другой символ для разграничивания строк? [закрытый]

Ада не использует одинарные кавычки для строк. Они предназначены только для символов, и их не нужно экранировать внутри строк.

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

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

Компилятор должен быть достаточно умен, чтобы распознавать, что BigFoo не может быть преобразовано в IEnumerable , но это не так. Он просто видит, что это IEnumerable , и чувствует, что это потенциальный кандидат на перегрузку (даже несмотря на то, что ограничение, которое вы определили, заставляет T быть IFoo и int нельзя преобразовать в IFoo ). Хотя это неудобно, но это не так уж и важно. Просто приведите bigFoo к IFoo , и компилятор будет счастлив:

fooContainer.Add((IFoo)bigFoo);

Или же

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

А, значит, вам нужен старомодный ФОРТРАН, где вы должны цитировать, подсчитывая количество символов в строке и вставляя его в формат H, например: 13HПривет, Мир! . Как человек, который кое-что делал с ФОРТРАНОМ в те дни, когда название языка состояло только из заглавных букв, кавычки и их экранирование - это хорошо. (Например, вы не совсем облажались, если в вашем ручном подсчете символов не справились.)

Серьезно, идеального решения не существует. В какой-то момент всегда будет необходимо иметь строку, содержащую любой символ кавычки, который вам нравится. Для практических целей разделители кавычек должны быть на клавиатуре и легко доступны, поскольку они часто используются. Perl's q @ ...Синтаксис @ завершится ошибкой, если строка содержит пример каждого возможного символа. Константы Холлерита FORTRAN еще хуже.

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

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

Сравните следующее.

print "This is a simple string."
print "This \"is not\" a simple string."

print ¤This is a simple string.¤
print ¤This "is not" a simple string.¤

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

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

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

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

Python does have an alternative string delimiter with the triple-double quote """Some String""".

Single quotes and double quotes are used in the majority of languages since that is the standard delimiter in most written languages.

Perl позволяет использовать любые символы, которые вам нравятся

 "foo $bar" eq
 qq(foo $bar) eq
 qq[foo $bar] eq
 qq!foo $bar! eq
 qq#foo $bar# etc

Meanwhile
 'foo $bar' eq
 q(foo $bar) eq
 q[foo $bar] eq
 q!foo $bar! eq
 q#foo $bar# etc

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

 "http://www.example.com/foo/bar/baz/" =~ /\/foo/[^\/]+\/baz\//;
 "http://www.example.com/foo/bar/baz/" =~ m!/foo/[^/]+/baz/!;

Потому что эти другие персонажи вы указали не ASCII. Я не уверен, что мы готовы или нуждаемся в языке программирования в юникоде ...

РЕДАКТИРОВАТЬ: Почему бы не использовать {}, | или \, ну, все эти символы уже имеют значение в большинстве языков. Представьте себе C или Perl с двумя разными значениями для '{' и '}'!

| означает или, а в некоторых языках уже объединяет строки. и как бы вы получили \ n, если бы \ был разделителем?

По сути, я действительно не понимаю, почему это проблема. Неужели \ "ТАК сложно? Я имею в виду, что в C вам часто приходится использовать \%, \ и несколько других двухсимвольных символов, так что ... Meh.

Python позволяет вам смешивать одинарные и двойные кавычки, чтобы помещать кавычки в строки.

print "Please welcome Mr Jim 'Beaner' Wilson."
>>> Please welcome Mr Jim 'Beaner' Wilson.

print 'Please welcome Mr Jim "Beaner" Wilson.'
>>> Please welcome Mr Jim "Beaner" Wilson

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

print """Please welcome Mr Jim "Beaner" Wilson."""
>>> Please welcome Mr Jim "Beaner" Wilson

Наконец, вы можете печатать строки так же, как и все остальные.

print "Please welcome Mr Jim \"Beaner\" Wilson."
>>> Please welcome Mr Jim "Beaner" Wilson

Текущее: «Кавычки» "Пишущая машинка"

Есть много веских причин для использования кавычек, которые мы сейчас используем:

• Цитаты легко найти на клавиатуре - поэтому их легко набирать, и они должны быть простыми, потому что строки нужны очень часто.

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

• Цитаты бывают разных версий - одинарные кавычки, двойные кавычки, обратные кавычки. Таким образом, язык может назначать разные значения строкам, заключенным в разные кавычки. Эти разные кавычки могут также решить проблему «кавычек внутри» кавычек.

• Цитаты естественны - английский язык использовал кавычки для разметки текстовых фрагментов задолго до того, как последовали языки программирования. В лингвистике кавычки используются точно так же, как и в языках программирования. Цитаты естественны так же, как + и - естественны для сложения и вычитания.

Альтернатива: «типографически» «правильные» кавычки

Технически они лучше. Одним из больших преимуществ является то, что вы можете легко различать котировки открытия и закрытия. Но их сложно набрать, и они не в ASCII. (Мне пришлось поместить их в заголовок, чтобы они вообще были видны в этом шрифте StackOverflow.)

Надеюсь, однажды, когда ASCII станет чем-то, что волнует только историков, а клавиатуры превратились в нечто совершенно иное (если мы вообще будут вообще клавиатуры),

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

И если вы создание нового языка, выбор правильного символа для строковых кавычек, вероятно, является ПУТЬ в списке задач, которые необходимо реализовать.