Почему ООП стало более популярным и соответствующие языки и технологии программирования чем то же ФП?

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

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

Я извиняюсь, но где можно посмотреть на Python без сборки мусора?

У основной реализации питона, CPython, а также у Cython фундаментальным механизмом управления памятью является подсчет ссылок и освобождение объекта при обнулении счетчика. Причем, даже GC работает в рамках этого механизма, временно снижая счетчики для известных ссылок и разрушая те объекты, у которых счетчик оказался равным нулю. Instagram просто отключал у себя мусорщика, чтобы он после форка не жрал память через copy-on-write.
https://instagram-engineering.com/dismissing-python-garbage-collection-at-ins...
У PyPy счетчиков ссылок нет, а есть регулярно сливаемые целиком ясли (nursery), из которых живые объекты копируются в кучу, что больше похоже на какой-нибудь GHC в этом плане; у Jython и IronPython мусорщики стандартные JVM и CLR соответственно.

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

Или такой Python, вместе с кучей других фантомов, живет только в вашей альтернативной вселенной?

Где будут, например, команды для явного освобождения ставшей ненужной памяти

del varname

Где будет возможность управлять размещением объектов на стеке или в куче.

CPython не умеет размещать объекты в стэке. По крайней мере, из коробки. Этого не умеет, к слову, и тот же Object Pascal. Вместо стэка есть поколения.

del varname

Допустим. Как тогда делить переменные на reference- и value? Например:

a = ["hello", ",", "world"]
b = a[0]
del b

Что из себя представляет b: ссылку или значение? Если ссылку, то каков эффект del b?

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

В Си нужно было добавить намного, намного меньше для того, чтобы язык стал конфеткой. А именно:
- структурированные исключения, которые позволяют погружаться во вложенные блоки без создания спагетти-кода для корректного выхода;
- автоматическое (на уровне компилятора) управление выделением-высвобождением структур, как это было сделано, например, в Object Pascal, где локальные массивы, структуры, строки, и интерфейсы компилятор оборачивает в инициализацию-финализацию, которая будет в блоке try..finally при наличии поддержки обработки исключений (а она не во всех компиляторах есть).

Всё. Не нужно классов, не нужно шаблонов - просто возможность объявить инициализаторы-финализаторы для некоего типа. Что они навыдумывали с крестами - это кошмар, всё, что только нашли на свалке, всё притащили: стул без ножки, сломанный телевизор, половину сверла (можно подточить), разорванные кроссовки.

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

А если нужно доработать старую кодовую базу, начавшую свою жизнь лет эдак 15-20 назад

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

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

Всё. Не нужно классов, не нужно шаблонов

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

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

Егора Бугаенко... «Elegant objects».

Статические методы в любом контексте — безошибочный индикатор плохого программиста, понятия не имеющего об ООП. Для применения статических методов нет ни единого оправдания ни в одной ситуации. Забота о производительности не считается. Статические методы — издевательство над объектно-ориентированной парадигмой. Они существуют в Java, Ruby, C++, PHP и других языках. К несчастью. Мы не можем их оттуда выбросить, не можем переписать все библиотеки с открытым исходным кодом, полные статических методов, но можем прекратить использовать их в своем коде.

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

Егор рассуждает по нашему вопросу и о преимуществах неизменяемости объектов https://youtu.be/lfdAwl3-X_c

Напомнило: https://www.youtube.com/watch?v=5Srg0i3Vc2o

Были 40 свойств в классе, а теперь имеем класс, который использует 40 классов

Это типичная архитектура приложения в исполнении сенйора за миску риса.

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

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

a = [«hello», ",", «world»]
b = a[0]
del b

Что из себя представляет b: ссылку или значение? Если ссылку, то каков эффект del b?

Переменная в CPython - это всегда ссылка на объект. del b удаляет ссылку и снижает счетчик ссылок у объекта. Когда у объекта будет ноль ссылок - вызовется деструктор объекта. В данном примере b - это ссылка на объект-строку «hello», на которую также ссылается список a. Конкретно строки в питоне неизменяемы, потому изменение строки будет изменением ссылки, а не изменением самой строки.

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

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

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

Гиганты же софтостроения выбирают средства из соображений доступности кадров, и не более того. Потому гугл так долго медлил с разработкой Go, например - под него нет кадров.

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

