Что происходит с популярностью Go?

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

Справедливости ради стоит сказать, что вы тут описываете проект/язык Oak, из которого появилась самая первая Java. Но уже начиная с Java 2 этот язык сильно изменили и начали делать именно как язык широкого назначения. Двойка во всех этих J2EE, J2SE, J2ME именно из Java 2 и эта двойка пережила немало более новых версий Java, что говорит о том, что Java 2 - самая база.

Надо рассказать это яваскриптёрам а то у них JavaScript в каждой дырке затычка.

Вы решили блеснуть умом и рассказать, что разреженный вектор не хранит ноль-значения физически

Вообще-то это был ответ на ваш вопрос.

я вам рассказал, что map также хранить ноль-значения не обязан.

А я вас об этом спрашивал или как-то протестовал против этого?

O(1) говорит о сложности

Не нужно растекаться банальностями. Даже когда хэш-таблица декларирует O(1) для доступа, это не то же самое что обращение к сишному массиву фиксированного размера по конкретному индексу. Как минимум, вам потребуется проверка коллизии с возможным переходом к другому элементу, если коллизия произошла.

Если же у вас немного данных, зачем вам что-то сложнее обычного массива?

Разряженные вектора применяют когда у вас пространство индексов измеряется десятками/сотнями миллионов (а то и миллиардами), тогда как элементов в нем на пару порядков меньше (но все равно не один-два).

А ваше решение не имеет никакой дополнительной стоимости?

Моего решения нет. Я хотел узнать, что должен был делать Go-программист имея на руках первые версии языка, если бы ему потребовалось, например, сделать свой разреженный вектор. Который мог бы хранить как short-ы, так и int-ы, так и double, так и, скажем, IPv6 адреса или UUID-ы.

Я говорил об использовании сторонней библиотеки.

Т.е. вы все еще про Go? А какая разница для Go-программиста используется ли в программе контейнер из стандартной библиотеки или из сторонней?

Причём тут язык программирования?

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

контуры будущей Java у Гослинга и Ко наметились уже в 1989-1991гг. Когда шаблонов в C++ по сути, еще не было, было только их описание от Страуструпа (по крайней мере в 1989 и 1990). Но когда шаблоны в C++ добавили, то Гослинг сотоварищи просто проморгали это революционное изменение в языке.

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

Но уже начиная с Java 2

А при чём тут Java 2, если речь идёт о заимствовании шаблонов из крестов в первую версию?

Ну да, не далее как вчера в коде на реальных данных всплыл data race, который не всплывал на тестах. Это все не считается, нужно верить тому, что hummer рассказывает.

Можете мне не верить, но и я не обязан воспринимать ваш пример в качестве аргумента. Качество ваших тестов мне неизвестно. Go, вы вообще не используете, то есть ваш пример вообще не про go test -race. В общем держите нас в курсе своего нелёгкого программирования на плюсах или на чём вы там программируете.

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

Ваших мозгов недостаточно чтобы понять нужно ли вам нечто вроде go test -race в вашем проете или нет?

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

Судя по вашим примерам некоторым свойственно ещё и не думать.

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

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

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

Видимо у вас какое-то своё представлении о доделанном коде, потому что сделанное на коленке доделанным быть не может по определению.

Ну вот нашелся близкий по смыслу

В моей системе координат шизоидные форсы на лоре (и в других местах интернета) не отражают и не выражают IT индустрию в каком-либо виде. В лучшем случае они выражают менталитет некоторой (и как правило достаточно узкой) группы it-специалистов, частенько весьма сомнительной квалификации.

Ты описал ситуацию которую утиная типизация как раз не решает а ухудшает.

Если у тебя есть зависимость в требованиях к которой указаны 2 метода. Ты вообще никак заранее не поймешь какой объектов будет туда засунут, т.к придется искать по сигнатурам всех кандидатов.

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

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

все таки на дворе массовые увольнения кнопкодавов.

Массовые увольнения всех подряд ради увеличения бюджетов на токены ИИ.

