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

V>>Первые СУБД только появились в начале 80-х и были с нынешней колокольни убоги.
S>Вижу, домашнюю работу вы так и не выполнили.

Попроще лицо...

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


V>

Введение

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

V>

Поколения программистов

V>Для начала разделю программистов по поколениям на основе источников доступной информации, а так же способам программирования, они же парадигмы программирования.

V>

1. Поколение программистов математиков (1940-1960)

а вы это годы рождения имели в виду ?

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

V>>Например?
S>Из самого известного — "ошибка на миллиард долларов" Тони Хоара. (К квалификации Тони вопросы есть?)

Квалификации — нет, а вот её оценке — есть.
Я считаю, что на момент принятия того самого решения — иметь null как вариант значения указателя — оно было правильно, потому что практически реализуемо. Альтернатива была просто неподъёмна с тогдашними средствами.
Главный вопрос — когда же это стало не просто подъёмно, но и необходимо. А вот это, я думаю, уже около 2000.
Пусть Хоар критикует себя тогдашнего сколько угодно, он прав в идеале, но неправ на практике. Конечно, лучше такая самокритичность, чем мания непогрешимости, но трезвый подход — ещё лучше.

V>>Концептуально нового? ))
V>>Например?
S>Ну, например, я не ожидал, что в 21 веке смогут придумать какой-то новый вид скалярных индексов для СУБД. Казалось бы — после B-trees, hash, и bitmap индексов в этой области уже ничего нового не придумать.

LSM tree забыл. Это уже ~2000, граница века.

S>Ан нет — апрель 2020, PGM-index.

Где алгоритмы обычных операций с индексами — добавление, удаление ключа? Как управлять эффективностью хранения? Или это индекс из тех, что строятся один раз для постоянного набора?
Как у него с конкурентностью? Для B-деревьев есть давно разработки с одновременным доступом из нескольких участников с адекватной синхронизацией, а тут?

S>Был ли возможен такой индекс в 1963? Да, конечно. Это не нейронки, обучение которых стало практически пригодным только после массового распространения многоядерных видеокарточек.
S>Математика в основе лежит общеизвестная, сложность алгоритмов — не выше, чем у B-tree. Просто — не додумались.

Или не был такой нужен.

Здравствуйте, netch80, Вы писали:
N>Квалификации — нет, а вот её оценке — есть.
N>Я считаю, что на момент принятия того самого решения — иметь null как вариант значения указателя — оно было правильно, потому что практически реализуемо. Альтернатива была просто неподъёмна с тогдашними средствами.
Интересная гипотеза. В LISP, к примеру, обошлись без null, и ничего, тогдашними средствами всё поднялось.

N>Главный вопрос — когда же это стало не просто подъёмно, но и необходимо. А вот это, я думаю, уже около 2000.
Как видим, языки без нулевых указателей были подъёмны в 1960.
N>Пусть Хоар критикует себя тогдашнего сколько угодно, он прав в идеале, но неправ на практике.
Хороший ход. Ещё можно сказать, что он имел в виду совсем другое.
N>Конечно, лучше такая самокритичность, чем мания непогрешимости, но трезвый подход — ещё лучше.
Я уверен, что у Тони вполне трезвый подход.

N>LSM tree забыл. Это уже ~2000, граница века.
Да, тоже верно.

N>Где алгоритмы обычных операций с индексами — добавление, удаление ключа? Как управлять эффективностью хранения? Или это индекс из тех, что строятся один раз для постоянного набора?
N>Как у него с конкурентностью? Для B-деревьев есть давно разработки с одновременным доступом из нескольких участников с адекватной синхронизацией, а тут?
Настолько детально я не разбирался. С модификациями там всё не вполне очевидно. А вот с конкурентностью всё хорошо известно — все древовидные структуры обрабатываются одинаково.
N>Или не был такой нужен.
Эту гипотезу коллега vdimas уже высказывал. Контраргументы те же — вопросы компресии индексов интересовали разработчиков ещё в ранних 1980х. Это хорошо видно по публикациям статей.
Так что возможность уменьшить размер индекса в пару тысяч раз конечно же была востребована.

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

N>>Квалификации — нет, а вот её оценке — есть.
N>>Я считаю, что на момент принятия того самого решения — иметь null как вариант значения указателя — оно было правильно, потому что практически реализуемо. Альтернатива была просто неподъёмна с тогдашними средствами.
S>Интересная гипотеза. В LISP, к примеру, обошлись без null, и ничего, тогдашними средствами всё поднялось.

