почему в «современных» языках программирования нельзя изменять строки...

Иммутабельные структуры данных упрощают программирование: если ты принял строку в качестве параметра, ты можешь сохранить её указатель. Если же строка мутабельная, ты должен её скопировать, иначе у тебя нет контроля над тем, чтобы её никто не менял. Ну и многопоточность. Мутабельные строки обычно тоже есть, но по понятным причинам пользуются меньшей популярностью.

Потому, что юникод и там уже это не так легко сделать, а сейчас обработка текста чаще всего требует именно юникода.

Ну вообще говоря UTF-8 никак не мешает этому. Просто в отдельных случаях будет реаллокация байтов. Но во многих случаях, скорее всего, будет in-place замена, т.к. чаще всего меняют символы той же длины или in-place замена + перемещение хвоста строки. Более того, можно даже хвост не перемещать, если забить неиспользуемые байты какими-нибудь специальными значениями. Т.е. реаллокация будет тогда и только тогда, когда мы заменяем, например, латинскую букву русской.

Но этого же никто не гарантирует, а если длина поменялась, то нужно реалокацию делать со всеми вытекающими. Да и для любителей менять символы есть byte array, просто в сишечке так сложилось, что и byte array и строки имеют один и тот же тип char*, хотя суть у них ну совсем разная. С тех пор и тянется.

В UTF-32 по-прежнему за константу.

UTF-32 это уже `Vec<char>` (нет, не тот `char`, что в С).

константа это code point. А осмысленные символы могут состоять из более чем одного code point-а. Например эмодзи «нубийская принцесса» может состоять из всмопогательного code point-а, обозначающего чёрный цвет и эмодзи «принцесса». Если ты заменишь принцессу на букву «A», получится чушь: менять нужно оба code point-а.

AHAHAHAHAHAHA, OH WOW.

You're so stupid.

...а в старичках C и C++ — можно?

В Perl тоже.

http://stackoverflow.com/questions/3395117/are-perl-strings-immutable

Это очень вырожденный пример, и все равно можно посмотреть, не идет ли диакритика после символа, и это все равно асимптотически ~константа (плевать на залго). А перед этим еще и NFC прогнать.

Попробуй например на asm-е безопасно поменять произвольную строчку на 123 и узнаешь ;)

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

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

Это касается вообще любого объекта, не только строки.

Мутабельные строки обычно тоже есть,

Есть, но далеко не везде, а только в Ъ-ООП, в основном, где все есть объект.

но по понятным причинам пользуются меньшей популярностью.

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

они чо, тупые? модифицируется не literal constant, а переменная.

они тебе на это и намекают

Ты случайно меняешь содержимое списков в коде? Давно это у тебя?

Четырёхбайтного юникода хватит всем.

Это касается вообще любого объекта, не только строки.

Строка это встроенная структура данных. За отдельные объекты отвечают уже их создатели.

Мутабельные строки обычно тоже есть,

Есть, но далеко не везде, а только в Ъ-ООП, в основном, где все есть объект.

Я не сталкивался с языками, в которых их нет. Разве что JavaScript приходит на ум. Есть ещё примеры?

но по понятным причинам пользуются меньшей популярностью.

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

Совсем наоборот. Иммутабельные строки не дают никакого прироста перформанса. Дело в другом — иммутабельные строки позволяют писать более понятный и надёжный код.

Строка это встроенная структура данных

В тру любая структура данных — полноценный объект.

Я не сталкивался с языками, в которых их нет. Разве что JavaScript приходит на ум. Есть ещё примеры?

пистон тот же, большинство языков. Да и в джаве твоей это тоже фейк, насколько я понимаю. Там строки — это не настоящие объекты, в том числе и эти ваши билдеры, просто клоунада.

Совсем наоборот.

Ну, значит ты имеешь свое собственное мнение(TM) отличное от мнения экспертов. Молодец.

пистон тот же, большинство языков. Да и в джаве твоей это тоже фейк, насколько я понимаю.

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

Там строки — это не настоящие объекты, в том числе и эти ваши билдеры, просто клоунада.

В Java строки это настоящие объекты.

В Java строки это настоящие объекты.

можешь сделать вот так

"foo".bar=1

можешь сделать вот так

«foo».bar=1

Если бы у класса String было бы публичное поле bar, мог бы. Можешь сделать "".length() например.

Если бы

если бы да кабы, ага.

заодно, прикинь, как насчет вот этого

"foo".bar=1
"bar".appendProto("foo")// "bar" наследует от "foo"
"bar".bar //-->1

Ты не понимаешь просто, что такое полноценный объект, потому что в жабе вообще нет ООП, там только имитация его.

присвоение в пространстве имён имени foo объекту bar.

Сам то понял что сказал?)

"foo".bar=1
"bar".appendProto("foo")// "bar" наследует от "foo"
"bar".bar //-->1
TypeError: "bar".appendProto is not a function