Бугайенко наркоман какой-то. Я как-то ему вопрос задавал на митапе, как он без тех же геттеров внутреннего состояния объектов в лог что-то выведет про эти объекты. Он предложил напложить кучу декораторов и пустился в пространные рассуждения о том, что миллион объектов лучше чем один геттер. А еще в том видео, где он говорит про негодность сеттеров он предлагал при переименовании файлов возвращать новый объект, а старый просто «забывать». То есть фактически оставить старый объект в невалидном состоянии. Яб постремался его книги читать.

А еще в том видео, где он говорит про негодность сеттеров он предлагал при переименовании файлов возвращать новый объект, а старый просто «забывать». То есть фактически оставить старый объект в невалидном состоянии.

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

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

Переменная в CPython - это всегда ссылка на объект. del b удаляет ссылку и снижает счетчик ссылок у объекта. Когда у объекта будет ноль ссылок - вызовется деструктор объекта.

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

Правда, тогда нужно будет финализаторы/деструкторы для объектов делать и вызывать только вручную.

Ну и стандартная библиотека будет не доступна.

А так, да. Похоже на правду.

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

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

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

И тот же Google со своим Go отличный пример. Сперва они сделали примитивный инструмент для тех, кто не может в Java и C++. А потом убедились, что и в Go нужны аналоги шаблонов и более удобные механизмы обработки ошибок. Ибо без этого трудоемкость в определенных задачах получается излишне высокой.

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

Я уже готов было написать, что слышал что-то подобное от человека с ЛОР-а, который ничего кроме С++ и жавы не знал, и восхваливал эти языки как лучшее решение, поскольку не имел с чем их сравнить. А потом оказалось, что это ты и был:
Почему ООП стало более популярным и соответствующие языки и технологии программирования чем то же ФП? (комментарий)

Я не знаю, что толком можно обсуждать в таком раскладе, потому что под фразой «очень сильно снижают трудоемкость» должна быть аргументация вроде «мы пробовали другой инструмент, и получилось намного дольше» - но ее не будет. В отличие от моего мнения, которое аргументировано участием в крупном проекте на Си, где, как ни странно, были классы, и от них не было ни холодно, ни жарко, а также много-много макросов a.k.a. poor man's template, которые так же ни разу не становились какой-то значимой проблемой или средством с ограниченными возможностями. Это к слову о: «Но пока вы это на собственной шкуре не прочувствовали, вы можете пространно рассуждать об индустрии».

Сперва они сделали примитивный инструмент для тех, кто не может в Java и C++

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

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

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

Ну а классов в Go нет, и не будет.

уровень твоих когнитивных

Наших, qulinxao, наших :D

Ну серьезно, за столько лет хоть чуть-чуть не подучить русский?..

который ничего кроме С++ и жавы не знал

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

В отличие от моего мнения, которое аргументировано участием в крупном проекте на Си, где, как ни странно, были классы, и от них не было ни холодно, ни жарко, а также много-много макросов a.k.a. poor man’s template, которые так же ни разу не становились какой-то значимой проблемой или средством с ограниченными возможностями.

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

Что до «не становились какой-либо значимой проблемой», то тут вы призываете поверить вам на слово. Чего делать не собираюсь, т.к. насмотрелся разных сортов кода как на C, так и на C++, так и на других языках, про которые на словах так же говорили, что значимых проблем там нет. В том числе и переписывал кое что с C на C++, делая код при этом и компактнее, и понятнее, и безопаснее.

Позволю себе лишь напомнить, какой прорыв в GUI-строении в свое время сделали ООП-языки, включая SmallTalk, ObjectPascal и C++. И какое количество GUI-софта в свое время было написано именно благодаря библиотекам классов.

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

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

Это ваша точка зрения, которая, как уже было сказано выше, сильно противоречит окружающей реальности. Это во-первых. И, во-вторых, почитайте мотивацию разработчиков Go. Они его делали специально для того, чтобы не нужно было на C++ и Java писать. Массовый переход с Python-а на Go стал для них самих неожиданностью.

При этом, идея шаблонов обрела какую-то формализацию только года два назад

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

Ну а классов в Go нет, и не будет.

Там есть аналог «для бедных».

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

классы - это способ контролировать доступ к глобальным переменным, не более. члены класса доступны множеству ф-ий (это типа методы), а остальным нет -> члены класса есть глобальные переменные для множества ф-ий.

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

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

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

