Здравствуйте, vdimas, Вы писали:

V>Я собеседовал десятки, если не больше сотни в разные годы.
V>И тенденция слишком однозначная, чтобы это было простым совпадением на многих десятках людей.
Есть какие-то объективные данные? Без них это так — трендёж о том, как раньше девки были краше.

V>И дело не в уровне программистов, дело кое в чём катастрофическом другом — профессия воспринимается всё более обыденно, всё меньше горят глаза, всё менее ЛЮБОПЫТНО.

Угу. Я закончил школу в 1993 году. Из параллели в 50 человек в программирование пошло двое с половиной.
И сейчас успеха в программировании добивается примерно 1 из 20. То, что теперь пытаются идти в программирование 15 из 20, общей картины никак не меняет.

V>Наше поколение — это поколение исследователей, без преувеличения.

V>А с чем ты сравниваешь?
С девяностыми. Ну, и с тем, какие программы и какими программистами писались в 80х. У меня инсайд из НИИ Автоматизированных Систем — типичное учреждение промышленного программирования.
Уверяю вас: никакого "любопытства", никаких "исследователей". Совершенно простые смертные. Тётеньки, которые писали унылые программы на фортране.

V>И в насколько разные это были годы?
Лично я — с конца 90х и до сих пор.
V>Проблема примерно в следующем — увлекающийся программист осваивал материала по специальности примерно раз в 10 больше, чем давала программа ВУЗ-а.
У нас и в 100 раз можно было больше, т.к. специальности не преподавали.
V>Сейчас доля таких студентовв разы ниже, дай бог 1-2 на группу.
Их всегда и было 1-2 на группу. Если в одной группе окажется 3-4, то в другой будет 0-1.

V>И у тебя разве есть достаточная выборка по однокурсникам хотя бы до начала нулевых, чтобы сравнивать с тем, как оно есть сейчас?
Конечно есть выборка.

Ваш очередной сеанс самовосхваления я поскипаю — скучно.

V>Чел попытался присвоить себе "ошибку", которая до него была уже "сделана" эдак тысячекратно, например, тот же nil в Lisp.
Да, с самомнением у вас всё хорошо. Хоар, оказывается, тупой — сам не знает, что сделал. И то, что вы nil в lisp не отличаете от NULL в Алголе — тоже плохо.


V>Альтернатива тут возможна только через IoС, т.е. в функциональных языках, когда некоему акцессору (итератору, скажем), подаётся колбэк.
Ок, самовосхваление кончилось. Пошёл чистый, незамутнённый бред. IoC и функциональные языки соотносятся примерно никак.
Нормальная альтернатива — это собственно выразимость требования непустоты ссылки в терминах системы типов.
Колбек тут совершенно ни при чём — в нормальной системе типов у меня nullable reference отличается от non-nullable reference, и это всё статически проверяется.
Внезапно значительная часть ссылок оказывается non-nullable. А nullable reference нужны не чаще чем, скажем, Nullable<int>. Как-то же работает C# с int? безо всяких IoC и коллбеков. Удивительно, да?

V>Других техник борьбы с nil, кроме диспетчеризации на манер IoC, в природе не существует, даже в Kotlin.
(facepalm). Тут прекрасно всё — и "даже" Котлин, как вершина развития языкостроения, и применение IoC для борьбы с nil, и диспетчеризация...
Жаль, что всё современное программирование прошло мимо вас.


V>А фраза целиком лишь характеризует уже старого и недостаточно умного человека.
Забавно, что вы тут усердно опровергаете утверждение "программисты прошлого были умнее". Видите, и Хоар вам недостаточно умён. Да, я помню, для вас и Билл Гейтс недостаточно успешен

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


V>В точности проблема нулевых ссылок повторяется в массивах, к которым обращаются по индексу.
Эта фраза показывает, что вы не понимаете сути "проблемы нулевых ссылок".

V>И чего ж старик не упомянул эту проблему, хотя проблема в точности идентичная?
Надо полагать, оттого, что проблема — не в точности идентичная.

V>Это ровно один и тот же класс ошибок, вызванных одной и той же причиной — невозможностью в compile-time выразить ВСЕ требуемые ограничения из runtime.
Это какой-то очень широкий класс ошибок. Ну, то есть понятно, что в общем случае проблема — ровно в том, что статическое доказательство корректности произвольной программы сводится к проблеме останова, которая неразрешима.
Но нормальному инженеру недостаточно такого общего доказательства, поэтому мы вводим разные виды и классы ошибок, с которыми и боремся.
В частности, "проблема" нулевой ссылки легко статически разрешима на более-менее любой современной платформе. Даже настольные языки, собранные на коленке энтузиастами, прекрасно обходятся без нулевых ссылок.
Кстати, вопросы индексов в массивах давно закрыты: https://www.cs.cmu.edu/~fp/papers/pldi98dml.pdf. Так то про "невозможность в компайл-тайм" — это лично ваши заблуждения. Развивайтесь, читайте.