Почему? Потому, что в JS строки — иммутабельные примитивы, а не объекты. «foo».bar по-прежнему undefined, кстати.

И да, даже в python не так, поскольку там строки всё же иммутабельные объекты, а не иммутабельные примитивы.

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

А я и не утверждал, что в JS строки объекты, это псевдокод был. Я про Io, говорил, в нем так. А в js целая куча примитивных типов, обсуждали уже.

Но это не значит

значит. Насколько я понимаю, в питоне строки такие же примитивы, с какими-то там ньюансами, это сути не меняет. Примерно то же самое, что и в JS по большому счету.

Насколько я понял, он говорит о том, что для ООП смысл слова «присваивание» вообще теряется, по большому счету. Когда мы пишем foo=bar, это с точки зрения ООП означает «отправить объекту global сообщение setSlot с адресом такого то объекта» дальше, объект global получив сообщение, связывает (если посчитает нужным) в своем адресном пространстве идентификатор «foo» c расположением данного объекта.

Насколько я понимаю, в питоне строки такие же примитивы

Нет, в python абсолютно всё есть объект без всяких оговорок, пока ты не выходишь за рамки cpython.

Лол. Обосрался — притворись, что так и хотел. В этом весь анонiмус

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

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

И, если уж рассуждать глобально, ни в питоне не в JS вообще нет полноценных объектов. Семантика сообщений предполагает, что объект сам решает, что делать с сообщением. Следовательно, должны быть ленивые вычисления искаропки. Например, ты можешь средствами языка реализовать кастомный if-then-else. Ни в пистоне ни в js этого нет(не считая костыли на проксях), так что не надо тут про «полноценность» заливать.

Кстати в ruby удобству отдаётся предпочтение перед ООП, например, тот же yield. Так как изначально создавался для простых работяг программистов, а не школьников, надрачивающих на трушность решений.

Иммутабельные объекты уже не объекты? Нифига себе новости. В том же JS достаточно скастовать seal на объект и он объектом перестанет быть?

Нет никакого смысла навешивать свойства на иммутабельный объект, поскольку все его инстансы должны быть равны.

Ни в пистоне ни в js этого нет(не считая костыли на проксях), так что не надо тут про «полноценность» заливать.

Ты про __getattr__/__setattr__, которые в python уже фиг знает сколько и покрывают все юзкейсы проксей?

Можно и так сказать, но самому объекту bar про имя foo ничего неизвестно, оно ему не присваивается.

Он не только в муттабельность, он и в наследование не умеет. Чем он тогда вообще отличается от примитива?

Ты про __getattr__/__setattr__, которые в python уже фиг знает сколько и покрывают все юзкейсы проксей?

Нет Я вот про это

myif := method(
  args := call message arguments
  if(doMessage(args at(0)), doMessage(args at(1)), doMessage(args at(2)))
)

myif(true, write(1), write(2))
myif(false, write(1), write(2))

//12

В JS и пистоне аргументы всегда выполняются, объект не имеет над ними контроля. А это не отвечает требованию о том, что объект сам волен решать, как ему поступать с пришедшим сообщением.

Он не только в муттабельность, он и в наследование не умеет. Чем он тогда вообще отличается от примитива?

В наследование вполне умеет. Более того — сам тип str обладает классом-родителем.

В JS и пистоне аргументы всегда выполняются, объект не имеет над ними контроля. А это не отвечает требованию о том, что объект сам волен решать, как ему поступать с пришедшим сообщением.

Эмм. Это вопрос синтаксиса и макросов. Объекту приходит уже результат.

методы остаются first-class и живут в рантайме.

Ты ничерта не понимаешь, что такое макрос.

В наследование вполне умеет. Более того — сам тип str обладает классом-родителем.

Ну так и в JS все то же самое, толку только с этого мало.

Объекту приходит уже результат.

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

Ты ничерта не понимаешь, что такое макрос.

возможно. Зато я понимаю, что они сосут. В Ъ - лиспах были fexpr'ы, а макросы — это отрыжка, суррогат.

write(1), write(2)

Тут ты выполняешь эту фигню. Хочешь отправить объекту — отправляй что-нибудь вроде (write, 1), (write, 2) чтобы он сам их и запускал. Ты откроешь... функции как объекты первого класса в противоположность к макросам.

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

это обычные лисповские фекспры. которые стали не модными.

Ты ничего не понял. Эту фигню, как ты выразился, и так запускает сам объект

там всего 4 вызова, из них выполнилось только 2

Эмм. Так умеет любой язык с функциями 1 класса. К объектной ориентации не относится никак.

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

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

Я твои фантазии не распарсил, извини. Замечу лишь, что сообщение — это отдельный тип, если чо.

В хаскеле можно, но надо заморочиться со State Monad.

Я еще раз повторю, на всякий случай

В JS и пистоне (в которых первоклассные функции) аргументы всегда выполняются, объект не имеет над ними контроля. А это не отвечает требованию о том, что объект сам волен решать, как ему поступать с пришедшим сообщением.