Вечер прохладных историй на ЛОР-е. Рекурсивные вызовы и структуры в паскале кто отменял? Чистые функции? А функции первого класса?
https://ru.wikipedia.org/wiki/Функции_первого_класса
«В информатике язык программирования имеет функции первого класса, если он рассматривает функции как объекты первого класса. В частности, это означает, что язык поддерживает передачу функций в качестве аргументов другим функциям, возврат их как результат других функций, присваивание их переменным или сохранение в структурах данных»
Индустрия начала с процедурки и ФП; индустрия скатилась в ООП, как локальный тупик, из которого она вполне целенаправленно выходит.

Что до «не становились какой-либо значимой проблемой», то тут вы призываете поверить вам на слово

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

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

Любой язык лучше, чем Си. Переписывая «кое-что» с Си на Erlang получается код и компактнее, и понятнее, и безопаснее. Переписывая с Си на Паскаль получается код и компактнее, и понятнее, и безопаснее. Переписывая с Си на Smalltalk получается код и компактнее, и понятнее, и безопаснее. Ну и вообще:

переписывал кое что с C на C++

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

Позволю себе лишь напомнить, какой прорыв в GUI-строении в свое время сделали ООП-языки, включая SmallTalk, ObjectPascal и C++. И какое количество GUI-софта в свое время было написано именно благодаря библиотекам классов.

Опять начинается. «Я привык к этому - а значит, это хорошо». Тебе не приходило в голову, что GUI-софт - это сплошное впаривание неудобных интерфейсов домохозийкам? Которое продолжается до сих пор, между прочим, на этот раз в лице игрофонов. А действительно оправданный GUI, вроде систем моделирования и графики, опирается уже на сложные структуры вроде банального массива вершин, где данные и функции работы с ними четко разделены. И в итоге у нас прекрасные современных молодежные ООП технологии GUI-строения нужно разве что в мастере установки, чтобы сделать картинку, надпись, и кнопки «Далее» и «Отмена».

почитайте мотивацию разработчиков Go. Они его делали специально для того, чтобы не нужно было на C++ и Java писать. Массовый переход с Python-а на Go стал для них самих неожиданностью.

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

Мотивация гугла проста: C++, Java, и Python имеют слишком много недостатков и не подходят достаточно хорошо ни для одной задачи. Поэтому гугл сам для себя нашел, выбрал, призвал из потусторонних миров язык, который был бы хорошим общим знаменателем для многих проектов гугла.
Может быть конкретно проектировщики и реализаторы языка и были аутистами, слабо понимающими процессы в индустрии, но любой мало-мальски значимый начальник прекрасно понимал, что основная масса будет плыть по течению: гугл поддерживает питон - все идут на питон; гугл сделал хром - все перешли с мозиллы на хром; гугл сделал сверхбыстрый движок javascript - все индусы начали писать что попало на JS, включая сервера; гугл сделал свой язык - все начали писать веб на Go, а там уже и смежные сферы подтянулись. Козел пошел в каком-то направлении - все бараны пошли за ним, вот и вся история.

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

Не говори «хоп», пока не перепрыгнешь.

Переписывая с Си на Smalltalk получается код и компактнее, и понятнее, и безопаснее.

Только в разы медленнее. Да и с сопровождением есть особенности в виду динамической типизации. Да и с переносом на другие VM от других вендоров тоже как-то не очень.

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

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

Эка у вас каша в голове. Вы эту кашу тому персонажу с докером отнесите.

Тебе не приходило в голову, что GUI-софт - это сплошное впаривание неудобных интерфейсов домохозийкам?

Нет.

Но то, что вы так думаете совсем не удивительно.

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

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

Козел пошел в каком-то направлении - все бараны пошли за ним, вот и вся история.

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

Не говори «хоп», пока не перепрыгнешь.

Ну посмотрите на историю развития C++, Eiffel, Java и C#. Они все начинались без поддержки обобщенного программирования. Но все ей обзавелись. Пока что Go движется по уже проторенной дорожке.

Переписывая с Си на Smalltalk получается код и компактнее, и понятнее, и безопаснее.

Только в разы медленнее.

Objective C и вся подсистема GUI маздая сделана на динамической диспетчеризации - чет я не помню, чтобы кто-то сильно жаловался на медленность. Надо сделать быстрее? Отпрофилировал, отоптимизировал - вот и вся история. Преждевременная оптимизация - зло.

Да и с сопровождением есть особенности в виду динамической типизации. Да и с переносом на другие VM от других вендоров тоже как-то не очень.

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

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

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

Ну посмотрите на историю развития C++, Eiffel, Java и C#. Они все начинались без поддержки обобщенного программирования.

