Здравствуйте, velkin, Вы писали:
V>В этой статье я попытаюсь ответить на вопрос, почему программисты прошлого были умнее, а качество образования с каждым годом только падало.
Для начала было бы неплохо доказать, что это факт имеет место быть.
Здравствуйте, 0x7be, Вы писали:
V>>В этой статье я попытаюсь ответить на вопрос, почему программисты прошлого были умнее, а качество образования с каждым годом только падало. 0>Для начала было бы неплохо доказать, что это факт имеет место быть.
Кому надо тот пусть и доказывает, мне лично пока хватает представленной информации. Но я не против, если ты докажешь, а потом бесплатно опубликуешь доказательство. Так-то бы пора уже переходить к следующей части статьи, от того кто виноват, к тому что делать.
Здравствуйте, velkin, Вы писали:
V>Кому надо тот пусть и доказывает, мне лично пока хватает представленной информации. Но я не против, если ты докажешь, а потом бесплатно опубликуешь доказательство. Так-то бы пора уже переходить к следующей части статьи, от того кто виноват, к тому что делать.
Ничего не надо делать. Надо продолжать в том же духе и дальше.
Здравствуйте, velkin, Вы писали:
V>В этой статье я попытаюсь ответить на вопрос, почему программисты прошлого были умнее, а качество образования с каждым годом только падало.
Здравствуйте, velkin, Вы писали:
V>В этой статье я попытаюсь ответить на вопрос, почему программисты прошлого были умнее, а качество образования с каждым годом только падало.
А такой вопрос вообще стоит? Его кто-то задал?
V>Как известно более старые книги по математике времён СССР лучше более поздних того же СССР и России. В некотором роде книги по математике деградировали так же, как и книги по программированию. Люди, до 60-ых годов получали гораздо более простые и насыщенные источники информации, просто потому, что у них не было выбора взять худшие варианты из будущего. Похожее случилось и с программированием.
Мммм, чего? Какие книги деградировали?
Например, Начала Евклида актуальны до сих пор. Чему там деградировать?
V>Поколение математиков были лишены всего этого безобразия, в том числе и структурной парадигмы заложенной в языке. V>Поколение программистов аппаратчиков (1960-1980) V>Поколение программистов абстракционистов (1980-2000) V>Поколение программистов пользователей (2000-2020+)
Коллега, перед этими поколениями стояли совершенно разные глобальные задачи. И с развитием ИКТ менялись как задачи, так и подходы и средства их решения, это нормально.
V>Проблемы программистов V>Мусорная литература V>Мусорные алгоритмы Это точно проблемы программистов?
V>В принципе я обозначил проблему. И не только я, в интернете иногда об этом говорят. Что касается решения, то здесь как всегда нужно проводить опыты.
Коллега, в принципе я догадываюсь о чем ты пишешь, но из приведенного текста это совсем не очевидно. Кроме того, всегда существует эволюционный путь развития любой сложной системы, не стоит форсировать события, просто занимайся своим делом наилучшим образом.
Здравствуйте, Sinclair, Вы писали:
S>Я вот не вижу однозначного подтверждения ни тому, что "программисты прошлого были умнее", ни тому, что "качество образования с каждым годом только падало".
А как ты увидишь, если речь об усреднённых вещах?
Ты собирал статистику, проводил собеседования в разные годы?
S>Зато я вижу множество фундаментальных ошибок, сделанных программистами прошлого. Не багов в коде, а именно провальных концепций.
Например?
Я вижу, что принятые ранее решения исходили (а) из ограничений аппаратуры и (б) были расчитаны в среднем на более способного программиста.
S>Вижу, что до сих пор в самых вытоптанных областях появляются новые решения, которые были бы вполне доступны программистам прошлого, но почему-то ускользнули от их внимания.
Концептуально нового? ))
Например?
Я, наоборот, концептуально нового уже давно не вижу.
Здравствуйте, vdimas, Вы писали:
V>А как ты увидишь, если речь об усреднённых вещах? V>Ты собирал статистику, проводил собеседования в разные годы?
Бремя доказательства лежит на утверждающем. Это оппонент делает утверждение о снижении среднего уровня программистов. Так что давайте адресуем вопрос про статистику и собеседования к нему.
А так — да, конечно же я проводил собеседования в разные годы.
Ну, и кроме собеседований я преподаю в ВУЗе, поэтому могу оценивать распределение уровней квалификации сегодняшних бакалавров и магистров. Никаких признаков проблемы, обозначенной ТС, не наблюдается ни там, ни там.
V>Например?
Из самого известного — "ошибка на миллиард долларов" Тони Хоара. (К квалификации Тони вопросы есть?)
Из чуть менее известного — thread.stop()/suspend()/resume() в Java 1.0. Гослинг вроде тоже отнюдь не новичок, но тем не менее принял заведомо неудачное решение.
Ещё в ту же коробку — Java.util.Date.
Это практически хрестоматийный пример того, как можно сделать неправильно буквально всё. Начиная с того, что тип с value-семантикой реализован как mutable, и заканчивая тонкими проблемами взаимодействия с календарём. https://programminghints.com/2017/05/still-using-java-util-date-dont/
V>Я вижу, что принятые ранее решения исходили (а) из ограничений аппаратуры и (б) были расчитаны в среднем на более способного программиста. Приведённые мной примеры — это грабли, которые никакого отношения к ограничениям аппаратуры не имеют, и от программиста ожидают не каких-то особенных способностей.
Ну, вот к примеру — с т.з. той же java.util.Date, "способный" программист отличается от "неспособного" тем, что в геттерах свойств выполняет defensive copy.
При этом никакого существенного улучшения качества программы не происходит — помимо замусоривания хипа и увеличения нагрузки на GC (что там у нас по ограничениям аппаратуры), клиентский код по-прежнему работает не так, как ожидают его авторы.
V>Концептуально нового? )) V>Например?
Ну, например, я не ожидал, что в 21 веке смогут придумать какой-то новый вид скалярных индексов для СУБД. Казалось бы — после B-trees, hash, и bitmap индексов в этой области уже ничего нового не придумать.
Ан нет — апрель 2020, PGM-index.
Прекрасная штука — все преимущества B-tree (range queries, nearest search), плюс значительная компактность (а, значит, меньше io-нагрузка, более высокий cache hit ratio, и все вытекающие).
Был ли возможен такой индекс в 1963? Да, конечно. Это не нейронки, обучение которых стало практически пригодным только после массового распространения многоядерных видеокарточек.
Математика в основе лежит общеизвестная, сложность алгоритмов — не выше, чем у B-tree. Просто — не додумались.
V>Я, наоборот, концептуально нового уже давно не вижу.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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>Из самого известного — "ошибка на миллиард долларов" Тони Хоара. (К квалификации Тони вопросы есть?)
Вот тут звиздёшь:
Я называю нулевую ссылку своей ошибкой на миллиард долларов. Она была изобретена в 1965 году, когда я разработал первую всеобъемлющую систему ссылочных типов на объектно-ориентированном языке (АЛГОЛ W).
Чел попытался присвоить себе "ошибку", которая до него была уже "сделана" эдак тысячекратно, например, тот же nil в Lisp.
И вообще, основные динамические структуры данных на тот момент давно были разработаны, не только связанный список.
Без 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, но уже в жертву был принесён здравый смысл — в одних случаях имеем многократное неоправданное дублирование служебных данных пакетов, в других случаях имеем невозможность дополнить пакеты нужной служебной информацией. Такая возможность есть лишь на прикладном уровне протокола. На прикладном, Карл, т.е. на одном из возможных из 7-ми.
Собсно, принципы разметки пакетов 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>плюс значительная компактность
Но я не вижу изобретённого способа компактификации.
Где формула изобретения?
Или мне тебе на пальцах показывать, как можно хранить иерархические данные не только в бинарных узлах, где оверхед по занимаемой памяти чуть ли не втрое? ))
Мы же именно с тобой обсуждали реализации 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
С середины нулевых халява закончилась, т.к. закончился экспоненциальный рост производительности.
Вот тогда опять повернулись лицом к нейтиву (С++0x инициатива во второй половине нулевых), а все эти теории языков опять поклали под нафталин до лучших времён.
C# тоже повернулся лицом к нейтивной платформе собственного исполнения.
Потому что добро пожаловать в реальный мир.
Здравствуйте, 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
Ну, так и зачем самому себе противоречить?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Ан нет — апрель 2020, PGM-index. S>Прекрасная штука — все преимущества B-tree (range queries, nearest search), плюс значительная компактность (а, значит, меньше io-нагрузка, более высокий cache hit ratio, и все вытекающие). S>Был ли возможен такой индекс в 1963? Да, конечно.
Не могли. Через познание и опыт перешагнуть невозможно.
B-tree, насколько помню, придумали только в 1971 году.
После чего и пошло развитие БД.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
S>>Ан нет — апрель 2020, PGM-index. S>>Прекрасная штука — все преимущества B-tree (range queries, nearest search), плюс значительная компактность (а, значит, меньше io-нагрузка, более высокий cache hit ratio, и все вытекающие). S>>Был ли возможен такой индекс в 1963? Да, конечно. LVV>Не могли. Через познание и опыт перешагнуть невозможно. LVV>B-tree, насколько помню, придумали только в 1971 году. LVV>После чего и пошло развитие БД.
Развитие БД началось немножко раньше. Программисты прошлого, хоть и не были шибко умнее нонешних, но и не тупее нас. Поэтому задача по разработке систем и стандартов по обработке данных (независимо от конкретных прикладных программ) была поставлена примерно в конце 50х. Помните такой Комитет по Языку Систем Данных, он же CODASYL? Создан в 1959 году. Кобол с самого начала проектировался не как язык общего назначения в современном понимании, а как язык для обработки данных. К середине шестидесятых работу над языком и моделью данных разделили по подкомитетам. К 1969 ребятушки опубликовали первую публичную версию стандарта CODASYL Data Model.
Примерно в те же времена появились первые промышленные СУБД. Например, IDS вышла в 1963 году.
Авторство B-tree приписывают Байеру с МакКреем — черновик статьи был готов (и доступен) в 1970м, опубликован в 1972.
Но есть свидетельства того, что аналогичные решения применялись в СУБД ещё в шестидесятых, просто их авторы не затруднили себя публикацией статей и формальными математическими доказательствами асимптотики.
И всё-таки — между 1970 и 2020 прошло 50 лет. И проблема индексации данных была актуальна все эти годы, а не внезапно возникла в 21 вее.
В PGM нет никакой математики, которой не существовало в шестидесятых. Поэтому теоретически — могли придумать уже тогда.
А вот то, что через познание и опыт перешагнуть невозможно — это в чём-то верно.
Нужно было придумать решения задач; попробовать их на практике; столкнуться с новыми вызовами (не все из которых были очевидны на момент изобретения тогдашних решений), придумать новые решения, и так далее.
Поэтому современные программисты продолжают придумывать вполне себе новые и интересные вещи, опираясь как на дедовские наработки, так и на отцовский опыт. Нормально всё.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Развитие БД началось немножко раньше. Программисты прошлого, хоть и не были шибко умнее нонешних, но и не тупее нас. Поэтому задача по разработке систем и стандартов по обработке данных (независимо от конкретных прикладных программ) была поставлена примерно в конце 50х. Помните такой Комитет по Языку Систем Данных, он же CODASYL? Создан в 1959 году. Кобол с самого начала проектировался не как язык общего назначения в современном понимании, а как язык для обработки данных. К середине шестидесятых работу над языком и моделью данных разделили по подкомитетам. К 1969 ребятушки опубликовали первую публичную версию стандарта CODASYL Data Model.
У мееня даже была эта книжка в русском переводе.
Оттуда я почерпнул знание о 3 моделях данных того времени. S>Примерно в те же времена появились первые промышленные СУБД. Например, IDS вышла в 1963 году.
Ну, я с БД впервые столкнулся на СМ1420 — adabas. S>И всё-таки — между 1970 и 2020 прошло 50 лет. И проблема индексации данных была актуальна все эти годы, а не внезапно возникла в 21 вее. S>В PGM нет никакой математики, которой не существовало в шестидесятых. Поэтому теоретически — могли придумать уже тогда.
Для практики, наверное, не очень было нужно — не было таких объемов, как сейчас.
Вот особо и не парились.
Это как с нейронками — можностя не позволяли.
А когда стали позволять — резкий рывок S>Нормально всё.
Да, все идет свои чередом
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Многа букаф — ниасилил...
Не были они умнее — они просто не были программистами по образованию. Во всяком случае, в 50 и первой половине 60 — точно.
Если не ошибаюсь, Дейкстра был радиофизик по образованию.
А отдел системного программирования в ОИЯИ — они же физиками были.
А написали операционную систему и систему программирования на фортране для физиков.
Да даже в наше время (с 1975 года) — просто не было интернета.
Поэтому все писали сами.
Например, по одному договору делали такое:
1. Добавили в PL-1 лисп.
2. Придумали язык сверхвысокого уровня (по тем временам) типа Clojure
3. Написали его интерпретатор на PL-1лисп
4. На нем уже реализовали договор
За 2.5 года примерно.
В соответствии с планом — графиком по договору.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>У мееня даже была эта книжка в русском переводе. LVV>Оттуда я почерпнул знание о 3 моделях данных того времени. LVV>Для практики, наверное, не очень было нужно — не было таких объемов, как сейчас.
Вы совершаете ту же ошибку, что и vdimas. Дело не в объёмах, как таковых, а в соотношении объёмов данных и объёмов RAM. LVV>Вот особо и не парились.
Как это "не парились"??? Вопросы индексации в СУБД привлекали огромное внимание.
Ещё раз прочитайте название статьи Байера и Маккрея — то есть и данные были, и потребность была, и статьи писали.
Та же IBM из своей System R сделала вообще тестовый полигон для всяких индексов. Я в своё время, лет 20 тому, когда пошёл в аспирантуру, накачал несколько десятков статей про всякие префиксные компрессии в текстовых Bx-индексах, про delta encoding для значений ключей — и так далее. Потом, правда, аспирантуру бросил и все эти материалы выкинул. LVV>Это как с нейронками — можностя не позволяли.
Позволю себе процитировать ответ, который я заранее дал на эту вашу реплику:
Это не нейронки, обучение которых стало практически пригодным только после массового распространения многоядерных видеокарточек.
LVV>А когда стали позволять — резкий рывок S>>Нормально всё. LVV>Да, все идет свои чередом
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
V>>Я собеседовал десятки, если не больше сотни в разные годы. V>>И тенденция слишком однозначная, чтобы это было простым совпадением на многих десятках людей. S>Есть какие-то объективные данные?
Уровень владения технологиями, технический кругозор.
В общем, всё, что можно выяснить на собеседовании.
S>Без них это так — трендёж о том, как раньше девки были краше.
Трындёж — это не иметь возможности сравнить претендентов из разных эпох, но делать заявления.
V>>И дело не в уровне программистов, дело кое в чём катастрофическом другом — профессия воспринимается всё более обыденно, всё меньше горят глаза, всё менее ЛЮБОПЫТНО. S> S>Угу. Я закончил школу в 1993 году. Из параллели в 50 человек в программирование пошло двое с половиной.
Наверно потому что им было интересно и до ВУЗ-а.
S>И сейчас успеха в программировании добивается примерно 1 из 20.
Верно, сейчас вменяемых 1-2 человека из выпускаемой группы ВУЗ-а в 20+ человек.
Я так и говорил, а ты споришь.
Зато у нас из группы примерно треть достаточно успешны, т.е. примерно как эти 1-2 сегодня.
И так же из других групп в потоке и еще на 2-х родственных специальностях.
S>То, что теперь пытаются идти в программирование 15 из 20, общей картины никак не меняет.
Никто не говорил о том, что сейчас в IT стало меньше грамотных людей.
Говорят, что их доля резко упала.
Т.е. резко упала средняя температура по больнице.
А так-то вероятнее всего обратное, грамотных в абсолютном выражении могло стать больше из-за того, что в IT стали идти "все подряд" (по крайней мере у нас, в экс-СССР), т.е. вполне могут "раскрываться" как специалисты те люди, которые в 90-х не пошли бы учиться на программиста.
А сейчас пошли и у них всё стало получаться, "загорелись" профессией и всё в этом роде.
Но это всё неспособно компенсировать всё более возрастающий поток "балласта".
И этот "балласт" уже давно и серьёзно влияет на индустрию.
Разговоры про "планку входа" у нас шли вовсю шли уже в первой половине нулевых.
Я не могу себе представить эти разговоры в твоём 93-м, потому что за пределами требуемой на тот момент "планки входа" этих людей просто не было в профессии — они получали "корочку", но занимались другой деятельностью.
V>>А с чем ты сравниваешь? S>С девяностыми.
Ты не ответил на вопрос.
Ты ж учился не на IT, откуда у тебя статистика по однокурсникам, учившимся на IT?
S>Ну, и с тем, какие программы и какими программистами писались в 80х.
Отож, 90% нынеших программистов принципиально неспособны писать те программы.
Думаю, конкретно ты был бы способен, но тебе пришлось бы многое пересмотреть из нынешних своих представлений.
Ну и прокачать некоторые навыки, например, внимательность и объективность.
S>У меня инсайд из НИИ Автоматизированных Систем — типичное учреждение промышленного программирования. S>Уверяю вас: никакого "любопытства", никаких "исследователей". Совершенно простые смертные. Тётеньки, которые писали унылые программы на фортране.
И они получают свои 5-10 тыс $$ в месяц, поэтому сидят там? ))
Или там остались только те, кто не способен столько получать?
V>>И в насколько разные это были годы? S>Лично я — с конца 90х и до сих пор.
Лично я обратил внимание на проблему уже в 2002-м году на собеседованиях.
Заметным потоком пошли претенденты из разряда "да вы издеваетесь!", пока не понял, что это такая новая реальность.
В моё время подобные ребята даже не рыпались.
А тут нагло ходят на собеседования.
Я не могу представить себе подобное в других областях, где требуются определённые непростые навыки.
Например, придти устраиваться танцором в балет, но растяжки нет, классика хромает, прыгучесть нулевая...
Решат, что чел просто прикалывается. ))
В общем, подобного уровня "программисты" из выпускников нашей группы программистами работать так и не стали, нашли себя в другом.
А сейчас аналогичные ребята уверены, что хоть где-то их возьмут, бо дефицит и всё в этом роде.
V>>Проблема примерно в следующем — увлекающийся программист осваивал материала по специальности примерно раз в 10 больше, чем давала программа ВУЗ-а. S>У нас и в 100 раз можно было больше, т.к. специальности не преподавали. V>>Сейчас доля таких студентовв разы ниже, дай бог 1-2 на группу. S>Их всегда и было 1-2 на группу.
Это в твоей непрофильной специальности из группы 1-2 любопытсвовали в IT, оттуда статистика? ))
Вообще странно, что ты сразу не пошёл на интересующую тебя специальность.
S>Если в одной группе окажется 3-4, то в другой будет 0-1.
На IT-специальностях так не было, разумеется.
Специальность была нифига не престижная, туда люди обычно знали, зачем шли.
За вычетом буквально нескольких, которые непонятно как в этой специальности оказались.
Мне проще вспомнить тех, кому специальность была не интересна и кто к окончанию ВУЗ-а был от неё далёк, чем наоборот.
В нашей группе было "совсем сильных" 5 человек и еще десяток с лишним достаточно вменяемых, включая двух девушек.
Когда искал себе людей на проект когда-то (нужно было достаточно много людей), то расчитывал хотя бы на вменяемых.
Что касается девочек — им системное программирование даётся объективно тяжелей, но многие грамотные девочки нашли себя в прикладном направлении, в 1C, и неплохо себя чувствуют.
Из одногруппниц — руководитель отдела 1С крупного поставщика решений, еще одна владелица-руководитель собственного такого предприятия помельче.
V>>И у тебя разве есть достаточная выборка по однокурсникам хотя бы до начала нулевых, чтобы сравнивать с тем, как оно есть сейчас? S>Конечно есть выборка.
Та не мог твой ВУЗ быть совсем отсталым, даже в пик развала в 93-м.
Просто у тебя выборка по непрофильной специальности.
V>>Чел попытался присвоить себе "ошибку", которая до него была уже "сделана" эдак тысячекратно, например, тот же nil в Lisp. S>Да, с самомнением у вас всё хорошо. Хоар, оказывается, тупой — сам не знает, что сделал. И то, что вы nil в lisp не отличаете от NULL в Алголе — тоже плохо.
Оба на!
Пошёл юмор! ))
В Lisp и Algol абсолютно идентичные nil, никакого NULL в Algol нет, RTFM!
И распространённой практикой в те годы были списки на манер лисповых — cons/car-cdr.
Защита от nil всегда через проверки, что в Lisp, что в Algol, безальтернативно.
Далее.
Lisp не в вакууме жил, решал в т.ч. реальные задачи.
В том числе обращался к низлежащим АПИ и точно так же мог спровоцировать проходы по памяти.
Абсолютно идентично это было и в Algol.
Ответственность по-прежнему лежала на программисте — проверил ли он аргументы перед вызовом низлежащих опасных вызовов или нет.
Разумеется, идущие в поставке стандартные библиотеки обоих языков проверяли аргументы, в т.ч. на nil, т.е. были безопасны как в Lisp, так и в Algol, но речь не о стандартных библиотеках, верно?
Речь о пространстве допустимых ошибок.
В Лиспе вообще много чего проверять надо было, чтобы программа не улетела не туда в своём исполнении. ))
Таки, сильно динамический язык.
Ну и, тот же Лисп и им подобные языки тоже на чём-то писать надо — не всё же на асме?
Просто Хоар реально загоняет, я же приводил выдержки:
Ошибка уродливее, чем обратная косая черта в Windows
Ну какая еще Windows, хосподя...
Это из DOS.
А там из CP-M.
В 70-х годах Хоар об этом знал хорошо, но сейчас забыл, увы, поэтому несёт тихий бред.
Как думаешь, какой чертой пользовался сам Хоар приличную часть своей карьеры еще до всяких Windows? ))
V>>Альтернатива тут возможна только через IoС, т.е. в функциональных языках, когда некоему акцессору (итератору, скажем), подаётся колбэк. S>Ок, самовосхваление кончилось. Пошёл чистый, незамутнённый бред. IoC и функциональные языки соотносятся примерно никак.
Оба на, юмор продолжается! ))
В общем, функциональные языки целиком на парадигме IoC живут.
Прямо начиная с Lisp.
Сам термин IoC из объектно-ориентированной среды, я его использовал сугубо удобства ради.
В Алгол68 ф-ии тоже поддерживаются как первоклассные типы, если что.
S>Нормальная альтернатива — это собственно выразимость требования непустоты ссылки в терминах системы типов.
Я тебе заранее на это уже отвечал — смотри как это обыгрывается в функциональных языках или в том же Kotlin, т.е. в языках, где присутствуют исключения.
В той версии Алгола не было исключений и не было первоклассных ф-ий.
Он появились в Алгол68.
Поэтому — никак от слова совсем.
В общем, ты сначала прикинь хотя бы минимально, как всё это обыграть для решения реальных задач.
Далее.
Если в языке есть возможность описывать пользовательские типы, выбрасывать и перехватывать исключения, переопределять операторы и вводить алиасы типов (как typedef в С/С++), то проблема упрощается.
У нас прямо в боевых проектах на С++ из базовой нашей библиотеки используется:
S>Колбек тут совершенно ни при чём — в нормальной системе типов у меня nullable reference отличается от non-nullable reference, и это всё статически проверяется.
Это, как раз, самая простая часть, не вызывающая сложностей.
У меня выше тоже SomeTypeRef статически отличается от SomeType*.
И никаких дополнительных фич языка не потребовалось.
А теперь давай про интероперабельность nullable и non-nullable типов.
Вот проверь статически Optional<T*> без IoC или исключений. ))
template<typename T>
class Optional;
typedef Optional<SomeType> SomeTypePtr;
template<typename T>
class Optional<T*> {
T * ptr;
public:
// ========== для исключений ==========explicit operator bool() const { return !!ptr; }
operator NotNull<T>() const {
if(T * p = ptr)
return NotNull<T>(p); // здесь лишняя проверка нивелируетсяthrow std::logic_error(...);
}
// ====================================
// =========== для IoC ================template<class Some, class None>
void dispatch(Some some, None none) {
if(T * p = ptr)
some(p);
else
none();
}
// ====================================
};
void func(SomeTypeRef arg) {
arg->someFunc(); // безопасно
}
void reportEmpty() {}
SomeTypePtr ptr = GetOptionalPtr();
func(ptr); // автоконверсия в NotNull, выбросит исключение, если NULLif(ptr)
func(ptr); // безопасно, ноль дополнительных проверок
ptr.dispatch(func, reportEmpty); // функциональный стиль.
В Хаскеле возможен только IoC вариант, т.е. рантайм-диспетчеризация как в последней строчке:
data Optional t = Default | Specific t;
func :: Optional SomeType -> Void
func (Specific ptr) = someFunc ptr
func Default = reportEmpty
Да, до некоторого предела вложенности компилятор при оптимизации производит распространение констант, поэтому часто рантайм-диспетчеризация заменяется на прямо вызов, но в современных С++ эта оптимизация куда глубже/качественней, так шта мой С++ вариант будет соптимизирован лучше.
S>Внезапно значительная часть ссылок оказывается non-nullable.
Какое открытие! ))
S>А nullable reference нужны не чаще чем, скажем, Nullable<int>. Как-то же работает C# с int? безо всяких IoC и коллбеков. Удивительно, да?
V>>Других техник борьбы с nil, кроме диспетчеризации на манер IoC, в природе не существует, даже в Kotlin. S>(facepalm). Тут прекрасно всё — и "даже" Котлин, как вершина развития языкостроения, и применение IoC для борьбы с nil, и диспетчеризация... S>Жаль, что всё современное программирование прошло мимо вас.
Жаль, что мы в разных весовых категориях по этому вопросу, я даже качественно надо тобой поизмываться не смогу в ответ на подобное хамство, бо ты даже не поймёшь сути измывательств.
ОК, дай мне пример языка, которым ты владеешь хотя бы на самом начальном уровне, где есть строгая первоклассная поддержка non-nullable ссылок.
Скорее всего, у тебя в копилке ни одного такого языка нет.
Но очередное громкое заявление про "современное программирование" было! ))
В общем, такие языки есть, но их нет в мейнстриме.
Более того, многие из них достаточно старые.
В общем, RTFM! как эту проблему решают языки, которые обладают требуемым свойством.
И да, в Kotlin всё хорошо именно в этом аспекте (не берусь обсуждать другие "достоинства" языка), т.е. там не хуже, чем в других языках, которые нельзя отнести, скажем, к чисто функциональным, т.е. где нет поддержки исключений.
Посмотри, например, языки, со встроенной поддержкой зависимых типов, как там обыгрывают подобные сценарии.
V>>А фраза целиком лишь характеризует уже старого и недостаточно умного человека. S>Забавно, что вы тут усердно опровергаете утверждение "программисты прошлого были умнее".
Хоар и был умнее.
Человеку почти 90 лет, тут не стоит манипулировать/спекулировать.
S>Видите, и Хоар вам недостаточно умён.
1. Один из распространённых приёмов демагогии.
2. Я ответил на эти спекуляции заране, зная тебя. Увы, не помогло. ))
Я уверен, что стоит тебе только начать копать проблематику первоклассной поддержки non-null ссылок в языках, и тебе станет мучительно стыдно за вопросы про диспетчеризацию или про обязательную поддержку исключений как альтернативу явной или неявной (как в Хаскель) диспетчеризации.
(Хотя, поддержка исключений — это тоже своего рода неявная диспетчеризация, бгг...)
S>Да, я помню, для вас и Билл Гейтс недостаточно успешен
Цитату или балабол.
Там ты мне это приписывал, помнится, примерно как здесь приписываешь, что я считаю Хоара глупым.
Я считаю высказывания постаревшего Хоара глупыми, и они, действительно, глупы, чего только стоит сравнение с косой чертой.
А когда он принимал те или иные решения, он был в расцвете своих способностей, принимал эти решения куда как осмысленней.
V>>В точности проблема нулевых ссылок повторяется в массивах, к которым обращаются по индексу. S>Эта фраза показывает, что вы не понимаете сути "проблемы нулевых ссылок".
Да нет, эта фраза показывает, что ты не понимаешь зависимых типов.
Проблема же не только в null, ссылка вообще может ссылаться на мусор в памяти.
Т.е. простая проверка на не null не решает вопрос окончательно.
В языках с зависимыми типами индекс не может вылезти за пределы массива никак, прямо на уровне типов.
Точно так же, как ненулевая ссылка не может принять нулевое значение.
Ссылка вообще не может принять невалидное значение.
V>>И чего ж старик не упомянул эту проблему, хотя проблема в точности идентичная? S>Надо полагать, оттого, что проблема — не в точности идентичная. V>>Это ровно один и тот же класс ошибок, вызванных одной и той же причиной — невозможностью в compile-time выразить ВСЕ требуемые ограничения из runtime. S>Это какой-то очень широкий класс ошибок.
Уфф...
Адрес — это индекс ячейки памяти.
Проблема невалидного адреса в точности равна проблеме невалидного индекса.
И ведет к асболютно идентичным ошибкам — к неверной реентерпретации памяти.
Я тебе в C# запросто создам управляемую ссылку на мусор в памяти (произвольный адрес, не обязательно null).
И никакое #nullable enable не спасёт.
Да и оно сейчас пока живёт как ворнинги.
И запросто обходится через !, без рантайм-проверок.
Это ты вот это всё имел ввиду под "современным программированием"? ))
В общем, в языках с зависимыми типами нет принципиальной разницы на допустимые ограничения, контроллируемые системой типов, будь это [0, 1, 2] или [0, 1..]
Там работает один и тот же механизм.
Синтаксически в разных языках это может выглядеть по-разному, но по-сути происходящего — идентично.
Опять же, зависит от наличия или нет исключений в языке!
Например, в языках с зависимыми типами без исключений может применяться flow control,
т.е., некий uint[0..MAX_UINT] может быть приведёт к ограниченному типу uint[0..10] через простой if:
uint array[10] = ...;
uint x = readX();
func(array[x]); // ошибка компиляцииif(x < 10)
func(array[x]); // OK, тип переменной x модифицируется контекстом предыдущих вычислений
S>Ну, то есть понятно, что в общем случае проблема — ровно в том, что статическое доказательство корректности произвольной программы сводится к проблеме останова, которая неразрешима.
Про произвольную программу речи не идёт, речь идёт об одном аспекте — о программировании в ограничениях на уровне системы типов.
Эти ограничения не дают неверно интерпретировать память.
Программа может содержать ошибки и при верной интерпретации памяти, но эти ошибки проще искать и они не столь непредсказуемы в своих проявлениях.
Плюс не оставляют простора для хакерских атак.
Далее.
Способ выражения ограничений в языке в свою очередь накладывают ограничения на дизайн программы.
Например, во многих языках с зависимыми типами ты не можешь прочитать массив данных из файла и передать его куда-то дальше, примерно так (псевдокод):
let array<?>(int) = readFromFile();
process(array);
Ты можешь действовать только через IoC:
readFromFile(process<N: uint>: array<N>(int) -> Void) {
let loop<N:uint> array<N>(int) ar = {
...
if(eof)
process(ar); // конец работы, вызов поданного продолженияelse
loop(insert(ar, data)) // хвостовая рекурсия, вызов лямбды loop с новым типом ar (с новым размером)
}
loop array<0>(int); // начало цикла
}
Т.е., с т.з. "обычных" языков, имеющих генерики/шаблоны, каждый вызов loop не является рекурсией, т.к. вызывается ф-ия другого типа.
Но для зависимых типов это обычная рекурсия, которая в случае хвостовой раскручивается компилятором в цикл.
S>Но нормальному инженеру недостаточно такого общего доказательства, поэтому мы вводим разные виды и классы ошибок, с которыми и боремся.
Давай не будем о нормальности.
Теория зависимых типов была разработана не с 0-ля в 70-е, а первые работы на эту тему были еще в 1925-м, задолго до первых компьютеров.
Не надо считать всех идиотами. ))
Речь тут не о теоретических вещах, бо с теорией давно всё хорошо, а сугубо об инженерных — о реализуемости, стоимости, практичности.
S>В частности, "проблема" нулевой ссылки легко статически разрешима на более-менее любой современной платформе.
Если ты про C#, то анекдот хороший.
S>Даже настольные языки, собранные на коленке энтузиастами, прекрасно обходятся без нулевых ссылок.
Фортран тоже обходился без нулевых ссылок.
Да и вообще любые языки, где явное оперирование динамическими структурами невозможно. ))
А этих структур огромное кол-во, всё их разнообразия в виде встроенных типов данных не предусмотришь, поэтому большинство таких наколенных "безопасных" языков имеют один тип динамических данных — связанный список. ))
В общем, интерес предоставляют не наколенные языки, а те, которые позволяют экспериментировать с произвольным лейаутом динамических данных в памяти с типизированной гарантией безопасности обращения к данным.
Т.е., неверно обращающаяся к данным программа не должна уметь компиллироваться.
S>Кстати, вопросы индексов в массивах давно закрыты: https://www.cs.cmu.edu/~fp/papers/pldi98dml.pdf. Так то про "невозможность в компайл-тайм" — это лично ваши заблуждения. Развивайтесь, читайте.
— Ты куда, в баню?
— Да нет, в баню!
И зачем ты даёшь столь неинформативную статью со столь бедными примерами, если есть полно отличных статей, описывающих проблематику и способы их решения, а так же ограничения на конструкты, которые допускают "распространение" типизированности по данным?
В т.ч. на русском.
Это тебе первая ссылка на англоязычном гугле подкинула и ты не читая кинул, чтобы поднадуть щеки?
И статью ты ниасилил, иначе бы не сверкал невежеством тут:
S>IoC и функциональные языки соотносятся примерно никак.
V>>В точности проблема нулевых ссылок повторяется в массивах, к которым обращаются по индексу.
S>Эта фраза показывает, что вы не понимаете сути "проблемы нулевых ссылок".
А теперь правильный ответ:
— вопрос не то, что еще не закрыт, а даже не планируется быть закрытым в мейнстриме в ближайший десяток-другой лет.
Ты обратил по ссылке внимание на сам принцип написания программ?
Это другой принцип проектирования.
Показан один из беднейших инструментов реализации ЗТ — хвостовая рекурсия, каждый раз вызывается локальная ламбда с новым типом аргументов.
И вот как раз конечный результат вычислений можено будет подать куда-нибудь далее в вычислениях поданному как аргумент функциональному объекту, потому-то и IoC, что список неизвестного размера нельзя вернуть из ф-ии. ))
Можно только вызывать другую ф-ию в типизированном контексте.
V>>(в языках, которые претендуют на хоть какую-то эффективность) S>Эта фраза тоже выдаёт непонимание сути проблемы. Как раз неэффективное решение проблемы и состоит в переносе проверок в ран-тайм.
Проверки в рантайм всё-равно есть, вопрос в том — сколько их.
Ведь достаточно проверить один раз (или достоверно получить валидное значение по new) и далее распространять значение уже с признаком валидности.
Насчёт "непонимания сути" — опять улыбнуло.
Это ты в своём C# не понимаешь сути, потому что нет алиасов типов, невозможно отсутствие конструктора структуры без параметров.
Поэтому ср-вами языка проблему не решить — нужен встроенный костыль.
А я тебе выше показал примеры на C++, которую столь узкую постановку вопроса решают на раз-два.
Причём, с нулевым оверхедом, в сравнении с обычными указателями.
И без переделки исходников, т.к. Optional<T*> и NotNull<T> — это умные указатели, с переопределёнными operator-> и operator*, т.е. их можно использовать там, где ожидался обычный указатель, только теперь можно распространять non-nullable указатели без лишних проверок.
S>Любое компайл-тайм решение получается более эффективным, как только время ожидаемой работы программы становится достаточно большим.
Увы, увы.
Программы, написанные в этом стиле, как по ссылке, построены таким образом, что в функции всегда передаются другие функции-"продолжения".
Т.е. вся работа основной программы — это бесконечный вызов ф-ий из ф-ий.
Но стек ведь не бесконечен? Отсюда монады и ленивость.
То бишь, "энергичный" вызов ф-ий заменяется динамически выстроенным графом продолжений, где вычисления передаются динамически же вычисленным в процессе работы программы веткам графа через явные if или неявную дистептчеризацию, на манер Хаскеля.
То бишь, никакого call не происходит, вычислительная модель языка в ленивой манере протягивает монаду процесса/потока по этому графу вычислений.
То бишь, вычисления выглядят в рантайме так:
func1 -> result1 -> func2 -> result2 -> func3 -> ...
И до чудес быстродействия там как до звёзд.
V>>И до изобретения исключений, без техники IoC, т.е. без функциональных ср-в в языке, ошибок такого рода в процедурных языках избежать было нельзя, можно было лишь сгенерировать проверочный код компилятором (...) и аварийно завершить программу, если проверка на индекс или nil была неудачной. S>И опять вы складываете в одну кучу рантайм и компайл-тайм проверки. Это вы мухлюете или вправду не видите разницы?
Это ты не понял прочитанного. ))
Медитируй до просветления, плиз.
V>>Разумеется, новое дыхание в конце 90-х и начале 2000-х получили теории языков. S>Вот как раз тут прямо таки нового появилось не очень много. V>>Без изобретения нового. S>Воот! В основном то, что мы наблюдаем — приезд в мейнстрим идей и концепций из 1960х. Так что "теории языков" вычёркиваем.
В 70-х только начали классифицировать типизированные лямбда-исчисления.
Классификация была нужна для понимания (1) необходимого и достаточного набора конструктов языка для соответствия выранным критериям и (2) для понимания необходимых техник программирования в данном классе ограничений, см лямбда куб (наглядное представление классификации).
В 60-х еще вопрос так не стоял, т.к. выразительные ср-ва компилятора диктовались сугубо объемом оперативной памяти, которой располагал компилятор в процессе своей работы.
Ну и, в 60-х годах, таки, разработкой языков занимались математики, поэтому языки те были полны в рамках выбранных концепций, в отличие от наколенных языков от энтузиастов сегодня.
Сегодняшние столь же "академические" языки в мейнстриме — это Golang, Dart, Хаскель.
И то, мейнстрим весьма условный. ))
F# (OCaml), Scala, Kotlin — уже нет.
C# — совсем нет.
В рамках выбранной концепции он далеко не полон, не обладает всеми необходимыми выразительными св-вами.
Собсно, поэтому развитие языка запросто идёт дальше при сохранении бинарного формата сборок еще аж со времён 2-го дотнета.
Блин, указатели на ф-ии только-только ввели.
Через stackalloc стало можно размещать не только примитивные целочисленные типы вот только недавно.
И т.д. и т.п.
V>>Я когда-то уже высказывался на эти темы ~12 лет назад в ответ молодому и горячему в те года Вольфхануду: V>>http://www.rsdn.org/forum/philosophy/4247637.1 S>Ну, так и зачем самому себе противоречить?
Нет никакого противоречия.
Действительно, было повышенное внимание к теории языков, т.к. была надежда в продвижении статического анализа программ, что необходимо для эффективной компиляции языков с ленивой вычислительной моделью.
Т.е., одно дело понятно в теории, другое дело практическое воплощение.
В экспериментах над "окончательной оптимизацией" (как оно достижимо в теории) не самых больших программ работали суперкомпьютеры часами.
Как тебе задача — выделить из данной цепочки символов всевозможные подцепочки максимальной длины, встречающиеся более одного раза.
Оцени сложность в терминах O.
Умножь на многие мегабайты размеров современных программ.
Это всего лишь одна из подзадач в процессе оптимизации — склейка самоповторов после стирания типов на одной из стадий оптимизации.
Сначала над типами работает бета-редукция и генерирование уникального кода из генерик-представления.
(А чуть ли не весь код на Хаскель — это сплошные генерики в терминах C#)
Здравствуйте, Sinclair, Вы писали:
LVV>>Для практики, наверное, не очень было нужно — не было таких объемов, как сейчас. S>Вы совершаете ту же ошибку, что и vdimas. Дело не в объёмах, как таковых, а в соотношении объёмов данных и объёмов RAM.
Ошибку сейчас совершил ты — имеется ввиду отношение объемов индексов и RAM.
С древовидными индексами и размерами RAM всё было хорошо в течении нескольких десятилетий, бо рост основного дерева индекса логарифмический от роста кол-ва данных, а размеры RAM росли быстро.
Просто надо понимать специфику — сейчас в среднем "реальных данных" всё еще столько, что обычный b-tree индекс справляется на ура.
Но появилась новая отрасль — биг дата.
В них кол-во данных на несколько порядков превышает кол-во "традиционных" данных.
S>Это не нейронки, обучение которых стало практически пригодным только после массового распространения многоядерных видеокарточек.
Для обучения сетки использовались кластеры до эпохи вычислений на карточках.
В общем, не понимаешь специфику — big-data могут быть обработаны горизонтальным масштабированием.
В случае нейронки в этом случае всё плохо, не масштабируется.
Это точно проблемы программистов? 