экосистему, культуру, идиоматические подходы и практики

Это как раз и есть изощрения. Тут в питоне (куда уж примитивнее) применишь конструкцию for-else, на тебя уже волком смотрят.

Был такой анекдот

— Сколько у вас в СССР инженер получает?
— А у вас в Америке негров вешают!

Я его рассказываю, потому что не знаю как ещё сказать, что ваша война с яваскриптерами меня совершенно не интересует.

Вообще-то это был ответ на ваш вопрос.

А сам вопрос вам напомнить?

А я вас об этом спрашивал

А я вас спрашивал про подробности реализации разреженных векторов?

O(1) говорит о сложности

Не нужно растекаться банальностями. Даже когда хэш-таблица декларирует O(1) для доступа, это не то же самое что обращение к сишному массиву фиксированного размера по конкретному индексу. Как минимум, вам потребуется проверка коллизии с возможным переходом к другому элементу, если коллизия произошла.

Если же у вас немного данных, зачем вам что-то сложнее обычного массива?

Разряженные вектора применяют когда у вас пространство индексов измеряется десятками/сотнями миллионов (а то и миллиардами), тогда как элементов в нем на пару порядков меньше (но все равно не один-два).

Допусти пространство индексов - один миллиард, а колчество значений на два порядка меньше - 10 миллионов. Вы всё ещё считаете решение на map с O(1) хуже полного сканирования 10 миллионов значений? Или там всё таки не на столько примитивная реализация и соответственно цена одного условного действия выше, чем просто чтение ячейки Си массива?

Моего решения нет. Я хотел узнать, что должен был делать Go-программист имея на руках первые версии языка, если бы ему потребовалось, например, сделать свой разреженный вектор. Который мог бы хранить как short-ы, так и int-ы, так и double, так и, скажем, IPv6 адреса или UUID-ы.

Скорее всего такой Go-программист пользовался бы интерфесами.

Т.е. вы все еще про Go? А какая разница для Go-программиста используется ли в программе контейнер из стандартной библиотеки или из сторонней?

Не понимаю к чему вы это спрашиваете.

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

А вы сразу всё делаете «зашибись»? Go стал достаточно популярным за пределами Google вовсе не с первой версии.

А при чём тут Java 2, если речь идёт о заимствовании шаблонов из крестов в первую версию?

При том, что именно с Java 2 этот язык начали позиционировать как язык программирования широкого назначения. Java 2 появилась в декабре 1998. К тому времени и шаблоны и STL в C++ уже давно были и во всю ипользовались. Дженерики в Java появились лишь в 2004, с выходом Java 5. Type erasure официально объяснялся нехваткой времени на более полную реализацию и якобы обратной совместимостью, которая там вообще ни к селу ни к городу. Нехватка времени - это вообще очень типично для Java. Например появившиеся в Java 9 модули - это десятилетний долгострой, который допиливали и после Java 9 ещё достаточно долго, ломая ту самую обратную совместимость. В итоге модули оказали вообще никому ненужными в реальных проектах.

они выросли или их конкуренты упали?

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

ещё дедушка Вирт эксперемениторовал с ней в лохматые годы?

Это в каком языке Вирта были интерфейсы Go?

Ты опять неправильно прочитал вопрос.

Ну так спрашивать нормально надо было. Откуда я знаю какая из сотни версий «почему» на самом деле нужна.

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

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

ЗЫ, хватит уже скармилавть мои сообщения БЯМ, я с ней и сам поговорить могу.

Если вы уверены, что я общаюсь недобросовестно, можете не отвечать.

Мне нужна реализация сразу двух или большего количества интерфейсов

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

Так ты спроси свою БЯМ про утиную типизацию и почему она так и не стала популярной.

В общем держите нас в курсе своего нелёгкого программирования на плюсах или на чём вы там программируете.

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

Ваших мозгов недостаточно чтобы понять нужно ли вам нечто вроде go test -race в вашем проете или нет?