В C++ и Eiffel обобщения были с первых макетов. Ну это я так... просто поотрицать окружающую реальность.

Objective C и вся подсистема GUI маздая сделана на динамической диспетчеризации - чет я не помню, чтобы кто-то сильно жаловался на медленность.

Речь не про Objective C, а про SmallTalk. И речь не про динамическую диспетчеризацию, а про динамическую типизацию.

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

Речь не про Java, а про SmallTalk, у которого была куча вендоров с собственными реализациями SmallTalk VM, несовместимые друг с другом. Тогда как Sun в свое время требовал жесткой сертификации у производителей других VM на соответствие своим спецификациям.

Так что вы это, выходите из мира своих фантазий.

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

Почему тогда тот же Страуструп ничего не рассказывает про бабло, которое AT&T или Bell Labs вливало в разработку C++? Почему сейчас некоторые участники заседаний комитета по стандартизации ездят на эти заседания за свой счет? Почему никто не вложился в разработку большой stdlib для C++, тогда как Sun и MS это сделали для Java и .NET-а?

Много ли бабла вкладывалось в разработку Perl-а? Или Python-а? Или Ruby? Может быть Вирту отвалили миллионы на разработку Pascal и Modula-2?

В C++ и Eiffel обобщения были с первых макетов.

Ахринеть, дайте два. Вы эти макеты разглядели в тех же секретных документах, в которых и про развитие космических отраслей США и СССР свои знания почерпнули?

Хоть Царь часто очень груб в выражениях, его оппоненты подозрительно часто повторяют одну и ту же ложь, им опровергнутую. Такой комментарий просто уничтожается возможностью [&](...){...}

Будешь умный указатель на каждый int ставить?

Всякие примитивные типы данных, COW, маленькие структуры без RAII проще просто передать по значению (скопировать). И Qt-шное решение «parent QObject обязательно удаляет своих children» мне кажется весьма элегантным: время жизни объекта зависит от простых правил, можно спокойно передавать экземпляры по указателю, несложно понять новичку, пришедшему из мира с GC.

клюква ситуации в вашей уверенности(допустим искренность утверждения о меньшем у оппонента лекта русского в сравнение с самооценкой высказавшегося ) в достаточном русском у вас :)

Речь не про Objective C, а про SmallTalk. И речь не про динамическую диспетчеризацию, а про динамическую типизацию.

Ну претензии про динамическую типизацию несерьезны на фоне Strongtalk. Я говорил про более неустранимые элементы динамичности.

Тогда как Sun в свое время требовал жесткой сертификации у производителей других VM на соответствие своим спецификациям.

Что значит «требовал»? Производители платили большие деньги за привелегию лицензирования VM для жабы, а совместимость с официальной VM - это, скорее, приятный бонус.

Почему тогда тот же Страуструп ничего не рассказывает про бабло, которое AT&T или Bell Labs вливало в разработку C++?

Давайте поговорим про заговоры. В мире, по моему мнению, есть единственный заговор - это заговор тупости. Люди не пытаются и не хотят пытаться узнать что-то, пока это что-то не поднесут к ним на блюдечке и не положат в ротик.
Да, не рассказал. А обязан был? Да и он сам вряд ли интересовался, кто, когда, и сколько вливал в разработку - он сам участвовал в заговоре тупости, скорее всего.
Или тебе все еще хочется верить, что совершенно случайно крупнейший потребитель софта того времени оказался у руля разработки C++, и эту роль мог отыграть кто угодно?

Почему сейчас некоторые участники заседаний комитета по стандартизации ездят на эти заседания за свой счет?

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

Почему никто не вложился в разработку большой stdlib для C++, тогда как Sun и MS это сделали для Java и .NET-а?

Вопрос про stdlib для C++ я не понял. STL, что ли?
Sun делал либу для жавы потому, что вложил много денег в покорение мира при помощи онной, и почти провалился при этом. Хотя, что значит «почти» - земля ему пухом.
MS же давно уделяет много внимания средствам разработки на их собственных платформах.

Много ли бабла вкладывалось в разработку Perl-а? Или Python-а? Или Ruby?

Про питон я уже отвечал - гугл популяризовал его.
Perl? Что такое перл? Не, не слышал.
Ruby относительно успешно повторил путь PHP, и нынче известен исключительно как Ruby on Rails благодаря распределенным усилиям многочисленных загонов для вебмакак. И это произошло именно из-за безграничной ущербности PHP, для которого давно нужна была альтернатива. Так что объективные факторы тут тоже есть, не спорю - совсем уже кошмарные решения будут вытесняться даже несмотря на их популярность. Хотя, PHP до сих пор не собирается никуда уходить.