В LISP не обошлись без null. В LISP он есть в виде NIL. Только не надо повторять ещё и ко мне ту чушь, что, мол, NIL это "пустой список", а не пустой указатель.
Нет, как раз пустой список реализован в LISP в виде пустого указателя, и тут он ничем не отличается от какой-нибудь C-подобной реализации где struct node с struct node *next, а NULL значит, что список пуст (длины 0).
Чтобы понять это глубже, посмотри, как в LISP работает хак (A.B) для неспискового B, где его используют и почему он нежелателен для общего применения.

N>>Главный вопрос — когда же это стало не просто подъёмно, но и необходимо. А вот это, я думаю, уже около 2000.
S>Как видим, языки без нулевых указателей были подъёмны в 1960.

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

N>>Пусть Хоар критикует себя тогдашнего сколько угодно, он прав в идеале, но неправ на практике.
S>Хороший ход. Ещё можно сказать, что он имел в виду совсем другое.

Ну с тем, кто так скажет, и дискутируй. Мне-то зачм твои ветряные мельницы?

N>>Где алгоритмы обычных операций с индексами — добавление, удаление ключа? Как управлять эффективностью хранения? Или это индекс из тех, что строятся один раз для постоянного набора?
N>>Как у него с конкурентностью? Для B-деревьев есть давно разработки с одновременным доступом из нескольких участников с адекватной синхронизацией, а тут?
S>Настолько детально я не разбирался. С модификациями там всё не вполне очевидно. А вот с конкурентностью всё хорошо известно — все древовидные структуры обрабатываются одинаково.

Точно все?

N>>Или не был такой нужен.
S> Эту гипотезу коллега vdimas уже высказывал. Контраргументы те же — вопросы компресии индексов интересовали разработчиков ещё в ранних 1980х. Это хорошо видно по публикациям статей.
S>Так что возможность уменьшить размер индекса в пару тысяч раз конечно же была востребована.

Теоретическая. Практически же тут есть непреодолимая пропасть — даже две — между 1) реализуемым в теории, 2) реализуемым на практике для константных деревьев и 3) реализуемым на практике для активно изменяемых деревьев. И что "реализуемо на практике" зависит от 100500 факторов.

То же LSM tree тоже ничто не мешало изобрести, например, в 1972 (возьмём за базу публикацию B-деревьев), он в разы проще тех же B-деревьев, но мешали аж три вещи:
1) недостаток места (чтобы индекс занимал место в 2-4 раза больше — не могли себе позволить);
2) отсутствие потребности в алгоритме для потоковой записи крупными порциями вместо одного блока;
3) проблема с организацией фоновых сжатий индекса (сейчас решается, например, через фоновые нити — а тогда надо было делать машину состояний и мириться с замираниями на сбор крупных порций).
Возможно, его тогда и изобретали кучу раз. А потом думали "и зачем эта фигня?" и забывали.
А вот ближе к 2000 начали давить тормоза позиционирования HDD, добило — появление SSD с записями порциями типа 128KB. А дисковое место на индексы стало доступно.
Вот то же самое и с потребностями при разработке языков.

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

S>Здравствуйте, netch80, Вы писали:
N>>Квалификации — нет, а вот её оценке — есть.
N>>Я считаю, что на момент принятия того самого решения — иметь null как вариант значения указателя — оно было правильно, потому что практически реализуемо. Альтернатива была просто неподъёмна с тогдашними средствами.
S>Интересная гипотеза. В LISP, к примеру, обошлись без null, и ничего, тогдашними средствами всё поднялось.

А что имеется в виду под неподъемностью без null в ЯП того времени? Доп. анализ от компилятора?

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

S>А что имеется в виду под неподъемностью без null в ЯП того времени? Доп. анализ от компилятора?
Это не ко мне вопрос, а к netch80.
Хоар считает, что уже в ALGOL W можно было обойтись без константы NULL. Пришлось бы для каких-то случаев реализовывать паттерн null objeсt, но уже при системе типов ALGOL W это означало возможность описания non-nullable types, контролируемых компилятором.

Здравствуйте, ботаныч, Вы писали:

V>>Поколения программистов
V>>Для начала разделю программистов по поколениям на основе источников доступной информации, а так же способам программирования, они же парадигмы программирования.
V>>1. Поколение программистов математиков (1940-1960)
Б> а вы это годы рождения имели в виду ?

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