Вчерашний data races возник на данных, которых в тестах не было. Т.е. на чем тестировали раньше проблем не выявляло, появились новые данные, data race проявился. Это одна из особенностей data races – возникать в зависимости от чего-то. Или не возникать до поры до времени.

я говорил о предположении необходимости параллельного тестирования

Да, вы говорили что-то в духе «надо делать как нужно, а как не нужно делать не надо».

Видимо у вас какое-то своё представлении о доделанном коде, потому что сделанное на коленке доделанным быть не может по определению.

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

А сам вопрос вам напомнить?

Их было несколько. Первый из них «Вы говорите про массив, большинство элементов которого равны ноль-значениям?» Как раз на него я и ответил что такое разряженный вектор.

На следующий вопрос, а именно, «Если так, то разве в том числе не для этого придуман map?» я тоже ответил здесь.

И на ваш третий вопрос в той пачке ответил там же.

Но вы все равно настойчиво педалите map.

map может рассматриваться в качестве возможной реализации. Но с этим есть сложности, о которых я уже говорил (ссылка выше).

А я вас спрашивал про подробности реализации разреженных векторов?

А я про подробности реализации ничего и не рассказывал.

Вы всё ещё считаете решение на map с O(1) хуже полного сканирования 10 миллионов значений?

ХЗ о чем вы и откуда у вас взялось полное сканирование.

Скорее всего такой Go-программист пользовался бы интерфесами.

Т.е. вместо 10M int-ов он бы хранил 10M динамически созданных объектов, внутри которых бы жили единичные int-ы?

Не понимаю к чему вы это спрашиваете.

Например к тому, что в С++ вы запросто можете заменить std::map или std::unordered_map на любой другой контейнер с таким же интерфейсом. Как и в Rust-е. А вот можете ли вы в Go вместо стандартной map-ы взять и подставить свою реализацию?

А вы сразу всё делаете «зашибись»?

Повторю еще раз, специально для тех, до кого с первого раза не доходит:

Это как бы не претензия. Это что-то вроде объяснения того, почему некоторые люди от выразительности Go плевались и почему у Go репутация языка «для дебилов» и «простых задач».

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

Тем, кто оказался в такой же ситуации, Go успешно зашел.

Для остальных остается вопрос «а нафига этот примитив вообще был нужен в наше время?»

Это как раз и есть изощрения.

Напротив же. У каждого языка есть свой стиль, свой способ делать дела. Если ты работаешь в рамках этого стиля, у тебя всё хорошо. На хаскелле нужно писать чистые функции высших порядков. На С — дрочить байты с учётом как оно потом на реальном процессоре будет раскладываться по регистрам и кэшам. Можно ли делать наоборот? Можно. Хаскель, как известно, лучший в мире язык императивного программирования, в С есть указатели на функции, можно ФВП эмулировать и даже здесь, прямо в этой теме предалагают модифицировать один кусок данных из разных горутин. Только не надо удивляться потом, отчего какие-то враги на тебя заклинание «анус запеканус» непрерывно кастуют.

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

Перестань тупить.

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

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

Наверное ваша голова проживает в другой субстанции думая, что хождение ржавым строем является универсальным решением проблемы data race.

Вчерашний data races возник на данных, которых в тестах не было. Т.е. на чем тестировали раньше проблем не выявляло, появились новые данные, data race проявился. Это одна из особенностей data races – возникать в зависимости от чего-то. Или не возникать до поры до времени.

Звучит как слишком высокоуровневое тестирование.

Да, вы говорили что-то в духе «надо делать как нужно, а как не нужно делать не надо».

Ну если вы не умеете писать юнит тесты, то действительно совет, что «надо делать как нужно» весьма актуален для вас.

хождение ржавым строем является универсальным решением проблемы data race

Вы можете быть обо мне сколь угодно никого мнения, но это никак не отменяет того факта, что в Rust есть средства защиты от data races на уровне языка, тогда как в Go их нет.

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

Звучит как слишком высокоуровневое тестирование.