V>(в языках, которые претендуют на хоть какую-то эффективность)
Эта фраза тоже выдаёт непонимание сути проблемы. Как раз неэффективное решение проблемы и состоит в переносе проверок в ран-тайм.
Любое компайл-тайм решение получается более эффективным, как только время ожидаемой работы программы становится достаточно большим.

V>И до изобретения исключений, без техники IoC, т.е. без функциональных ср-в в языке, ошибок такого рода в процедурных языках избежать было нельзя, можно было лишь сгенерировать проверочный код компилятором (или использовать какой-нить другой трюк, например как обращение к NULL как к невалидной области памяти, как оно специально сейчас организуется в мейнстримовых архитектурах с защищённой памятью, через аппаратное инициирование исключительной ситуации) и аварийно завершить программу, если проверка на индекс или nil была неудачной. Аналогично некоторые адерс-санитайзеры обкладывают массивы незакоммиченной памятью, чтобы иметь возможность уловить "промахи". Но там улавливание только в рамках этих отступов, т.е. всё-равно ничего не гарантируется, можно "промахнуться" уже на следующую валидную область памяти.
И опять вы складываете в одну кучу рантайм и компайл-тайм проверки. Это вы мухлюете или вправду не видите разницы?

V>Даже если критикуешь себя.


V>Наверно, Хоар еще не совсем выжил из ума, раз не озвучивает альтернативу, потому что альтернатива была проста:
V>- их доработка Алгола вышла бы УГ, была бы отдвинута конкурирующими более вменяемыми языками, а Хоар заслужил бы себе реноме дурачка, который обращает в г-но всё, что попадает к нему в руки.


V>Ты же на голубом глазу рассуждаешь о том, что ради "идейной чистоты" со всем этим можно было бы подождать примерно 30 лет, до эпохи, когда начался резкий рост производительности компьютеров.
Какие ещё 30 лет? Все нужные решения были известны уже тогда, в 60х.

V>ЧТД, еще более слабый пример.
V>Да и при чём тут Java, это надо совсем не разбираться в вопросе. ))
Вижу, что вы совсем не разбираетесь. Зря — потратьте 15 минут, разберитесь в вопросе. Поможет стать лучшим специалистом.

V>Это АПИ потоков современных ОС, Java лишь даёт доступ к этому АПИ, как и ко многому другому АПИ.
Уже не даёт. В том-то и дело — оказалось, что прямой доступ к такому АПИ сильно мешает писать корректные Java-программы.

V>В деле разработки языков вклад Хоара скромен и мне на эту часть его деятельности несколько пофик.
)
V>Хоар внёс заметный вклад в анализ и выработку решений, лежащих в основе современных многозадачных ОС.
А ещё — в верификацию корректности программ. Поэтому когда Тони говорит о проблемах в системе типов Алгола, он понимает, о чём говорит.

V>Синклер, ты всё-таки определись, ты демагог или ты просто неисправимый нуб?
Ну вот, дошли и до перехода на личности. Не умеете вы всё-таки обсуждения вести.

V>Когда разрабатывались эти классы (в среде, где всё выделяется из кучи), вменяемого escape-анализа не существовало.
V>Поэтому решение было единственно верным.
Зачем вы пишете чушь? Не было оно ни единственным, ни верным. Escape-анализ здесь совершенно точно ни при чём.
Я же вам русским по белому написал: в новом стандарте нагрузка на GC меньше, чем в старом — независимо от наличия escape-анализа.
Если непонятно, почему — не стесняйтесь, спрашивайте. Если уж вам трудно на английском пару страничек прочитать и выводы сделать — я могу и перевести, и объяснить.

V>Судя даже по этому обсуждению — без способностей в нашей области некоторым непросто.


V>Ты уже показываешь что плаваешь совсем в азах взаимодействия управляемого и нейтивного кода.
И взаимодействие управляемого и нейтивного кода тут строго ни при чём. Я уже вообще начинаю сомневаться, что вы понимаете семантику Java.

V>Хотя, по переписке оно проще, конечно, водить окружающих за нос.
Это вам так кажется. Вот, к примеру, вам постоянно кажется, что вы по переписке поражаете всех своей широтой кругозора и глубиной знаний.
А на практике большинство читателей от этих ваших прогонов ржёт молча или в голос. Увы.