Может быть Вирту отвалили миллионы на разработку Pascal и Modula-2?

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

В C++ и Eiffel обобщения были с первых макетов.

Ахринеть, дайте два. Вы эти макеты разглядели в тех же секретных документах, в которых и про развитие космических отраслей США и СССР свои знания почерпнули?

Страуструп сам говорил в интервью, что хотел сделать язык с шаблонами и перегрузками, а классы не особо были интересны.
https://www.maths.tcd.ie/~odunlain/eiffel/eiffel_course/designbyc/invitation.pdf - 1987 год, обобщения уже есть. Стоит понимать, что до 1986 года Эйфель был закрытой разработкой.

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

Уже давно понятно, что вы Д'Артаньян, весь такой в белом, а мы все быдло, по уши в дерьме. Но, имхо, вы просто напыщеный чудак.

PS. Пожалуй, стоит отправить вас в игнор.

c p-ASCA-l'ем ситуация запутанней

как ща лингвофранка для 90% околокомпьютерного python, - т/е язык публикации

некоторое время назад - языком публикации был С

а много раньше Algol60

и да Паскаль как информатика из Европки - ну а С и компутерСциенция с Америшки

зы РУ для Russia; Go для ДжунГо

Индустрия начала с процедурки и ФП;

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

единсвтенный язык, обладающих хоть чем то от фп это с, который всё равно плавно перетёк в ооп (читай спп).

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

какая неожиданность.

даже если смотреть на ооп вне объектной модели симулы (туда же спп, джавы и пр.), а глобально, с позиции алана кея, то ооп всё равно легко (именно) ложится на конкуретность в фп (async и прочие).

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

Хоть Царь часто очень груб в выражениях, его оппоненты подозрительно часто повторяют одну и ту же ложь, им опровергнутую. Такой комментарий просто уничтожается возможностью [&](...){...}

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

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

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

И Qt-шное решение «parent QObject обязательно удаляет своих children» мне кажется весьма элегантным

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

дает ссылку на документ от 2001-го года, датируя его 1987-ым

А сами документы читать мы не будем, да? Только две цифры? Ты ничего не можешь привести в ответ - зачем ты мне отвечаешь?

Для людей с клиническим альтернативным мышлением прямая аналогия: в третьем издании «Язык программирования C++» описаны шаблоны C++. Но текст третьего издания не может быть доказательством того, что шаблоны в C++ были с самого начала.

Вы дали ссылку на краткое описание Eiffel-я, где тамошние генерики уже описаны. Но это описание датируется не 1987-ым, а 2001-м годом. При том, что настолько я помню, генерики в Eiffel были добавлены как раз в 1990-е.

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

индустрия начала с ассемблера и фортрана в которых ничего от фп нету

В фортране действительно не было вложенных и рекурсивных процедур. Стоит понимать, что машинные коды - это даже не процедурное программирование, это тупо машинные коды. Появившиеся непосредственно за фортраном Lisp и Algol 60 уже имели рекурсии. И Lisp 2, между прочем, почерпнул свой синтаксис из Algol 60. Algol 58 не запрещал рекурсии, но и работа с ними была проблематичной. То есть, как только технология поднялась над маш кодами - она сразу пришла к процедурке и функционалке. Она там же и осталась, между прочим. Лишь позже появилась Симула, из которой зараза ООП расползлась по всей индустрии.

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

Еще раз, про определения:

functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. It is a declarative programming paradigm in that programming is done with expressions or declarations instead of statements.

Пиши на Си, пиши на Паскале, Алголе выражениями без изменения состояния - будет тебе ФП. ФП - это не свойство языка, это свойство конкретного алгоритма. Первым императивным языком среднего уровня с полноценной поддержкой писания ФП стал Алгол 60, за ним пошла целая куча самых разных языков с функциями первого класса, рекурсиями и рекурсивными структурами, локальными переменными и ограничениями побочных эфектов - это всё и есть ФП.

Здесь кто-то писал, что определяющим для ФП является поддержка замыканий, но разве указатель на функцию + указатель на значение данных != замыкание ?

фп ф-ий это объект (ты сам сказал, ха), а в ооп объект можно считать ф-ей

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