Ну если вы не умеете писать юнит тесты, то действительно совет, что «надо делать как нужно» весьма актуален для вас.

Код, в котором был обнаружен data race вообще вне зоны моей ответственности. И повлиять на людей, которые этот кусок разрабатывают и тестируют, не могу. Мое участие свелось к тому, чтобы подтвердить наличие проблемы под одной из платформ и, по возможности, локализовать. Что и было сделано посредством thread sanitizer (после очистки его выхлопа от ложных срабатываний).

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

Их было несколько. Первый из них «Вы говорите про массив, большинство элементов которого равны ноль-значениям?» Как раз на него я и ответил что такое разряженный вектор.

Вы рассказали, что ноль-значения там не хранятся физически, на что я сказал, что и в map их тоже не нужно хранить. Зачем вы так упорно нудничаете?

А я про подробности реализации ничего и не рассказывал.

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

ХЗ о чем вы и откуда у вас взялось полное сканирование.

Из необходимости как-то более оптимально находить данные по нужному индексу.

Т.е. вместо 10M int-ов он бы хранил 10M динамически созданных объектов, внутри которых бы жили единичные int-ы?

Грубо говоря да - тип и поинтер на данные, то есть на int.

Например к тому, что в С++ вы запросто можете заменить std::map или std::unordered_map на любой другой контейнер с таким же интерфейсом. Как и в Rust-е. А вот можете ли вы в Go вместо стандартной map-ы взять и подставить свою реализацию?

В C++ map реализован в коде STL, которая является частью стандартной библиотеки. В Go map реализован на уровне самого языка и это hash map. В большенстве случаев нужен именно hash map. Для специальных случаев никто не запрещает пользоваться библиотеками. Если вам нужна заменяемость между этими реализациями, оберните стандартный map в обёртку с единым интерфейсом. Минимализм Go придуман не столько для снижения порога входа, сколько для уменьшения вероятности наступить на грабли в будущем.

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

Нет, это лишь ваша догадка.

Снова тупишь. Ну сколько можно? Тебе рассказали о преимуществе утиной типизации и о проблеме, которая возникает с dependency injection без такой типизации в Java. Тебе есть что по теме сказать или тебе гипофиз собаки в мозги вшили?

Вы можете быть обо мне сколь угодно никого мнения, но это никак не отменяет того факта, что в Rust есть средства защиты от data races на уровне языка, тогда как в Go их нет.

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

В каком месте я спорил с вами о том, что «в Rust есть средства защиты от data races»? Я говорил о том, что цена этой защиты неадекватна для языка общего применения.

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

Ну вот, пошли отмазки в стиле «мопед не мой, я только разместил объяву».

на что я сказал, что и в map их тоже не нужно хранить

Мне непонятно зачем вы это сказали и зачем столько раз повторяете.

То, что разряженный вектор физически не хранит ноль-значения является одной из подробностей реализации.

Как бы нет. Это требование.

Из необходимости как-то более оптимально находить данные по нужному индексу.

«Оптимально» и «полное сканирование» у меня в одном предложении не уживаются. У вас, вероятно, таки да.

Грубо говоря да - тип и поинтер на данные, то есть на int.

Вот и еще одна причина для игнора Go в его ранних версиях.

Если вам нужна заменяемость между этими реализациями, оберните стандартный map в обёртку с единым интерфейсом.

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

Посылай в БЯМ кого-нибудь другого. Кого-нибудь, кто не посылает тебя в жопу в ответ.

Я говорил о том, что цена этой защиты неадекватна для языка общего применения.

И, как по мне, так это глупость.

Ну вот, пошли отмазки в стиле «мопед не мой, я только разместил объяву».

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

Но, если интересно, прямо сейчас, в процессе нашего общения, TSan, очень похоже, нашел data race в коде, написанном мной лет 10 назад и с тех пор использовавшимся разными людьми в разных проектах. Однако, пока еще не «стрельнувшим». Ну или «стрельнувшим», но незамеченным.

В коде, который был покрытым тестами. Очевидно, не теми, что следовало бы.