V>Код работает так, как написано в документации, а не как ожидают те, кто сам себе чего-то надумал.
(facepalm).

V>Ты забыл еще time series, и целое семейство вероятностных, как надстройки над иерархическими индексами (не обязательно B-trees, бо сами B-trees лишь вырожденный случай из своего класса).
Да, забыл. Поделитесь ссылкой, для освежения памяти?

V>Не вижу ничего нового.
V>Вижу попытку сочетаний уже имеющихся подходов.
Скорее всего, вы просто не поняли сути подхода.

S>>плюс значительная компактность

V>Но я не вижу изобретённого способа компактификации.
Это нормально. Вы, помнится, и в статье про оптимизации блокировок для MySQL блуждали в десятке строк псевдокода.

V>Где формула изобретения?
Я же ссылку дал. Читайте. Если непонятно — спрашивайте. Хотя рядом уже даже ссылку на видеолекцию дали, где всё разжёвано максимально понятно, но за 90 минут.

V>Собсно, любые n-tree выразимы через b-tree, но решают недостатки b-tree по оверхеду служебной памяти, по локальности данных и т.д.
Простите моё невежество, а что такое n-tree? И как именно они недостатки B-tree по оверхеду решают?
Или вы B-tree принимаете за бинарные деревья?
В любом случае:

better query and update time than a B+-tree by up to 71% in various dynamic workloads while reducing its space occupancy by four orders of magnitude (from gigabytes to few megabytes).

Это к вопросу о "компактификации".

V>Ты бы не мог впредь не засорять эфир, где тусуются опытные инженерами, всякой наивной мутью от учащихся?
Воинствующее невежество, как оно есть. Увы.

>Просто ты живешь в параллельной Вселенной.
V>Первые примитивнейшые СУБД появились в начале 80-х.
О, ещё порция булшита.

V>А первые вменяемые — к 89-му, а на самом деле в 92-м, после исправления детских ошибок.
V>И там до перебора комбинаторики всевозможных видов индексов еще столько вопросов решить надо было, особенно в плане ХРАНЕНИЯ данных и сопротивляющихся их целостности дисковых операционных систем — у-у-у...
V>Т.е. этот вопрос был даже не десятый.
Вот зачем, зачем вы корчите из себя идиота, пытаясь лезть в области, в которых ничего не знаете?
Удивительная ведь вещь — только я с вами СУБД обсуждаю прямо тут уже лет десять, не меньше. Можно за это время было с нуля всю эту область выучить на уровень эксперта. В профиле у вас с какого-то хрена специализация по MS SQL указана. Нет — упорствуете в невежестве.
Домашнее задание — подготовить ответы на следующие вопросы:
1. В каком году была разработана СУБД IMS?
2. В каком году была разработана СУБД Ingres?
3. В каком году была разработана СУБД System R?
4. С какого года в СУБД применяются B-Tree индексы?
5. В каком году была опубликована первая коммерческая реализация bitmap индексов?

V>Плюс сама эта проблематика не стояла, бо она начинает вовсю стоять на больших объемах данных, а их тогда физически не существовало.
Феерия. Вот прямо жжоте.

V>И вот ты заламываешь руки, что в 60-х годах на несуществующих тогда СУБД (сама теория в 70-х только-только начала прорабатываться) не решали задачи эфффективного индексирования чудовищных размеров данных, пригодных к обработке, хранящихся на хранителях, которых требуемых размеров на тот момент тоже физически не существовало.
Да конечно же решали. Ответ на вопрос 4 найдёте — узнаете, как оно обстояло на самом деле, а не в вашей вымышленной вселенной. Достаточно название статьи прочитать и устыдиться.

V>Тебе не надоело, случаем, делать громкие заявления и быть выпоротым в итоге?
Ах если бы. Всё же ровно наоборот — вы чем больше пишете, тем больше в лужу садитесь.

V>Разумеется, новое дыхание в конце 90-х и начале 2000-х получили теории языков.
Вот как раз тут прямо таки нового появилось не очень много.
V>Без изобретения нового.
Воот! В основном то, что мы наблюдаем — приезд в мейнстрим идей и концепций из 1960х. Так что "теории языков" вычёркиваем.

V>Я когда-то уже высказывался на эти темы ~12 лет назад в ответ молодому и горячему в те года Вольфхануду:
V>http://www.rsdn.org/forum/philosophy/4247637.1
Ну, так и зачем самому себе противоречить?