ооп всё равно легко (именно) ложится на конкуретность в фп (async и прочие).

Вообще-то, своё понятие объектов Алан Кэй явно упоминал как позаимствованное с объектов лиспа. Я пишу «объекты», а не «ООП», потому что я не знаю, что такое ООП.

Стоит понимать, что машинные коды - это даже не процедурное программирование, это тупо машинные коды.

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

если нет, чем машинные инструкции для х86 отличаются от инструкций например jvm?

если да, как быть с например инструкцией closure в бейткоде окалма? это даже не процедурное программирование? хехе

Функция не является объектом,

можешь считать ф-ию объектом с состоянием unit. такие дела.

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

о чём я говорю. привет

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

если нет, чем машинные инструкции для х86 отличаются от инструкций например jvm?

если да, как быть с например инструкцией closure в бейткоде окалма? это даже не процедурное программирование? хехе

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

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

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

если да, как быть с например инструкцией closure в бейткоде окалма? это даже не процедурное программирование? хехе

Ты бы еще байткод питона вспомнил.

Я тебе напомню, что раньше программы писались на голой глобальной памяти со статически выделяемыми переменными, а переход между логически выделенными блоками осуществлялся либо через услувных/безусловный переход, либо через call в роли команды «прыгни мне по такому-то адресу, а потом прыгни обратно». То есть, понятия процедур в принципе не было. В flow-matic/fortran/cobol осталась та же глобальная память, причем, даже для локальных переменных - просто были убраны беспорядочные переходы между блоками. Можно ли это назвать каким-то опрережающим развитием процедурного программирования, если учесть, что FLOW-MATIC есть с 1955, Fortran с 1957, COBOL с 1959, но IPL - уже 1956 выпущен, разрабатывался с 1954, а его наследник, LISP - 1958. Тютелька в тютельку идут.

можешь считать ф-ию объектом с состоянием unit. такие дела.

Тогда замыкание будет не объектом, бг-г-г.

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

Байткод байткоду рознь.

Машинный код Машинному коду рознь и чё? что сказать то хотел? я не понял

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

немцы вон jvm сделали в железе (правда без gc), можно ли байткод jvm считать машинным кодом теперь?

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

и много с тех пор поменялось? теперь нельзя писать на асемблере или что? хехе

То есть, понятия процедур в принципе не было.

я тебе открою тайну: их сейчас нету на некоторых архитектурах например в мипс нету явного sp, push, pop всё надо руками делать, а picoblaze вообще в аргументы не умеет и глубина стека ограничена (то ли 7 то ли 32, не помню).

Тогда замыкание будет не объектом, бг-г-г.

ты дурак?

Байткод байткоду рознь.

Машинный код Машинному коду рознь и чё? что сказать то хотел? я не понял

Байткод - это любой набор инструкций для программного интерпретатора. Питон, например, не умеет исполнять исходный код - есть специальный компилятор, который превращает исходники в байткод, и уже байткод может исполняться. Это же касается вызовов exec() и eval().

немцы вон jvm сделали в железе (правда без gc), можно ли байткод jvm считать машинным кодом теперь?

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

и много с тех пор поменялось? теперь нельзя писать на асемблере или что? хехе

Разговор шел про процедурное программирование, ФП, ООП. Во времена асма не было процедурного программирования - вот о чем я писал. ПП и ФП появились одновременно.

я тебе открою тайну: их сейчас нету на некоторых архитектурах например в мипс нету явного sp, push, pop всё надо руками делать, а picoblaze вообще в аргументы не умеет и глубина стека ограничена (то ли 7 то ли 32, не помню).

https://kevinpt.github.io/opbasm/rst/language.html - ну, по крайней мере эти версии умеют в регистры, переходы, call. Причем, регистров настолько много (16), что можно забыть про безнадежно устаревшую передачу аргументов через стэк.

Тогда замыкание будет не объектом, бг-г-г.

ты дурак?

Может и дурак, однако же все равно замыкание будет не объектом, а подобъектом или атрибутом объекта.

Байткод - это любой набор инструкций для программного интерпретатора. Питон, например, не умеет исполнять исходный код - есть специальный компилятор, который превращает исходники в байткод, и уже байткод может исполняться. Это же касается вызовов exec() и eval().

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

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

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

ну, по крайней мере эти версии умеют в регистры, переходы, call.

ты походу чукча писатель. ты читал вообще, о чём я тебе писал?

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

что ещё за подобъект? атрибут объекта? что это за ахинея?

