Новое сообщение в форум Философия программирования

Форум	Философия программирования
Тема	Как правильно задавать вопросы

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

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

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

V>>И дело не в уровне программистов, дело кое в чём катастрофическом другом - профессия воспринимается всё более обыденно, всё меньше горят глаза, всё менее ЛЮБОПЫТНО.
S>:) 
S>Угу. Я закончил школу в 1993 году. Из параллели в 50 человек в программирование пошло двое с половиной. 
S>И сейчас успеха в программировании добивается примерно 1 из 20. То, что теперь [i]пытаются[/i] идти в программирование 15 из 20, общей картины никак не меняет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

V>>Собсно, любые n-tree выразимы через b-tree, но решают недостатки b-tree по оверхеду служебной памяти, по локальности данных и т.д.
S>Простите моё невежество, а что такое n-tree? И как именно они недостатки B-tree по оверхеду решают?
S>Или вы B-tree принимаете за бинарные деревья? 
S>В любом случае: 
S>[q]
S>better query and update time than a B+-tree by up to 71% in various dynamic workloads while [b]reducing its space occupancy by four orders of magnitude[/b] (from gigabytes to few megabytes).
S>[/q]
S>Это к вопросу о "компактификации".

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

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

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

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

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

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

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

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

Теги:

Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например: "Visual Studio" .NET

Имя, пароль: Загрузить Нравится наш сайт? Помогите его развитию!
Отключить смайлики Получать ответы по e-mail