А при чём тут Java 2, если речь идёт о заимствовании шаблонов из крестов в первую версию?

При том, что именно с Java 2

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

Мне непонятно зачем вы это сказали и зачем столько раз повторяете.

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

Как бы нет. Это требование.

Согласно определению это не требование.

«Оптимально» и «полное сканирование» у меня в одном предложении не уживаются. У вас, вероятно, таки да.

Как раз именно у вас. Потому что я как раз таки поставил между ними знак неравенство.

Вот и еще одна причина для игнора Go в его ранних версиях.

А заодно и кучи других языков, у которых дженериков в ранних версиях тоже не было.

Зачем делать то, что в других языках можно не делать вообще?

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

Я говорил о том, что цена этой защиты неадекватна для языка общего применения.

И, как по мне, так это глупость.

Не буду вас переубеждать. Скажу лишь, что по факту Rust так и не стал языком общего применения и остаётся почти полностью языком системного программирования. Микросервисы на нём мало кто программирует, если вообще.

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

Зачем мне ваша переписка, когда мы говорим вовсе не о ней?

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

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

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

Это не мое определение. В моем случае это вектор, у которого большинства элементов нет вообще (ноль – это легальное значение для существующего элемента).

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

Эта подробность нехило так влияет на то, сможете ли вы вообще что-то сделать на обычном железе или вам потребуется терабайт ОЗУ (а то и не один).

Потому что я как раз таки поставил между ними знак неравенство.

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

А заодно и кучи других языков, у которых дженериков в ранних версиях тоже не было.

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

Зачем тащить в язык то, что нужно лишь в исчезающе малом проценте случаев?

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

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

Да и вообще, зачем все эти лучшие практики, которые обкатывали в других языках? Ну вот те же алгебраические типы данных и паттерн матчинг? Ведь можно же просто возвращать (x, err) всегда. А затем смотреть, задействовал ли программист err хоть как-то. Не, на у чё? Для 80% случаев прокатит.

Или зачем нужна константность? Или зачем следить за одновременным количеством ссылок на объект?

Большинству же это не нужно. А кому нужно, тот пусть тесты пишет.

Скажу лишь, что по факту Rust так и не стал языком общего применения и остаётся почти полностью языком системного программирования.

Да да, держите нас в курсе. Нам очень важны результаты ваших наблюдений.

Обсуждать Java до Java 2 не имеет никакого смысла.

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

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

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

Так до этого ты в БЯМ по каждому сообщению бегал.

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

ИМХО, это зависит от того, про какие языки мы говорим: статически-типизированные или динамически-типизированные. В динамический языках, насколько я знаю, утиная типизация во все поля.

Со статически-типизированными, конечно же, все куда как интереснее. Включая и моду на примитивный ООП начиная с 1980-х и по конец 2000-х.

У меня на написание тех сообщений ушло примерно 30 минут в сумме. По ощущениям, точно не считал. Первый набросок, проверка предпосылок, поиск первоисточников, полировка подачи — всё это непростой труд, который от БЯМ зависит мало. Можешь посмотреть количество редактирований под сообщениями, в качестве свидетельства. Так что банальные обвинения без пруфов довольно обидны. Ну не верите — дело ваше.

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

Так я же не просил с тебя эти портянки. У меня то вопросы такие чтобы на них одним-двумя предложениями можно было ответить. Мы ж на форуме. Тут к любому сообщению можно ставить имхо.

Если го загнется то будет очень жаль.

P.S. Кстати что интересно, во многих сферах, начиная с продуктов, автомашин, процессоров и т.д. почему все хорошее и качественное загибается а всякой … всплывает.

In my honest opinion, корректность до последнего бита — это не судьба программирования, а скучная бухгалтерия. Компьютеры (и программирование) должны создаваться для людей, а люди не заполняют неуместно-сложные формы ради каршеринга. Из принципа должна быть динамичность и лёгкость использования.

И мне кажется, что эволюция ещё поставила крест на этом подходе.