struct A {
  int i;
  int get() {return i;}
  void set(int i) {this->i = i;}
};

int main() {
  A a;
  a.set(12);
  printf("%d\n", a.get());
}

let create() =
  let i = ref 0 in
  function
    `get f -> f !i
  | `set x -> i := x

let() =
  let obj = create() in
  `set 12 |> obj;
  `get (function i -> Printf.printf "%d\n" i) |> obj

найди 10 отличий!

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

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

полной машиной реализации никогда не было (насколько я знаю), потому что очень сложно в железе сделать gc

В байткоде JVM нету GC. Никто не будет делать сборку мусора в железе - ему месте в софте.

по твоему в современных процах нету условных переходов и вызовов по указателю

Что в словах «те же» тебе непонятно? те же условные переходы по смещению, тот же вызовы по указателю

я тебе открою тайну: их сейчас нету на некоторых архитектурах например в мипс нету явного sp, push, pop всё надо руками делать, а picoblaze вообще в аргументы не умеет и глубина стека ограничена (то ли 7 то ли 32, не помню).

https://kevinpt.github.io/opbasm/rst/language.html - ну, по крайней мере эти версии умеют в регистры, переходы, call. Причем, регистров настолько много (16), что можно забыть про безнадежно устаревшую передачу аргументов через стэк.

ты походу чукча писатель. ты читал вообще, о чём я тебе писал?

https://www.dsi.unive.it/~gasparetto/materials/MIPS_Instruction_Set.pdf - MIPS, есть jal/jr для вызова подпрограмм и возврата из них, есть регистр $sp (29) - ты не прав.
https://kevinpt.github.io/opbasm/rst/language.html#call - PicoBlaze, есть простые call/return для подпрограмм с сохранением в аппаратном стэке адреса возврата (стэк- набор регистров, 31 в KCPSM3), в дополнение к стэку есть 16 регистров для передачи аргументов - ты не прав.
Почему push/pop - провал? Потому что передача параметров и сохранение временных значений уже довольно давно работают быстрее через регистры, чем через стэк - для x86 проблема исправлена в x64, а ведь уже в первых армах было 16 регистров.

можешь считать ф-ию объектом с состоянием unit. такие дела.

Тогда замыкание будет не объектом, бг-г-г.

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

что ещё за подобъект? атрибут объекта? что это за ахинея?
...
найди 10 отличий!

Язык мне незнаком, скорее всего какой-то идрис, но идея примерно ясна. Здесь нет состояния модуля, а ты определял объект, как функцию с состоянием модуля. Давай тогда отказывайся от этого определения, и определяй объект как имеющий отдельное состояние.

Почему не на функциональные языки?
Потому что в то время функциональные языки в основном использовались сугубо в академической среде или как?
Или если перефразировать всё вышесказанное словами моего коллеги: «если всё так круто (про ФП), то почему оно ещё не захватило рынок?»

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

например.

имеем: 2 парадигмы программирования, модели мышления. предназначенные чтобы изолировать модульность.

1. ООП: «глобальное состояние это плохо, изолируем в объект». и далее получим «изменчивое состояние — акт умственного жонглирования» и далее по тексту, «беспорядочно разделённое состояние», и ворох сопутствующих проблем. потому что единица модульности, first class object на уровне системы типов это объект (,класс, метакласс) — то есть уже «беспорядочно разделённое состояние».

2. ФП: «мутабельное состояние это плохо, изоморфно преобразуем в функциональные структуры данных и иммутабельные функции/сообщения/методы. изолируем состояние в монаду, и преобразования и интерфейсы в трансформеры монад».

и далее получим «умственное жонглирование» такими иммутабельными структурами данных и трансформерами. first class object — функция, типы и конструкторы типов. более модульное. предполагается, что с помощью зависимых типов и более гибкой системы типов удастся описать «беспорядочно разделённое состояние чисто функциональное преобразование» уже таких расширенных типов и иммутабельных структур данных.

3. акторы (например, в pony): «ООП — это когда методы класса вызываются синхронно и последовательно, а акторы — когда асинхронно и конкурентно». при этом не только «состояние», но и поток выполнения размазан по асинхронной лапше методов вызовов сообщений, которые класс ХЗ когда отработает (когда захочет, тогда и отработает). селектор таких методов и есть эта «иммутабельная структура данных».

акторы: «синхронный вызов методов это плохо, изолируем самостоятельное поведение агента в асинхронные методы ХЗ когда вызывающиеся через green treads».

