Подтвердить что ты не робот

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

Каждый язык программирования, который я знаю (Perl, Javascript, PHP, Python, ASP, ActionScript, Commodore Basic) использует одиночные и двойные кавычки для разграничения строк.

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

Почему языки программирования не используют какой-либо другой символ для разграничения строк, который не используется в обычном разговоре \, | или {}, например), чтобы мы могли просто продолжить свою жизнь?

Это правда, или я что-то не замечаю? Есть ли простой способ остановить использование кавычек для строк на современном языке программирования?

print < < END
Я знаю о синтаксисе здесь document, но для незначительных манипуляций с строками он слишком сложный и усложняет форматирование.
END;

[ОБНОВЛЕНИЕ]. Многие из вас хорошо высказались о важности использования только символов ASCII. Я обновил примеры, чтобы отразить это (обратная косая черта, и фигурные скобки).

4b9b3361

Ответ 1

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

"""like this"""

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

q^ like this ^

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

Ответ 2

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/!;

Ответ 3

Ток: метки пишущей машинки "quotation"

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

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

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

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

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

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

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

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

Ответ 4

У Python есть альтернативный разделитель строк с тройной двойной цитатой "" Some String "" ".

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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

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

В принципе, я действительно не понимаю, почему это проблема. Действительно ли это так? Я имею в виду, что в C вам часто приходится использовать\%и\​​и несколько других двухсимвольных символов, поэтому... Meh.

Ответ 8

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

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

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

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.¤

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

Ответ 9

А, так что вы хотите старомодный FORTRAN, где вы цитируете, подсчитывая количество символов в строке и вставляя его в формате H, например: 13HHello, World!. Как кто-то, кто сделал несколько вещей с FORTRAN еще в те дни, когда имя языка было все шапки, кавычки и побег из них - хорошая вещь. (Например, вы не полностью привинчены, если вы отключены одним из ваших символов персонажа.)

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

Ответ 10

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

Ответ 11

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

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

Ответ 12

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

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

Так что не совсем ясно, что это победа, а затем сила привычки.

Ответ 13

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

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

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

Ответ 14

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