Сообщение Re[4]: Почему программисты прошлого были умнее от 27.11.2022 13:15
Изменено 27.11.2022 13:28 vdimas
Re[4]: Почему программисты прошлого были умнее
Здравствуйте, Sinclair, Вы писали:
V>>А как ты увидишь, если речь об усреднённых вещах?
V>>Ты собирал статистику, проводил собеседования в разные годы?
S>Бремя доказательства лежит на утверждающем.
Я собеседовал десятки, если не больше сотни в разные годы.
И тенденция слишком однозначная, чтобы это было простым совпадением на многих десятках людей.
S>Это оппонент делает утверждение о снижении среднего уровня программистов. Так что давайте адресуем вопрос про статистику и собеседования к нему.
Так это хорошо видно по молодняку, если отслеживать появляющийся в конторах молодняк в течении длительного времени.
И дело не в уровне программистов, дело кое в чём катастрофическом другом — профессия воспринимается всё более обыденно, всё меньше горят глаза, всё менее ЛЮБОПЫТНО.
http://www.rsdn.org/forum/philosophy/2130680.1
Наше поколение — это поколение исследователей, без преувеличения.
Чем дальше, тем такие товарищи встречаются всё реже.
Да, встречаются, но это теперь, скорее, исключение.
Раньше было редким исключением наоборот.
Мы ж бессеребреники были, ЗП были вовсе не космические, шли осознанно, испытывая тягу к предмету.
Теперь часто идут потому что это способ неплохо устроиться в этой жизни.
Ей-богу не знаю как на Западе (они мне в среднем намного слабее казались уже во второй половине 90-х), но у нас финансовый вопрос влияет на мотивацию, бо 300+ тыс в месяц для 3-5- лет стажа на дороге не валяются, т.е. отсутствует чистота эксперимента. ))
S>А так — да, конечно же я проводил собеседования в разные годы.
S>Ну, и кроме собеседований я преподаю в ВУЗе, поэтому могу оценивать распределение уровней квалификации сегодняшних бакалавров и магистров. Никаких признаков проблемы, обозначенной ТС, не наблюдается ни там, ни там.
А с чем ты сравниваешь?
И в насколько разные это были годы?
Прблема стала себя проявлять в полный рост примерно с середины нулевых, когда ЗП программеров у нас доросли до неадекватных величин.
До этого неуклонный рост ЗП был примерно с 97-го года, по мере покрытия интернетом экс-СССР.
Проблема примерно в следующем — увлекающийся программист осваивал материала по специальности примерно раз в 10 больше, чем давала программа ВУЗ-а.
Сейчас доля таких студентовв разы ниже, дай бог 1-2 на группу.
И у тебя разве есть достаточная выборка по однокурсникам хотя бы до начала нулевых, чтобы сравнивать с тем, как оно есть сейчас?
А меня есть по тем временам и по нынешним, бо несколько студентов вытягивал из болота за волосы как раз по специальностям IT (детей друзей и родственников, своих подтянул лишь однажды, и то задание было несколько непрофильным — по цифровой обработке сигналов, им давали теорию на слабом уровне, в сравнении с тем, как давали нам).
Я в курсе среднего нынешнего уровня студентов в группах в различных ВУЗ-ах Украины, России, и даже двух европейских.
Буквально полтора года назад помог с курсовой работой одному человеку из европейского ВУЗ-а, потом тщательно спросил про уровень работ остальных сокурсников.
В общем, справились на должном уровне всего трое, включая моего подопечного (который самостоятельно не справился), а там была сущая херня, примерно которую мы делали на 3-м курсе.
Только условия для выполнения этой херни на порядки более удобные — из Arduino IDE, доступен ЯВУ, схема выч. модуля дана, её проектировать не надо, перед тем как для модуля ПО, и вообще "всё работает само", тепличные условия, нам когда-то это и не снилось. ))
И всё-равно 20 чел из 23-х на должном уровне ниасилили.
У нас осиливал десяток запросто и еще десяток с пары подсказок.
Не осиливали самостоятельно большинство девочек и буквально один случайный мальчик в группе.
Блин, у нас несколько девах в группе САМОСТОЯТЕЛЬНО справились с менеджерами памяти, с пакетными шедуллерами IO и прочими такими задачами на 3-м курсе.
По сравнению с этим тот западный курсовик за 4-й курс — тьфу полнейшее.
Да еще в тепличных условиях тулсетов/окружения.
В группе сыновей тоже десятка внемяемых не набралось, хотя там один из 3-х топовых ВУЗ-ов РФ.
V>>Например?
S>Из самого известного — "ошибка на миллиард долларов" Тони Хоара. (К квалификации Тони вопросы есть?)
Вот тут звиздёшь:
И вообще, основные динамические структуры данных на тот момент давно были разработаны, не только связанный список.
Без nil никуда.
И альтернатив в процедурном программировании нет до сих пор, даже в Kotlin.
Альтернатива тут возможна только через IoС, т.е. в функциональных языках, когда некоему акцессору (итератору, скажем), подаётся колбэк.
Или когда некоему optional<T> подаётся пара колбэков — для наличия значения и для его отсутствия.
(примерно как работает диспетчеризация ф-ий в Хаскеле над размеченными union)
Других техник борьбы с nil, кроме диспетчеризации на манер IoC, в природе не существует, даже в Kotlin.
И да, в 60-е годы эта техника была уже известна и показывала себя откровенно хреново, как и сегодня, собсно.
А фраза целиком лишь характеризует уже старого и недостаточно умного человека:
С возрастом строить сложные конструкты в голове всё сложнее, т.е. ему сложнее удержать в памяти кучу одновременных противоречивых требований прямых и порождаемых ими зависимых.
Сохрани он эту способность до сих пор — не писал бы откровенные глупости.
В молодости был умнее, мог оперировать большей размерностью условий, в которых принимал решения.
Далее.
В точности проблема нулевых ссылок повторяется в массивах, к которым обращаются по индексу.
И чего ж старик не упомянул эту проблему, хотя проблема в точности идентичная?
Это ровно один и тот же класс ошибок, вызванных одной и той же причиной — невозможностью в compile-time выразить ВСЕ требуемые ограничения из runtime.
(в языках, которые претендуют на хоть какую-то эффективность)
И до изобретения исключений, без техники IoC, т.е. без функциолнальных ср-в в языке, ошибок такого рода в процедурных языках избежать было нельзя, можно было лишь сгенерировать проверочный код и аварийно завершить программу, если проверка на индекс или nil была неудачной.
Далее.
Критикуя — предлагай!
Даже если критикуешь себя.
Наверно, Хоар еще не совсем выжил из ума, раз не озвучивает альтернативу, потому что альтернатива была проста:
— их доработка Алгола вышла бы УГ, была бы отдвинута конкурирующими более вменяемыми языками, а Хоар заслужил бы себе реноме дурачка, который обращает в г-но всё, что попадает к нему в руки.
Или, если бы весь мир сошёл с ума одновременно с ним, то эта ошибка стоила бы индустрии не смешные миллиарды долларов, а ВСЕМУ МИРУ сотни триллионов, по причине задержки примерно на 30 лет развития IT из-за неадекватного железу ПО.
Последствия "правильного" решения, если бы оно было принято обязательно в любых ЯВУ на нашем шарике были бы таковы, что сегодня население Земли никак не могло бы вырасти до 8 млрд, потому что этот рост вызван лишь ростом среднего благосостояния людей и ничем больше.
Ты же на голубом глазу рассуждаешь о том, что ради "идейной чистоты" со всем этим можно было бы подождать примерно 30 лет, до эпохи, когда начался резкий рост производительности компьютеров.
S>Из чуть менее известного — thread.stop()/suspend()/resume() в Java 1.0. Гослинг вроде тоже отнюдь не новичок, но тем не менее принял заведомо неудачное решение.
ЧТД, еще более слабый пример.
Да и при чём тут Java, это надо совсем не разбираться в вопросе. ))
Это АПИ потоков современных ОС, Java лишь даёт доступ к этому АПИ, как и ко многому другому АПИ.
Не хочешь, пройтись по сокетам, обычным и NIO из Java?
С высоты сегодняшнего понимания проблематики — уродство и то, и это.
Но это уродство — тоже лишь языковая обертка над обычными и асинхронными сокетами в ОС.
А откуда сокеты таковы в ОС?
Из-за уродства сетевой модели, даже OSI 7, рядом с которым семейство IP выглядит имбициллом.
А откуда это уродство вообще берется? — из-за необходимости разделять на независимые уровни различные задачи.
Из-за необходимости пользоваться сетевым транспортом не только высокоуровневым программам, но и низкоуровневыми.
Даже размером со спичесный коробок, как сказали бы в 90-х, или размером со спичечную головку сегодня.
К уродству приводит выбор из сомна противоречивых требований, из необходимости учесть кучу больших и малых факторов, из необходимости обеспечивать затем обратную совместимость в течении многих десятков лет жизни технологии, дабы технологии хотя бы успевали себя окупать.
В таком выборе обязательно что-нибудь приносится в жертву.
Например, в случае OSI в жертву было принесено доверие иерархических уровней сетей друг другу, т.е. в целом там выходит плохая защита от злоумышленничества.
Этот казус более-менее решает семейство IP, но уже в жертву был принесён здравый смысл — в одних случаях имеем многократное неоправданное дублирование служебных данных пакетов, в других случаях имеем невозможность дополнить пакеты нужной служебной информацией.
Собсно, принципы разметки пакетов IP придумыали имбициллы. Это не ругательство, это факт. Видна рука, скажем прямо, полупрофессионалов.
Скорее всего, этим занимались не системотехники, а смежники или вообще спецы в других дисциплинах, типа тебя, которые нахватались IT сугубо из любопытства.
Отсюда детские ошибки.
А вот "ошибка" с nil нифига не детская и не ошибка вовсе.
Чел прямо говорит, что принял это решение осознанно.
Просто из-за возраста не в состоянии восстановить полный ход тех своих рассуждений.
Жаль, конечно, но нас всех это ждёт.
Уважаю Хоара за что он делал тогда, и не собираюсь принимать во внимание то, что он говорит сейчас.
В деле разработки языков вклад Хоара скромен и мне на эту часть его деятельности несколько пофик.
Хоар внёс заметный вклад в анализ и выработку решений, лежащих в основе современных многозадачных ОС.
И не только в плане механизмов синхронизации, но даже в современных менеджерах памяти.
И да, весь этот код в той области задач писан через nil и обращения к массивам через индексы. ))
Добро пожаловать в реальность, Нео.
S>Ещё в ту же коробку — Java.util.Date.
S>Это практически хрестоматийный пример того, как можно сделать неправильно буквально всё. Начиная с того, что тип с value-семантикой реализован как mutable
Синклер, ты всё-таки определись, ты демагог или ты просто неисправимый нуб?
Когда разрабатывались эти классы (в среде, где всё выделяется из кучи), вменяемого escape-анализа не существовало.
Поэтому решение было единственно верным.
Да и сейчас вменяемого escape-анализа не существует и все серьёзные работы на эту тему сходятся в итоге на том, что в рамках динамического JIT это принципиально невозможно.
То бишь, протестовать тут можно лишь по классике — как двоечники протестуют против невыученных уроков, и тогда ты неисправимый нуб, обреченынй вызывать насмешки до старости.
Или ты всё это понимаешь — и тогда ты нечестивый демагог, наше вам фи.
V>>Я вижу, что принятые ранее решения исходили (а) из ограничений аппаратуры и (б) были расчитаны в среднем на более способного программиста.
S>
Приведённые мной примеры — это грабли, которые никакого отношения к ограничениям аппаратуры не имеют
Всё-таки неиправимый нуб?
S>и от программиста ожидают не каких-то особенных способностей.
Судя даже по этому обсуждению — без способностей в нашей области некоторым непросто.
S>Ну, вот к примеру — с т.з. той же java.util.Date, "способный" программист отличается от "неспособного" тем, что в геттерах свойств выполняет defensive copy.
Ты действительно не понимаешь, почему так было сделано?
Так ты нуб, или демагог.
Ты уже показываешь что плаваешь совсем в азах взаимодействия управляемого и нейтивного кода.
Поэтому я так до сих пор и не могу определиться.
Но неужели столь вопиющий нуб так ловко играет хотя бы продвинутого юзера? ))
Хотя, по переписке оно проще, конечно, водить окружающих за нос.
В живом разговоре, когда к гуглу за ответом па бырому не сбегаешь, лучше видно, ху из ху.
S>При этом никакого существенного улучшения качества программы не происходит — помимо замусоривания хипа и увеличения нагрузки на GC (что там у нас по ограничениям аппаратуры), клиентский код по-прежнему работает не так, как ожидают его авторы.
Код работает так, как написано в документации, а не как ожидают те, кто сам себе чего-то надумал.
V>>Концептуально нового? ))
V>>Например?
S>Ну, например, я не ожидал, что в 21 веке смогут придумать какой-то новый вид скалярных индексов для СУБД.
Во-первых, у тебя хромает русскоязычная терминология, т.е. ты не знаешь, о чём ты говоришь.
Во-вторых, никаких видом индекса не придумали ни одного в 21-м веке.
S>Казалось бы — после B-trees, hash, и bitmap индексов в этой области уже ничего нового не придумать.
Ты забыл еще time series, и целое семейство вероятностных, как надстройки над иерархическими индексами (не обязательно B-trees, бо сами B-trees лишь вырожденный случай из своего класса).
S>Ан нет — апрель 2020, PGM-index.
Не вижу ничего нового.
Вижу попытка сочетаний уже имеющихся подходов.
Итого, Синклер лжец. ))
Или нуб, опять самостоятельно не разобрался, как маленький.
S>плюс значительная компактность
Но я не вижу изобретённого способа компактификации.
Где формула изобретения?
Или мне тебе на пальцах показывать, как можно хранить иерархические данные не только в бинарных узлах, где оверхед по занимаемой памяти чуть ли не втрое? ))
Мы же именно с тобой обсуждали рализации n-tree.
Собсно, любые n-tree выразимы через b-tree, но решают недостатки b-tree по оверхеду служебной памяти, по локальности данных и т.д.
S>(а, значит, меньше io-нагрузка, более высокий cache hit ratio, и все вытекающие).
Зевал так, что чуть рот не порвался...
Синклер, ты обещал новые концепции...
Значительные изобретения...
А кормишь булшитом, уровня инженерной разработки.
Блин, различные шедуллеры в современных ОС и в разы сложнее в плане использованного понимания происходящего, статейка от новичков в IT (зародышей-аспирантов) по ссылке.
Ты бы не мог впредь не засорять эфир, где тусуются опытные инженерами, всякой наивной мутью от учащихся?
Многие оформляют кандидатские к 27-28 годам, будучи еще при этом совсем еще зелеными в области IT, поражающими воображение своей наивностью и отсутствием "набитости руки" в этой области человеческой деятельности, бо копают один-два направления в аспирантуре, причём, весьма изолированно от других областей.
В этом и заключается отличие инженерной от научной работы в IT — научники изучают изолированные аспекты, а инженеры изобретают способы совмещения аспектов.
Характер и тех и других работ исследовательский, но объем одновременно оперируемой информации у инженера обычно в разы больше.
Нескольким таким горе-кандидатам я когда-то помогал, да и не только я.
Опытные инженеры всегда помогают зеленым аспирантам, это нормально и правильно.
Ненормально, когда опытных инженеров в аспирантов тыкают. ))
Брысь по яслям, как грится.
S>Был ли возможен такой индекс в 1963? Да, конечно. Это не нейронки, обучение которых стало практически пригодным только после массового распространения многоядерных видеокарточек.
S>Математика в основе лежит общеизвестная, сложность алгоритмов — не выше, чем у B-tree. Просто — не додумались.
Просто ты живешь в параллельной Вселенной.
Первые примитивнейшые СУБД появились в начале 80-х.
А первые вменяемые — к 89-му, а на самом деле в 92-м, после исправления детских ошибок.
И там до перебора комбинаторики всевозможных видов индексов еще столько вопросов решить надо было, особенно в плане ХРАНЕНИЯ данных и сопротивляющихся их целостности дисковых операционных систем — у-у-у...
Т.е. этот вопрос был даже не десятый.
Плюс сама эта прблематика не стояла, бо она начинает вовсю стоять на больших объемах данных, а их тогда физически несуществовало.
И вот ты заламываешь руки, что в 60-х годах на несуществующих тогда СУБД (сама теория в 70-х только-только начала прорабатывать) не решали задачи эфффективного индексирования чудовищных размеров данных, пригодных к обработке, хранящихся на хранителях, которых требуемых размеров на тот момент тоже физически не существовало.
В этом сюрре прекрасно всё. ))
Дисциллированное нубство какое-то...
V>>Я, наоборот, концептуально нового уже давно не вижу.
S>
==========================
Тебе не надоело, случаем, делать громкие заявления и быть выпоротым в итоге?
Зачем так орать-то громкими заявлениями?
Разумеется, новое дыхание в конце 90-х и начале 2000-х получили теории языков.
Причина была очевидной — производительность компьютеров росла экспоненциально, виделось, что IT сможет позволить себе, наконец, "излишества".
Но что характерно — в этих иследованиях были подняты нафталиновые вопросы.
Без изобретения нового.
Я когда-то уже высказывался на эти темы ~12 лет назад в ответ молодому и горячему в те года Вольфхануду:
http://www.rsdn.org/forum/philosophy/4247637.1
V>>А как ты увидишь, если речь об усреднённых вещах?
V>>Ты собирал статистику, проводил собеседования в разные годы?
S>Бремя доказательства лежит на утверждающем.
Я собеседовал десятки, если не больше сотни в разные годы.
И тенденция слишком однозначная, чтобы это было простым совпадением на многих десятках людей.
S>Это оппонент делает утверждение о снижении среднего уровня программистов. Так что давайте адресуем вопрос про статистику и собеседования к нему.
Так это хорошо видно по молодняку, если отслеживать появляющийся в конторах молодняк в течении длительного времени.
И дело не в уровне программистов, дело кое в чём катастрофическом другом — профессия воспринимается всё более обыденно, всё меньше горят глаза, всё менее ЛЮБОПЫТНО.
http://www.rsdn.org/forum/philosophy/2130680.1
Наше поколение — это поколение исследователей, без преувеличения.
Чем дальше, тем такие товарищи встречаются всё реже.
Да, встречаются, но это теперь, скорее, исключение.
Раньше было редким исключением наоборот.
Мы ж бессеребреники были, ЗП были вовсе не космические, шли осознанно, испытывая тягу к предмету.
Теперь часто идут потому что это способ неплохо устроиться в этой жизни.
Ей-богу не знаю как на Западе (они мне в среднем намного слабее казались уже во второй половине 90-х), но у нас финансовый вопрос влияет на мотивацию, бо 300+ тыс в месяц для 3-5- лет стажа на дороге не валяются, т.е. отсутствует чистота эксперимента. ))
S>А так — да, конечно же я проводил собеседования в разные годы.
S>Ну, и кроме собеседований я преподаю в ВУЗе, поэтому могу оценивать распределение уровней квалификации сегодняшних бакалавров и магистров. Никаких признаков проблемы, обозначенной ТС, не наблюдается ни там, ни там.
А с чем ты сравниваешь?
И в насколько разные это были годы?
Прблема стала себя проявлять в полный рост примерно с середины нулевых, когда ЗП программеров у нас доросли до неадекватных величин.
До этого неуклонный рост ЗП был примерно с 97-го года, по мере покрытия интернетом экс-СССР.
Проблема примерно в следующем — увлекающийся программист осваивал материала по специальности примерно раз в 10 больше, чем давала программа ВУЗ-а.
Сейчас доля таких студентовв разы ниже, дай бог 1-2 на группу.
И у тебя разве есть достаточная выборка по однокурсникам хотя бы до начала нулевых, чтобы сравнивать с тем, как оно есть сейчас?
А меня есть по тем временам и по нынешним, бо несколько студентов вытягивал из болота за волосы как раз по специальностям IT (детей друзей и родственников, своих подтянул лишь однажды, и то задание было несколько непрофильным — по цифровой обработке сигналов, им давали теорию на слабом уровне, в сравнении с тем, как давали нам).
Я в курсе среднего нынешнего уровня студентов в группах в различных ВУЗ-ах Украины, России, и даже двух европейских.
Буквально полтора года назад помог с курсовой работой одному человеку из европейского ВУЗ-а, потом тщательно спросил про уровень работ остальных сокурсников.
В общем, справились на должном уровне всего трое, включая моего подопечного (который самостоятельно не справился), а там была сущая херня, примерно которую мы делали на 3-м курсе.
Только условия для выполнения этой херни на порядки более удобные — из Arduino IDE, доступен ЯВУ, схема выч. модуля дана, её проектировать не надо, перед тем как для модуля ПО, и вообще "всё работает само", тепличные условия, нам когда-то это и не снилось. ))
И всё-равно 20 чел из 23-х на должном уровне ниасилили.
У нас осиливал десяток запросто и еще десяток с пары подсказок.
Не осиливали самостоятельно большинство девочек и буквально один случайный мальчик в группе.
Блин, у нас несколько девах в группе САМОСТОЯТЕЛЬНО справились с менеджерами памяти, с пакетными шедуллерами IO и прочими такими задачами на 3-м курсе.
По сравнению с этим тот западный курсовик за 4-й курс — тьфу полнейшее.
Да еще в тепличных условиях тулсетов/окружения.
В группе сыновей тоже десятка внемяемых не набралось, хотя там один из 3-х топовых ВУЗ-ов РФ.
V>>Например?
S>Из самого известного — "ошибка на миллиард долларов" Тони Хоара. (К квалификации Тони вопросы есть?)
Вот тут звиздёшь:
Чел попытался присвоить себе "ошибку", которая до него была уже "сделана" эдак тысячекратно, например, тот же nil в Lisp.Я называю нулевую ссылку своей ошибкой на миллиард долларов. Она была изобретена в 1965 году, когда я разработал первую всеобъемлющую систему ссылочных типов на объектно-ориентированном языке (АЛГОЛ W).
И вообще, основные динамические структуры данных на тот момент давно были разработаны, не только связанный список.
Без nil никуда.
И альтернатив в процедурном программировании нет до сих пор, даже в Kotlin.
Альтернатива тут возможна только через IoС, т.е. в функциональных языках, когда некоему акцессору (итератору, скажем), подаётся колбэк.
Или когда некоему optional<T> подаётся пара колбэков — для наличия значения и для его отсутствия.
(примерно как работает диспетчеризация ф-ий в Хаскеле над размеченными union)
Других техник борьбы с nil, кроме диспетчеризации на манер IoC, в природе не существует, даже в Kotlin.
И да, в 60-е годы эта техника была уже известна и показывала себя откровенно хреново, как и сегодня, собсно.
А фраза целиком лишь характеризует уже старого и недостаточно умного человека:
Ошибка уродливее, чем обратная косая черта в Windows, более странная, чем ===, более распространенная, чем PHP, более неудачная, чем CORS, и более тревожная, чем дженерики Java. XMLHttpRequest, более сложный для понимания, чем препроцессор C, более подверженный фрагментации, чем MongoDB, и более прискорбный, чем UTF-16.
С возрастом строить сложные конструкты в голове всё сложнее, т.е. ему сложнее удержать в памяти кучу одновременных противоречивых требований прямых и порождаемых ими зависимых.
Сохрани он эту способность до сих пор — не писал бы откровенные глупости.
В молодости был умнее, мог оперировать большей размерностью условий, в которых принимал решения.
Далее.
В точности проблема нулевых ссылок повторяется в массивах, к которым обращаются по индексу.
И чего ж старик не упомянул эту проблему, хотя проблема в точности идентичная?
Это ровно один и тот же класс ошибок, вызванных одной и той же причиной — невозможностью в compile-time выразить ВСЕ требуемые ограничения из runtime.
(в языках, которые претендуют на хоть какую-то эффективность)
И до изобретения исключений, без техники IoC, т.е. без функциолнальных ср-в в языке, ошибок такого рода в процедурных языках избежать было нельзя, можно было лишь сгенерировать проверочный код и аварийно завершить программу, если проверка на индекс или nil была неудачной.
Далее.
Критикуя — предлагай!
Даже если критикуешь себя.
Наверно, Хоар еще не совсем выжил из ума, раз не озвучивает альтернативу, потому что альтернатива была проста:
— их доработка Алгола вышла бы УГ, была бы отдвинута конкурирующими более вменяемыми языками, а Хоар заслужил бы себе реноме дурачка, который обращает в г-но всё, что попадает к нему в руки.
Или, если бы весь мир сошёл с ума одновременно с ним, то эта ошибка стоила бы индустрии не смешные миллиарды долларов, а ВСЕМУ МИРУ сотни триллионов, по причине задержки примерно на 30 лет развития IT из-за неадекватного железу ПО.
Последствия "правильного" решения, если бы оно было принято обязательно в любых ЯВУ на нашем шарике были бы таковы, что сегодня население Земли никак не могло бы вырасти до 8 млрд, потому что этот рост вызван лишь ростом среднего благосостояния людей и ничем больше.
Ты же на голубом глазу рассуждаешь о том, что ради "идейной чистоты" со всем этим можно было бы подождать примерно 30 лет, до эпохи, когда начался резкий рост производительности компьютеров.
S>Из чуть менее известного — thread.stop()/suspend()/resume() в Java 1.0. Гослинг вроде тоже отнюдь не новичок, но тем не менее принял заведомо неудачное решение.
ЧТД, еще более слабый пример.
Да и при чём тут Java, это надо совсем не разбираться в вопросе. ))
Это АПИ потоков современных ОС, Java лишь даёт доступ к этому АПИ, как и ко многому другому АПИ.
Не хочешь, пройтись по сокетам, обычным и NIO из Java?
С высоты сегодняшнего понимания проблематики — уродство и то, и это.
Но это уродство — тоже лишь языковая обертка над обычными и асинхронными сокетами в ОС.
А откуда сокеты таковы в ОС?
Из-за уродства сетевой модели, даже OSI 7, рядом с которым семейство IP выглядит имбициллом.
А откуда это уродство вообще берется? — из-за необходимости разделять на независимые уровни различные задачи.
Из-за необходимости пользоваться сетевым транспортом не только высокоуровневым программам, но и низкоуровневыми.
Даже размером со спичесный коробок, как сказали бы в 90-х, или размером со спичечную головку сегодня.
К уродству приводит выбор из сомна противоречивых требований, из необходимости учесть кучу больших и малых факторов, из необходимости обеспечивать затем обратную совместимость в течении многих десятков лет жизни технологии, дабы технологии хотя бы успевали себя окупать.
В таком выборе обязательно что-нибудь приносится в жертву.
Например, в случае OSI в жертву было принесено доверие иерархических уровней сетей друг другу, т.е. в целом там выходит плохая защита от злоумышленничества.
Этот казус более-менее решает семейство IP, но уже в жертву был принесён здравый смысл — в одних случаях имеем многократное неоправданное дублирование служебных данных пакетов, в других случаях имеем невозможность дополнить пакеты нужной служебной информацией.
Собсно, принципы разметки пакетов IP придумыали имбициллы. Это не ругательство, это факт. Видна рука, скажем прямо, полупрофессионалов.
Скорее всего, этим занимались не системотехники, а смежники или вообще спецы в других дисциплинах, типа тебя, которые нахватались IT сугубо из любопытства.
Отсюда детские ошибки.
А вот "ошибка" с nil нифига не детская и не ошибка вовсе.
Чел прямо говорит, что принял это решение осознанно.
Просто из-за возраста не в состоянии восстановить полный ход тех своих рассуждений.
Жаль, конечно, но нас всех это ждёт.
Уважаю Хоара за что он делал тогда, и не собираюсь принимать во внимание то, что он говорит сейчас.
В деле разработки языков вклад Хоара скромен и мне на эту часть его деятельности несколько пофик.
Хоар внёс заметный вклад в анализ и выработку решений, лежащих в основе современных многозадачных ОС.
И не только в плане механизмов синхронизации, но даже в современных менеджерах памяти.
И да, весь этот код в той области задач писан через nil и обращения к массивам через индексы. ))
Добро пожаловать в реальность, Нео.
S>Ещё в ту же коробку — Java.util.Date.
S>Это практически хрестоматийный пример того, как можно сделать неправильно буквально всё. Начиная с того, что тип с value-семантикой реализован как mutable
Синклер, ты всё-таки определись, ты демагог или ты просто неисправимый нуб?
Когда разрабатывались эти классы (в среде, где всё выделяется из кучи), вменяемого escape-анализа не существовало.
Поэтому решение было единственно верным.
Да и сейчас вменяемого escape-анализа не существует и все серьёзные работы на эту тему сходятся в итоге на том, что в рамках динамического JIT это принципиально невозможно.
То бишь, протестовать тут можно лишь по классике — как двоечники протестуют против невыученных уроков, и тогда ты неисправимый нуб, обреченынй вызывать насмешки до старости.
Или ты всё это понимаешь — и тогда ты нечестивый демагог, наше вам фи.
V>>Я вижу, что принятые ранее решения исходили (а) из ограничений аппаратуры и (б) были расчитаны в среднем на более способного программиста.
S>
Приведённые мной примеры — это грабли, которые никакого отношения к ограничениям аппаратуры не имеютВсё-таки неиправимый нуб?
S>и от программиста ожидают не каких-то особенных способностей.
Судя даже по этому обсуждению — без способностей в нашей области некоторым непросто.
S>Ну, вот к примеру — с т.з. той же java.util.Date, "способный" программист отличается от "неспособного" тем, что в геттерах свойств выполняет defensive copy.
Ты действительно не понимаешь, почему так было сделано?
Так ты нуб, или демагог.
Ты уже показываешь что плаваешь совсем в азах взаимодействия управляемого и нейтивного кода.
Поэтому я так до сих пор и не могу определиться.
Но неужели столь вопиющий нуб так ловко играет хотя бы продвинутого юзера? ))
Хотя, по переписке оно проще, конечно, водить окружающих за нос.
В живом разговоре, когда к гуглу за ответом па бырому не сбегаешь, лучше видно, ху из ху.
S>При этом никакого существенного улучшения качества программы не происходит — помимо замусоривания хипа и увеличения нагрузки на GC (что там у нас по ограничениям аппаратуры), клиентский код по-прежнему работает не так, как ожидают его авторы.
Код работает так, как написано в документации, а не как ожидают те, кто сам себе чего-то надумал.
V>>Концептуально нового? ))
V>>Например?
S>Ну, например, я не ожидал, что в 21 веке смогут придумать какой-то новый вид скалярных индексов для СУБД.
Во-первых, у тебя хромает русскоязычная терминология, т.е. ты не знаешь, о чём ты говоришь.
Во-вторых, никаких видом индекса не придумали ни одного в 21-м веке.
S>Казалось бы — после B-trees, hash, и bitmap индексов в этой области уже ничего нового не придумать.
Ты забыл еще time series, и целое семейство вероятностных, как надстройки над иерархическими индексами (не обязательно B-trees, бо сами B-trees лишь вырожденный случай из своего класса).
S>Ан нет — апрель 2020, PGM-index.
Не вижу ничего нового.
Вижу попытка сочетаний уже имеющихся подходов.
Итого, Синклер лжец. ))
Или нуб, опять самостоятельно не разобрался, как маленький.
S>плюс значительная компактность
Но я не вижу изобретённого способа компактификации.
Где формула изобретения?
Или мне тебе на пальцах показывать, как можно хранить иерархические данные не только в бинарных узлах, где оверхед по занимаемой памяти чуть ли не втрое? ))
Мы же именно с тобой обсуждали рализации n-tree.
Собсно, любые n-tree выразимы через b-tree, но решают недостатки b-tree по оверхеду служебной памяти, по локальности данных и т.д.
S>(а, значит, меньше io-нагрузка, более высокий cache hit ratio, и все вытекающие).
Зевал так, что чуть рот не порвался...
Синклер, ты обещал новые концепции...
Значительные изобретения...
А кормишь булшитом, уровня инженерной разработки.
Блин, различные шедуллеры в современных ОС и в разы сложнее в плане использованного понимания происходящего, статейка от новичков в IT (зародышей-аспирантов) по ссылке.
Ты бы не мог впредь не засорять эфир, где тусуются опытные инженерами, всякой наивной мутью от учащихся?
Многие оформляют кандидатские к 27-28 годам, будучи еще при этом совсем еще зелеными в области IT, поражающими воображение своей наивностью и отсутствием "набитости руки" в этой области человеческой деятельности, бо копают один-два направления в аспирантуре, причём, весьма изолированно от других областей.
В этом и заключается отличие инженерной от научной работы в IT — научники изучают изолированные аспекты, а инженеры изобретают способы совмещения аспектов.
Характер и тех и других работ исследовательский, но объем одновременно оперируемой информации у инженера обычно в разы больше.
Нескольким таким горе-кандидатам я когда-то помогал, да и не только я.
Опытные инженеры всегда помогают зеленым аспирантам, это нормально и правильно.
Ненормально, когда опытных инженеров в аспирантов тыкают. ))
Брысь по яслям, как грится.
S>Был ли возможен такой индекс в 1963? Да, конечно. Это не нейронки, обучение которых стало практически пригодным только после массового распространения многоядерных видеокарточек.
S>Математика в основе лежит общеизвестная, сложность алгоритмов — не выше, чем у B-tree. Просто — не додумались.
Просто ты живешь в параллельной Вселенной.
Первые примитивнейшые СУБД появились в начале 80-х.
А первые вменяемые — к 89-му, а на самом деле в 92-м, после исправления детских ошибок.
И там до перебора комбинаторики всевозможных видов индексов еще столько вопросов решить надо было, особенно в плане ХРАНЕНИЯ данных и сопротивляющихся их целостности дисковых операционных систем — у-у-у...
Т.е. этот вопрос был даже не десятый.
Плюс сама эта прблематика не стояла, бо она начинает вовсю стоять на больших объемах данных, а их тогда физически несуществовало.
И вот ты заламываешь руки, что в 60-х годах на несуществующих тогда СУБД (сама теория в 70-х только-только начала прорабатывать) не решали задачи эфффективного индексирования чудовищных размеров данных, пригодных к обработке, хранящихся на хранителях, которых требуемых размеров на тот момент тоже физически не существовало.
В этом сюрре прекрасно всё. ))
Дисциллированное нубство какое-то...
V>>Я, наоборот, концептуально нового уже давно не вижу.
S>
==========================
Тебе не надоело, случаем, делать громкие заявления и быть выпоротым в итоге?
Зачем так орать-то громкими заявлениями?
Разумеется, новое дыхание в конце 90-х и начале 2000-х получили теории языков.
Причина была очевидной — производительность компьютеров росла экспоненциально, виделось, что IT сможет позволить себе, наконец, "излишества".
Но что характерно — в этих иследованиях были подняты нафталиновые вопросы.
Без изобретения нового.
Я когда-то уже высказывался на эти темы ~12 лет назад в ответ молодому и горячему в те года Вольфхануду:
http://www.rsdn.org/forum/philosophy/4247637.1
Re[4]: Почему программисты прошлого были умнее
Здравствуйте, Sinclair, Вы писали:
V>>А как ты увидишь, если речь об усреднённых вещах?
V>>Ты собирал статистику, проводил собеседования в разные годы?
S>Бремя доказательства лежит на утверждающем.
Я собеседовал десятки, если не больше сотни в разные годы.
И тенденция слишком однозначная, чтобы это было простым совпадением на многих десятках людей.
S>Это оппонент делает утверждение о снижении среднего уровня программистов. Так что давайте адресуем вопрос про статистику и собеседования к нему.
Так это хорошо видно по молодняку, если отслеживать появляющийся в конторах молодняк в течении длительного времени.
И дело не в уровне программистов, дело кое в чём катастрофическом другом — профессия воспринимается всё более обыденно, всё меньше горят глаза, всё менее ЛЮБОПЫТНО.
http://www.rsdn.org/forum/philosophy/2130680.1
Наше поколение — это поколение исследователей, без преувеличения.
Чем дальше, тем такие товарищи встречаются всё реже.
Да, встречаются, но это теперь, скорее, исключение.
Раньше было редким исключением наоборот.
Мы ж бессеребреники были, ЗП были вовсе не космические, шли осознанно, испытывая тягу к предмету.
Теперь часто идут потому что это способ неплохо устроиться в этой жизни.
Ей-богу не знаю как на Западе (они мне в среднем намного слабее казались уже во второй половине 90-х), но у нас финансовый вопрос влияет на мотивацию, бо 300+ тыс в месяц для 3-5- лет стажа на дороге не валяются, т.е. отсутствует чистота эксперимента. ))
S>А так — да, конечно же я проводил собеседования в разные годы.
S>Ну, и кроме собеседований я преподаю в ВУЗе, поэтому могу оценивать распределение уровней квалификации сегодняшних бакалавров и магистров. Никаких признаков проблемы, обозначенной ТС, не наблюдается ни там, ни там.
А с чем ты сравниваешь?
И в насколько разные это были годы?
Прблема стала себя проявлять в полный рост примерно с середины нулевых, когда ЗП программеров у нас доросли до неадекватных величин.
До этого неуклонный рост ЗП был примерно с 97-го года, по мере покрытия интернетом экс-СССР.
Проблема примерно в следующем — увлекающийся программист осваивал материала по специальности примерно раз в 10 больше, чем давала программа ВУЗ-а.
Сейчас доля таких студентовв разы ниже, дай бог 1-2 на группу.
И у тебя разве есть достаточная выборка по однокурсникам хотя бы до начала нулевых, чтобы сравнивать с тем, как оно есть сейчас?
А меня есть по тем временам и по нынешним, бо несколько студентов вытягивал из болота за волосы как раз по специальностям IT (детей друзей и родственников, своих подтянул лишь однажды, и то задание было несколько непрофильным — по цифровой обработке сигналов, им давали теорию на слабом уровне, в сравнении с тем, как давали нам).
Я в курсе среднего нынешнего уровня студентов в группах в различных ВУЗ-ах Украины, России, и даже двух европейских.
Буквально полтора года назад помог с курсовой работой одному человеку из европейского ВУЗ-а, потом тщательно спросил про уровень работ остальных сокурсников.
В общем, справились на должном уровне всего трое, включая моего подопечного (который самостоятельно не справился), а там была сущая херня, примерно которую мы делали на 3-м курсе.
Только условия для выполнения этой херни на порядки более удобные — из Arduino IDE, доступен ЯВУ, схема выч. модуля дана, её проектировать не надо, перед тем как для модуля ПО, и вообще "всё работает само", тепличные условия, нам когда-то это и не снилось. ))
И всё-равно 20 чел из 23-х на должном уровне ниасилили.
У нас осиливал десяток запросто и еще десяток с пары подсказок.
Не осиливали самостоятельно большинство девочек и буквально один случайный мальчик в группе.
Блин, у нас несколько девах в группе САМОСТОЯТЕЛЬНО справились с менеджерами памяти, с пакетными шедуллерами IO и прочими такими задачами на 3-м курсе.
По сравнению с этим тот западный курсовик за 4-й курс — тьфу полнейшее.
Да еще в тепличных условиях тулсетов/окружения.
В группе сыновей тоже десятка внемяемых не набралось, хотя там один из 3-х топовых ВУЗ-ов РФ.
V>>Например?
S>Из самого известного — "ошибка на миллиард долларов" Тони Хоара. (К квалификации Тони вопросы есть?)
Вот тут звиздёшь:
И вообще, основные динамические структуры данных на тот момент давно были разработаны, не только связанный список.
Без nil никуда.
И альтернатив в процедурном программировании нет до сих пор, даже в Kotlin.
Альтернатива тут возможна только через IoС, т.е. в функциональных языках, когда некоему акцессору (итератору, скажем), подаётся колбэк.
Или когда некоему optional<T> подаётся пара колбэков — для наличия значения и для его отсутствия.
(примерно как работает диспетчеризация ф-ий в Хаскеле над размеченными union)
Других техник борьбы с nil, кроме диспетчеризации на манер IoC, в природе не существует, даже в Kotlin.
И да, в 60-е годы эта техника была уже известна и показывала себя откровенно хреново, как и сегодня, собсно.
А фраза целиком лишь характеризует уже старого и недостаточно умного человека:
С возрастом строить сложные конструкты в голове всё сложнее, т.е. ему сложнее удержать в памяти кучу одновременных противоречивых требований прямых и порождаемых ими зависимых.
Сохрани он эту способность до сих пор — не писал бы откровенные глупости.
В молодости был умнее, мог оперировать большей размерностью условий, в которых принимал решения.
Далее.
В точности проблема нулевых ссылок повторяется в массивах, к которым обращаются по индексу.
И чего ж старик не упомянул эту проблему, хотя проблема в точности идентичная?
Это ровно один и тот же класс ошибок, вызванных одной и той же причиной — невозможностью в compile-time выразить ВСЕ требуемые ограничения из runtime.
(в языках, которые претендуют на хоть какую-то эффективность)
И до изобретения исключений, без техники IoC, т.е. без функциональных ср-в в языке, ошибок такого рода в процедурных языках избежать было нельзя, можно было лишь сгенерировать проверочный код компилятором (или использовать какой-нить другой трюк, например как обращение к NULL как к невалидной области памяти, как оно специально сейчас оргаизуется в мейнстримовых архитектурах с защищённой памятью) и аварийно завершить программу, если проверка на индекс или nil была неудачной.
Далее.
Критикуя — предлагай!
Даже если критикуешь себя.
Наверно, Хоар еще не совсем выжил из ума, раз не озвучивает альтернативу, потому что альтернатива была проста:
— их доработка Алгола вышла бы УГ, была бы отдвинута конкурирующими более вменяемыми языками, а Хоар заслужил бы себе реноме дурачка, который обращает в г-но всё, что попадает к нему в руки.
Или, если бы весь мир сошёл с ума одновременно с ним, то эта ошибка стоила бы индустрии не смешные миллиарды долларов, а ВСЕМУ МИРУ сотни триллионов, по причине задержки примерно на 30 лет развития IT из-за неадекватного железу ПО.
Последствия "правильного" решения, если бы оно было принято обязательно в любых ЯВУ на нашем шарике были бы таковы, что сегодня население Земли никак не могло бы вырасти до 8 млрд, потому что этот рост вызван лишь ростом среднего благосостояния людей и ничем больше.
Ты же на голубом глазу рассуждаешь о том, что ради "идейной чистоты" со всем этим можно было бы подождать примерно 30 лет, до эпохи, когда начался резкий рост производительности компьютеров.
S>Из чуть менее известного — thread.stop()/suspend()/resume() в Java 1.0. Гослинг вроде тоже отнюдь не новичок, но тем не менее принял заведомо неудачное решение.
ЧТД, еще более слабый пример.
Да и при чём тут Java, это надо совсем не разбираться в вопросе. ))
Это АПИ потоков современных ОС, Java лишь даёт доступ к этому АПИ, как и ко многому другому АПИ.
Не хочешь, пройтись по сокетам, обычным и NIO из Java?
С высоты сегодняшнего понимания проблематики — уродство и то, и это.
Но это уродство — тоже лишь языковая обертка над обычными и асинхронными сокетами в ОС.
А откуда сокеты таковы в ОС?
Из-за уродства сетевой модели, даже OSI 7, рядом с которым семейство IP выглядит имбициллом.
А откуда это уродство вообще берется? — из-за необходимости разделять на независимые уровни различные задачи.
Из-за необходимости пользоваться сетевым транспортом не только высокоуровневым программам, но и низкоуровневыми.
Даже размером со спичесный коробок, как сказали бы в 90-х, или размером со спичечную головку сегодня.
К уродству приводит выбор из сомна противоречивых требований, из необходимости учесть кучу больших и малых факторов, из необходимости обеспечивать затем обратную совместимость в течении многих десятков лет жизни технологии, дабы технологии хотя бы успевали себя окупать.
В таком выборе обязательно что-нибудь приносится в жертву.
Например, в случае OSI в жертву было принесено доверие иерархических уровней сетей друг другу, т.е. в целом там выходит плохая защита от злоумышленничества.
Этот казус более-менее решает семейство IP, но уже в жертву был принесён здравый смысл — в одних случаях имеем многократное неоправданное дублирование служебных данных пакетов, в других случаях имеем невозможность дополнить пакеты нужной служебной информацией.
Собсно, принципы разметки пакетов IP придумыали имбициллы. Это не ругательство, это факт. Видна рука, скажем прямо, полупрофессионалов.
Скорее всего, этим занимались не системотехники, а смежники или вообще спецы в других дисциплинах, типа тебя, которые нахватались IT сугубо из любопытства.
Отсюда детские ошибки.
А вот "ошибка" с nil нифига не детская и не ошибка вовсе.
Чел прямо говорит, что принял это решение осознанно.
Просто из-за возраста не в состоянии восстановить полный ход тех своих рассуждений.
Жаль, конечно, но нас всех это ждёт.
Уважаю Хоара за что он делал тогда, и не собираюсь принимать во внимание то, что он говорит сейчас.
В деле разработки языков вклад Хоара скромен и мне на эту часть его деятельности несколько пофик.
Хоар внёс заметный вклад в анализ и выработку решений, лежащих в основе современных многозадачных ОС.
И не только в плане механизмов синхронизации, но даже в современных менеджерах памяти.
И да, весь этот код в той области задач писан через nil и обращения к массивам через индексы. ))
Добро пожаловать в реальность, Нео.
S>Ещё в ту же коробку — Java.util.Date.
S>Это практически хрестоматийный пример того, как можно сделать неправильно буквально всё. Начиная с того, что тип с value-семантикой реализован как mutable
Синклер, ты всё-таки определись, ты демагог или ты просто неисправимый нуб?
Когда разрабатывались эти классы (в среде, где всё выделяется из кучи), вменяемого escape-анализа не существовало.
Поэтому решение было единственно верным.
Да и сейчас вменяемого escape-анализа не существует и все серьёзные работы на эту тему сходятся в итоге на том, что в рамках динамического JIT это принципиально невозможно.
То бишь, протестовать тут можно лишь по классике — как двоечники протестуют против невыученных уроков, и тогда ты неисправимый нуб, обреченынй вызывать насмешки до старости.
Или ты всё это понимаешь — и тогда ты нечестивый демагог, наше вам фи.
V>>Я вижу, что принятые ранее решения исходили (а) из ограничений аппаратуры и (б) были расчитаны в среднем на более способного программиста.
S> Приведённые мной примеры — это грабли, которые никакого отношения к ограничениям аппаратуры не имеют
Всё-таки неиправимый нуб?
S>и от программиста ожидают не каких-то особенных способностей.
Судя даже по этому обсуждению — без способностей в нашей области некоторым непросто.
S>Ну, вот к примеру — с т.з. той же java.util.Date, "способный" программист отличается от "неспособного" тем, что в геттерах свойств выполняет defensive copy.
Ты действительно не понимаешь, почему так было сделано?
Так ты нуб, или демагог.
Ты уже показываешь что плаваешь совсем в азах взаимодействия управляемого и нейтивного кода.
Поэтому я так до сих пор и не могу определиться.
Но неужели столь вопиющий нуб так ловко играет хотя бы продвинутого юзера? ))
Хотя, по переписке оно проще, конечно, водить окружающих за нос.
В живом разговоре, когда к гуглу за ответом па бырому не сбегаешь, лучше видно, ху из ху.
S>При этом никакого существенного улучшения качества программы не происходит — помимо замусоривания хипа и увеличения нагрузки на GC (что там у нас по ограничениям аппаратуры), клиентский код по-прежнему работает не так, как ожидают его авторы.
Код работает так, как написано в документации, а не как ожидают те, кто сам себе чего-то надумал.
V>>Концептуально нового? ))
V>>Например?
S>Ну, например, я не ожидал, что в 21 веке смогут придумать какой-то новый вид скалярных индексов для СУБД.
Во-первых, у тебя хромает русскоязычная терминология, т.е. ты не знаешь, о чём ты говоришь.
Во-вторых, никаких видом индекса не придумали ни одного в 21-м веке.
S>Казалось бы — после B-trees, hash, и bitmap индексов в этой области уже ничего нового не придумать.
Ты забыл еще time series, и целое семейство вероятностных, как надстройки над иерархическими индексами (не обязательно B-trees, бо сами B-trees лишь вырожденный случай из своего класса).
S>Ан нет — апрель 2020, PGM-index.
Не вижу ничего нового.
Вижу попытка сочетаний уже имеющихся подходов.
Итого, Синклер лжец. ))
Или нуб, опять самостоятельно не разобрался, как маленький.
S>плюс значительная компактность
Но я не вижу изобретённого способа компактификации.
Где формула изобретения?
Или мне тебе на пальцах показывать, как можно хранить иерархические данные не только в бинарных узлах, где оверхед по занимаемой памяти чуть ли не втрое? ))
Мы же именно с тобой обсуждали рализации n-tree.
Собсно, любые n-tree выразимы через b-tree, но решают недостатки b-tree по оверхеду служебной памяти, по локальности данных и т.д.
S>(а, значит, меньше io-нагрузка, более высокий cache hit ratio, и все вытекающие).
Зевал так, что чуть рот не порвался...
Синклер, ты обещал новые концепции...
Значительные изобретения...
А кормишь булшитом, уровня инженерной разработки.
Блин, различные шедуллеры в современных ОС и в разы сложнее в плане использованного понимания происходящего, статейка от новичков в IT (зародышей-аспирантов) по ссылке.
Ты бы не мог впредь не засорять эфир, где тусуются опытные инженерами, всякой наивной мутью от учащихся?
Многие оформляют кандидатские к 27-28 годам, будучи еще при этом совсем еще зелеными в области IT, поражающими воображение своей наивностью и отсутствием "набитости руки" в этой области человеческой деятельности, бо копают один-два направления в аспирантуре, причём, весьма изолированно от других областей.
В этом и заключается отличие инженерной от научной работы в IT — научники изучают изолированные аспекты, а инженеры изобретают способы совмещения аспектов.
Характер и тех и других работ исследовательский, но объем одновременно оперируемой информации у инженера обычно в разы больше.
Нескольким таким горе-кандидатам я когда-то помогал, да и не только я.
Опытные инженеры всегда помогают зеленым аспирантам, это нормально и правильно.
Ненормально, когда опытных инженеров в аспирантов тыкают. ))
Брысь по яслям, как грится.
S>Был ли возможен такой индекс в 1963? Да, конечно. Это не нейронки, обучение которых стало практически пригодным только после массового распространения многоядерных видеокарточек.
S>Математика в основе лежит общеизвестная, сложность алгоритмов — не выше, чем у B-tree. Просто — не додумались.
Просто ты живешь в параллельной Вселенной.
Первые примитивнейшые СУБД появились в начале 80-х.
А первые вменяемые — к 89-му, а на самом деле в 92-м, после исправления детских ошибок.
И там до перебора комбинаторики всевозможных видов индексов еще столько вопросов решить надо было, особенно в плане ХРАНЕНИЯ данных и сопротивляющихся их целостности дисковых операционных систем — у-у-у...
Т.е. этот вопрос был даже не десятый.
Плюс сама эта прблематика не стояла, бо она начинает вовсю стоять на больших объемах данных, а их тогда физически несуществовало.
И вот ты заламываешь руки, что в 60-х годах на несуществующих тогда СУБД (сама теория в 70-х только-только начала прорабатывать) не решали задачи эфффективного индексирования чудовищных размеров данных, пригодных к обработке, хранящихся на хранителях, которых требуемых размеров на тот момент тоже физически не существовало.
В этом сюрре прекрасно всё. ))
Дисциллированное нубство какое-то...
V>>Я, наоборот, концептуально нового уже давно не вижу.
S>
==========================
Тебе не надоело, случаем, делать громкие заявления и быть выпоротым в итоге?
Зачем так орать-то громкими заявлениями?
Разумеется, новое дыхание в конце 90-х и начале 2000-х получили теории языков.
Причина была очевидной — производительность компьютеров росла экспоненциально, виделось, что IT сможет позволить себе, наконец, "излишества".
Но что характерно — в этих иследованиях были подняты нафталиновые вопросы.
Без изобретения нового.
Я когда-то уже высказывался на эти темы ~12 лет назад в ответ молодому и горячему в те года Вольфхануду:
http://www.rsdn.org/forum/philosophy/4247637.1
V>>А как ты увидишь, если речь об усреднённых вещах?
V>>Ты собирал статистику, проводил собеседования в разные годы?
S>Бремя доказательства лежит на утверждающем.
Я собеседовал десятки, если не больше сотни в разные годы.
И тенденция слишком однозначная, чтобы это было простым совпадением на многих десятках людей.
S>Это оппонент делает утверждение о снижении среднего уровня программистов. Так что давайте адресуем вопрос про статистику и собеседования к нему.
Так это хорошо видно по молодняку, если отслеживать появляющийся в конторах молодняк в течении длительного времени.
И дело не в уровне программистов, дело кое в чём катастрофическом другом — профессия воспринимается всё более обыденно, всё меньше горят глаза, всё менее ЛЮБОПЫТНО.
http://www.rsdn.org/forum/philosophy/2130680.1
Наше поколение — это поколение исследователей, без преувеличения.
Чем дальше, тем такие товарищи встречаются всё реже.
Да, встречаются, но это теперь, скорее, исключение.
Раньше было редким исключением наоборот.
Мы ж бессеребреники были, ЗП были вовсе не космические, шли осознанно, испытывая тягу к предмету.
Теперь часто идут потому что это способ неплохо устроиться в этой жизни.
Ей-богу не знаю как на Западе (они мне в среднем намного слабее казались уже во второй половине 90-х), но у нас финансовый вопрос влияет на мотивацию, бо 300+ тыс в месяц для 3-5- лет стажа на дороге не валяются, т.е. отсутствует чистота эксперимента. ))
S>А так — да, конечно же я проводил собеседования в разные годы.
S>Ну, и кроме собеседований я преподаю в ВУЗе, поэтому могу оценивать распределение уровней квалификации сегодняшних бакалавров и магистров. Никаких признаков проблемы, обозначенной ТС, не наблюдается ни там, ни там.
А с чем ты сравниваешь?
И в насколько разные это были годы?
Прблема стала себя проявлять в полный рост примерно с середины нулевых, когда ЗП программеров у нас доросли до неадекватных величин.
До этого неуклонный рост ЗП был примерно с 97-го года, по мере покрытия интернетом экс-СССР.
Проблема примерно в следующем — увлекающийся программист осваивал материала по специальности примерно раз в 10 больше, чем давала программа ВУЗ-а.
Сейчас доля таких студентовв разы ниже, дай бог 1-2 на группу.
И у тебя разве есть достаточная выборка по однокурсникам хотя бы до начала нулевых, чтобы сравнивать с тем, как оно есть сейчас?
А меня есть по тем временам и по нынешним, бо несколько студентов вытягивал из болота за волосы как раз по специальностям IT (детей друзей и родственников, своих подтянул лишь однажды, и то задание было несколько непрофильным — по цифровой обработке сигналов, им давали теорию на слабом уровне, в сравнении с тем, как давали нам).
Я в курсе среднего нынешнего уровня студентов в группах в различных ВУЗ-ах Украины, России, и даже двух европейских.
Буквально полтора года назад помог с курсовой работой одному человеку из европейского ВУЗ-а, потом тщательно спросил про уровень работ остальных сокурсников.
В общем, справились на должном уровне всего трое, включая моего подопечного (который самостоятельно не справился), а там была сущая херня, примерно которую мы делали на 3-м курсе.
Только условия для выполнения этой херни на порядки более удобные — из Arduino IDE, доступен ЯВУ, схема выч. модуля дана, её проектировать не надо, перед тем как для модуля ПО, и вообще "всё работает само", тепличные условия, нам когда-то это и не снилось. ))
И всё-равно 20 чел из 23-х на должном уровне ниасилили.
У нас осиливал десяток запросто и еще десяток с пары подсказок.
Не осиливали самостоятельно большинство девочек и буквально один случайный мальчик в группе.
Блин, у нас несколько девах в группе САМОСТОЯТЕЛЬНО справились с менеджерами памяти, с пакетными шедуллерами IO и прочими такими задачами на 3-м курсе.
По сравнению с этим тот западный курсовик за 4-й курс — тьфу полнейшее.
Да еще в тепличных условиях тулсетов/окружения.
В группе сыновей тоже десятка внемяемых не набралось, хотя там один из 3-х топовых ВУЗ-ов РФ.
V>>Например?
S>Из самого известного — "ошибка на миллиард долларов" Тони Хоара. (К квалификации Тони вопросы есть?)
Вот тут звиздёшь:
Чел попытался присвоить себе "ошибку", которая до него была уже "сделана" эдак тысячекратно, например, тот же nil в Lisp.Я называю нулевую ссылку своей ошибкой на миллиард долларов. Она была изобретена в 1965 году, когда я разработал первую всеобъемлющую систему ссылочных типов на объектно-ориентированном языке (АЛГОЛ W).
И вообще, основные динамические структуры данных на тот момент давно были разработаны, не только связанный список.
Без nil никуда.
И альтернатив в процедурном программировании нет до сих пор, даже в Kotlin.
Альтернатива тут возможна только через IoС, т.е. в функциональных языках, когда некоему акцессору (итератору, скажем), подаётся колбэк.
Или когда некоему optional<T> подаётся пара колбэков — для наличия значения и для его отсутствия.
(примерно как работает диспетчеризация ф-ий в Хаскеле над размеченными union)
Других техник борьбы с nil, кроме диспетчеризации на манер IoC, в природе не существует, даже в Kotlin.
И да, в 60-е годы эта техника была уже известна и показывала себя откровенно хреново, как и сегодня, собсно.
А фраза целиком лишь характеризует уже старого и недостаточно умного человека:
Ошибка уродливее, чем обратная косая черта в Windows, более странная, чем ===, более распространенная, чем PHP, более неудачная, чем CORS, и более тревожная, чем дженерики Java. XMLHttpRequest, более сложный для понимания, чем препроцессор C, более подверженный фрагментации, чем MongoDB, и более прискорбный, чем UTF-16.
С возрастом строить сложные конструкты в голове всё сложнее, т.е. ему сложнее удержать в памяти кучу одновременных противоречивых требований прямых и порождаемых ими зависимых.
Сохрани он эту способность до сих пор — не писал бы откровенные глупости.
В молодости был умнее, мог оперировать большей размерностью условий, в которых принимал решения.
Далее.
В точности проблема нулевых ссылок повторяется в массивах, к которым обращаются по индексу.
И чего ж старик не упомянул эту проблему, хотя проблема в точности идентичная?
Это ровно один и тот же класс ошибок, вызванных одной и той же причиной — невозможностью в compile-time выразить ВСЕ требуемые ограничения из runtime.
(в языках, которые претендуют на хоть какую-то эффективность)
И до изобретения исключений, без техники IoC, т.е. без функциональных ср-в в языке, ошибок такого рода в процедурных языках избежать было нельзя, можно было лишь сгенерировать проверочный код компилятором (или использовать какой-нить другой трюк, например как обращение к NULL как к невалидной области памяти, как оно специально сейчас оргаизуется в мейнстримовых архитектурах с защищённой памятью) и аварийно завершить программу, если проверка на индекс или nil была неудачной.
Далее.
Критикуя — предлагай!
Даже если критикуешь себя.
Наверно, Хоар еще не совсем выжил из ума, раз не озвучивает альтернативу, потому что альтернатива была проста:
— их доработка Алгола вышла бы УГ, была бы отдвинута конкурирующими более вменяемыми языками, а Хоар заслужил бы себе реноме дурачка, который обращает в г-но всё, что попадает к нему в руки.
Или, если бы весь мир сошёл с ума одновременно с ним, то эта ошибка стоила бы индустрии не смешные миллиарды долларов, а ВСЕМУ МИРУ сотни триллионов, по причине задержки примерно на 30 лет развития IT из-за неадекватного железу ПО.
Последствия "правильного" решения, если бы оно было принято обязательно в любых ЯВУ на нашем шарике были бы таковы, что сегодня население Земли никак не могло бы вырасти до 8 млрд, потому что этот рост вызван лишь ростом среднего благосостояния людей и ничем больше.
Ты же на голубом глазу рассуждаешь о том, что ради "идейной чистоты" со всем этим можно было бы подождать примерно 30 лет, до эпохи, когда начался резкий рост производительности компьютеров.
S>Из чуть менее известного — thread.stop()/suspend()/resume() в Java 1.0. Гослинг вроде тоже отнюдь не новичок, но тем не менее принял заведомо неудачное решение.
ЧТД, еще более слабый пример.
Да и при чём тут Java, это надо совсем не разбираться в вопросе. ))
Это АПИ потоков современных ОС, Java лишь даёт доступ к этому АПИ, как и ко многому другому АПИ.
Не хочешь, пройтись по сокетам, обычным и NIO из Java?
С высоты сегодняшнего понимания проблематики — уродство и то, и это.
Но это уродство — тоже лишь языковая обертка над обычными и асинхронными сокетами в ОС.
А откуда сокеты таковы в ОС?
Из-за уродства сетевой модели, даже OSI 7, рядом с которым семейство IP выглядит имбициллом.
А откуда это уродство вообще берется? — из-за необходимости разделять на независимые уровни различные задачи.
Из-за необходимости пользоваться сетевым транспортом не только высокоуровневым программам, но и низкоуровневыми.
Даже размером со спичесный коробок, как сказали бы в 90-х, или размером со спичечную головку сегодня.
К уродству приводит выбор из сомна противоречивых требований, из необходимости учесть кучу больших и малых факторов, из необходимости обеспечивать затем обратную совместимость в течении многих десятков лет жизни технологии, дабы технологии хотя бы успевали себя окупать.
В таком выборе обязательно что-нибудь приносится в жертву.
Например, в случае OSI в жертву было принесено доверие иерархических уровней сетей друг другу, т.е. в целом там выходит плохая защита от злоумышленничества.
Этот казус более-менее решает семейство IP, но уже в жертву был принесён здравый смысл — в одних случаях имеем многократное неоправданное дублирование служебных данных пакетов, в других случаях имеем невозможность дополнить пакеты нужной служебной информацией.
Собсно, принципы разметки пакетов IP придумыали имбициллы. Это не ругательство, это факт. Видна рука, скажем прямо, полупрофессионалов.
Скорее всего, этим занимались не системотехники, а смежники или вообще спецы в других дисциплинах, типа тебя, которые нахватались IT сугубо из любопытства.
Отсюда детские ошибки.
А вот "ошибка" с nil нифига не детская и не ошибка вовсе.
Чел прямо говорит, что принял это решение осознанно.
Просто из-за возраста не в состоянии восстановить полный ход тех своих рассуждений.
Жаль, конечно, но нас всех это ждёт.
Уважаю Хоара за что он делал тогда, и не собираюсь принимать во внимание то, что он говорит сейчас.
В деле разработки языков вклад Хоара скромен и мне на эту часть его деятельности несколько пофик.
Хоар внёс заметный вклад в анализ и выработку решений, лежащих в основе современных многозадачных ОС.
И не только в плане механизмов синхронизации, но даже в современных менеджерах памяти.
И да, весь этот код в той области задач писан через nil и обращения к массивам через индексы. ))
Добро пожаловать в реальность, Нео.
S>Ещё в ту же коробку — Java.util.Date.
S>Это практически хрестоматийный пример того, как можно сделать неправильно буквально всё. Начиная с того, что тип с value-семантикой реализован как mutable
Синклер, ты всё-таки определись, ты демагог или ты просто неисправимый нуб?
Когда разрабатывались эти классы (в среде, где всё выделяется из кучи), вменяемого escape-анализа не существовало.
Поэтому решение было единственно верным.
Да и сейчас вменяемого escape-анализа не существует и все серьёзные работы на эту тему сходятся в итоге на том, что в рамках динамического JIT это принципиально невозможно.
То бишь, протестовать тут можно лишь по классике — как двоечники протестуют против невыученных уроков, и тогда ты неисправимый нуб, обреченынй вызывать насмешки до старости.
Или ты всё это понимаешь — и тогда ты нечестивый демагог, наше вам фи.
V>>Я вижу, что принятые ранее решения исходили (а) из ограничений аппаратуры и (б) были расчитаны в среднем на более способного программиста.
S>
Приведённые мной примеры — это грабли, которые никакого отношения к ограничениям аппаратуры не имеютВсё-таки неиправимый нуб?
S>и от программиста ожидают не каких-то особенных способностей.
Судя даже по этому обсуждению — без способностей в нашей области некоторым непросто.
S>Ну, вот к примеру — с т.з. той же java.util.Date, "способный" программист отличается от "неспособного" тем, что в геттерах свойств выполняет defensive copy.
Ты действительно не понимаешь, почему так было сделано?
Так ты нуб, или демагог.
Ты уже показываешь что плаваешь совсем в азах взаимодействия управляемого и нейтивного кода.
Поэтому я так до сих пор и не могу определиться.
Но неужели столь вопиющий нуб так ловко играет хотя бы продвинутого юзера? ))
Хотя, по переписке оно проще, конечно, водить окружающих за нос.
В живом разговоре, когда к гуглу за ответом па бырому не сбегаешь, лучше видно, ху из ху.
S>При этом никакого существенного улучшения качества программы не происходит — помимо замусоривания хипа и увеличения нагрузки на GC (что там у нас по ограничениям аппаратуры), клиентский код по-прежнему работает не так, как ожидают его авторы.
Код работает так, как написано в документации, а не как ожидают те, кто сам себе чего-то надумал.
V>>Концептуально нового? ))
V>>Например?
S>Ну, например, я не ожидал, что в 21 веке смогут придумать какой-то новый вид скалярных индексов для СУБД.
Во-первых, у тебя хромает русскоязычная терминология, т.е. ты не знаешь, о чём ты говоришь.
Во-вторых, никаких видом индекса не придумали ни одного в 21-м веке.
S>Казалось бы — после B-trees, hash, и bitmap индексов в этой области уже ничего нового не придумать.
Ты забыл еще time series, и целое семейство вероятностных, как надстройки над иерархическими индексами (не обязательно B-trees, бо сами B-trees лишь вырожденный случай из своего класса).
S>Ан нет — апрель 2020, PGM-index.
Не вижу ничего нового.
Вижу попытка сочетаний уже имеющихся подходов.
Итого, Синклер лжец. ))
Или нуб, опять самостоятельно не разобрался, как маленький.
S>плюс значительная компактность
Но я не вижу изобретённого способа компактификации.
Где формула изобретения?
Или мне тебе на пальцах показывать, как можно хранить иерархические данные не только в бинарных узлах, где оверхед по занимаемой памяти чуть ли не втрое? ))
Мы же именно с тобой обсуждали рализации n-tree.
Собсно, любые n-tree выразимы через b-tree, но решают недостатки b-tree по оверхеду служебной памяти, по локальности данных и т.д.
S>(а, значит, меньше io-нагрузка, более высокий cache hit ratio, и все вытекающие).
Зевал так, что чуть рот не порвался...
Синклер, ты обещал новые концепции...
Значительные изобретения...
А кормишь булшитом, уровня инженерной разработки.
Блин, различные шедуллеры в современных ОС и в разы сложнее в плане использованного понимания происходящего, статейка от новичков в IT (зародышей-аспирантов) по ссылке.
Ты бы не мог впредь не засорять эфир, где тусуются опытные инженерами, всякой наивной мутью от учащихся?
Многие оформляют кандидатские к 27-28 годам, будучи еще при этом совсем еще зелеными в области IT, поражающими воображение своей наивностью и отсутствием "набитости руки" в этой области человеческой деятельности, бо копают один-два направления в аспирантуре, причём, весьма изолированно от других областей.
В этом и заключается отличие инженерной от научной работы в IT — научники изучают изолированные аспекты, а инженеры изобретают способы совмещения аспектов.
Характер и тех и других работ исследовательский, но объем одновременно оперируемой информации у инженера обычно в разы больше.
Нескольким таким горе-кандидатам я когда-то помогал, да и не только я.
Опытные инженеры всегда помогают зеленым аспирантам, это нормально и правильно.
Ненормально, когда опытных инженеров в аспирантов тыкают. ))
Брысь по яслям, как грится.
S>Был ли возможен такой индекс в 1963? Да, конечно. Это не нейронки, обучение которых стало практически пригодным только после массового распространения многоядерных видеокарточек.
S>Математика в основе лежит общеизвестная, сложность алгоритмов — не выше, чем у B-tree. Просто — не додумались.
Просто ты живешь в параллельной Вселенной.
Первые примитивнейшые СУБД появились в начале 80-х.
А первые вменяемые — к 89-му, а на самом деле в 92-м, после исправления детских ошибок.
И там до перебора комбинаторики всевозможных видов индексов еще столько вопросов решить надо было, особенно в плане ХРАНЕНИЯ данных и сопротивляющихся их целостности дисковых операционных систем — у-у-у...
Т.е. этот вопрос был даже не десятый.
Плюс сама эта прблематика не стояла, бо она начинает вовсю стоять на больших объемах данных, а их тогда физически несуществовало.
И вот ты заламываешь руки, что в 60-х годах на несуществующих тогда СУБД (сама теория в 70-х только-только начала прорабатывать) не решали задачи эфффективного индексирования чудовищных размеров данных, пригодных к обработке, хранящихся на хранителях, которых требуемых размеров на тот момент тоже физически не существовало.
В этом сюрре прекрасно всё. ))
Дисциллированное нубство какое-то...
V>>Я, наоборот, концептуально нового уже давно не вижу.
S>
==========================
Тебе не надоело, случаем, делать громкие заявления и быть выпоротым в итоге?
Зачем так орать-то громкими заявлениями?
Разумеется, новое дыхание в конце 90-х и начале 2000-х получили теории языков.
Причина была очевидной — производительность компьютеров росла экспоненциально, виделось, что IT сможет позволить себе, наконец, "излишества".
Но что характерно — в этих иследованиях были подняты нафталиновые вопросы.
Без изобретения нового.
Я когда-то уже высказывался на эти темы ~12 лет назад в ответ молодому и горячему в те года Вольфхануду:
http://www.rsdn.org/forum/philosophy/4247637.1