и асинхронная лапша из коллбеков в духе javascript. с абстрактной верой, что асинхронщина всё разрулит.

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

берём 10500 не ООПшных библиотечек в стиле фортрана, и обмазываем их ООП обёрткой, даже без единого предка или метакласса, в духе цепепе объектов. и на тебе — у нас цепепе движок, а значит оопе.

системная корректность статическая, ко/контрвариантность динамическая и прочие выкрутасы с семантикой системы типов конечно идут побоку — но, у нас же тоже уже есть ООПе!!! маркетоидные фреймворки, ботарейки и прочий буллшит.

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

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

Вы забываете, что обезьян в сферы крестов в то время не подпускали на пушечный выстрел - сиди, Васик ковыряй, или dBase/Foxpro/Access, подрастешь - поговорим. А то же ядро оракла написано суровыми бородатыми дядьками на голом Си - никаких крестов там нет. Где-то между этими бородатыми Сишниками и пузатыми дядьками в начальстве, подсчитывающими прибыль и убытки, и кроется секрет успеха ООП, но никак не в обезьянах. Хороших руководителей-кодеров тяжелой найти даже сейчас - тогда их днем с огнем было не сыскать. Обезьяны пошли с дешевыми компами, с жавой, с PHP, с JS - в 90-х закончился хардкорный кодинг и творчество, а вместо этого началась разгрузка вагонов с углем руками желтожопых.

Большинство детей имеют талант с рождения. Если ты мне покажешь школу, которая на поточной основе за пять лет учит взрослых людей говорить на двух иностранных языках с успехом хотя бы 95%, то я соглашусь, что я неправ.

Два индивидуальных учителя. Полная невозможность чего-либо получить самостоятельно. К примеру снять портки чтоб посрать. Только вербальные просьбы. Ну и никаких взрослых забот.

Два индивидуальных учителя. Полная невозможность чего-либо получить самостоятельно. К примеру снять портки чтоб посрать. Только вербальные просьбы. Ну и никаких взрослых забот.

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

ИМХНО /sorry повторюсь/ каждому человеку Бог даровал таланты /и не один/.
К сожалению люди идут «своим путем».
Прирожденный оперный певец разрабатывает «компиляторы», а программист становится «оперным певцом».

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

Всё ж примитивно. Чтоб аргументировано утверждать что дело только в «детской талантливости», нужно убрать другие отличие. Я перечислил важные по моему мнению.

Прирожденный оперный певец разрабатывает «компиляторы», а программист становится «оперным певцом».

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

Разговор шел о том, что обычные учебные заведения зарывают эту одаренность в землю, штампуя рабов для нужд тех, кто эти учебные заведения спонсирует. Например, за годы вне учебных заведений, в которых я провел полжизни, я выучил английский хуже, чем за годы после них. Сейчас, имея довольно солидный уровень и оглядываясь назад и анализируя, в чем же был затык, я могу с уверенностью сказать, что способ подачи в школе и ВУЗ-ах такой, что даже при самом большом желании по этой программе ты не сможешь выучить язык, а если и выучишь - то только благодаря своим собственным занятиям. Сейчас я бы даже не написал на хорошую оценку школьную контрольную, хоть могу пересказать услышанную английскую речь, а большинство моих одноклассников не смогут двух слов на английском связать. Еще раз: школа и ВУЗ мешают изучать иностранные языки.

Java была создана для превращения кодеров в скот - еще Дейкстра заметил, что написание программ на Васике отупляет программистов. Это и был настоящий план менеджеров Sun, который, скорее всего, был придуман уже после создания самого языка, и который не имеет отношения к фантазиям создателя языка про «исполнение на каждом утюге» - именно эта роль сверхпортабельной жавы с треском провалилась. PHP уже начал завоевывать мир умственно отсталых кодеров с 1995 года, когда в Sun, наконец, поняли, что эту же роль может отыграть Java, если ей немного помочь. Java - это язык, который перегружен формальностями, который защищен от неожиданностей, что в итоге требует высокого уровня механической организации ума и низкий уровень творческого мышления. Таких людей очень любят в разных крупных фирмах - из них получается замечательный офисный планктон. В отличие от PHP, кодера на Java все-таки нужно дрессировать - спрос на пастухов довольно быстро был подхвачен, и развелась огромная туча пасторов, проповедующих те или иные догмы, которые без сомнения и без понимания подхватываются планктоном и используются в продакшене.

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