Новичок будет дополнительно шокирован, когда узнает, что у int есть ограничение максимального значения, что присутствует uint и обычный , что есть long и остальные.
Не, в Питоне драконы живут не совсем там. Они живут в семантике изменяемых данных — она крайне неочевидна. В результате и очень опытные энтузиасты Питона не могут вручную уверенно проинтерпретировать программу — всё время опасаются подвоха.
Классические:
def f( x = []):
x.append(1)
return x
l1 = [1, 2, 3]
l2 = l1 # Тут надо рассуждать в терминах указателей!
l1.append(4)
print(l2)
l1 += [5]
print(l2)
Ну и недавний шедевр (спасибо тут кому-то) — что выдадут две программы
a = 1
b = 2
def f():
print(b)
a = b
f()
и
a = 1
b = 2
def f():
print(b)
b = a
f()
Хочу отметить, что если я все эти программы переведу на OCaml, практически кто угодно без труда их проинтерпретирует.
Ну я как бы продолжительное время работал в науке. Там задачи сложнее, и концентрацию требуется держать дольше.
Я просто их игнорю.
Если вы прочтёте комментарий, с которого началась ветка, там предлагается делать триаж сразу по получении сообщения. Вот этот триаж предполагает, что вы выгружаете контекст, над которым работаете, чтобы загрузить новый и сделать триаж. Дело в том, что вероятность того, что вас спросят ровно по той задаче, над которой вы работаете сейчас, мала - обычно висят же несколько разных задач.
На следующий день продолжил так же, но через час работы кто-то реально отвлек. Когда вернулся к работе, то пришла такая идея, что переписал все за минут сорок и очень круто упростил все процессы.
Я уже довольно давно сам отмечаю, когда некоторое время не могу дальше продвинуться. Как правило, это означает, что где-то не хватает каких-то данных. Дальше стандартные вещи - ищем, где же именно не хватает, переходим в над или под систему для определения этого.
А ваш пример "Прислать вам сроки" я бы тоже проигнорил.
Вообще такой вопрос свидетельствует о полном непонимании того, что в програзме помимо "фронта работ - от забора и до обеда", есть ещё и риски. То есть, сроки, на самом деле - это некоторая случайная величина, которая уточняется по мере выполнения работ.
Спокойно отвечаю на такое "да, без проблем, кинь встречу в календарь". Примерно в 10% случаев действительно кидают, ещё в 40% пишут вопрос текстом, в остальных исчезают)
И теряете 40 минут на то, чтобы, блин, обратно сконцентрироваться на задаче. Красота.
такие попытки были. но бд не справились с объемами. практически все мега-хранилища документов терабайтных объемов используют бд только для хранения ссылок на файловую систему и метаинформации типа наследования документов.
Я подозреваю, что тут как с графами - нет пока хорошего интерфейса на все случаи жизни. Кстати, опыт Python и JSON показывает, что огромное кол-во случаев при условии динамической типизации вполне закрывается буквально двумя структурами: массивом и hashmap.
Понимаете, эти срачи на тему "как должна выглядить ОС", были где-то в начале 2000х на LOR. В частности, упоминалось, что "всё есть файл" реально реализовано только в Plan 9, не в UNIX (см sockets). Что NT (ядро), сделанное Катлером сотоварищи построено на идеологии "всё есть объект". Правда написано на С, поэтому объекты реализованы как в glib. Дальше это было развито в средах выполнения .Net и JVM.
В общем, да, вы безусловно правы, что идеология UNIX стара, что можно что-то новое и интересное забабахать. Но вы тему не изучили ну совершенно, потому что люди забабахивали.
Мимо вас, например, полностью прошла идеология VM/370 "всё есть виртуальная машина". Где каждая программа выполнялась в своей собственной виртуальной машине.
Когда разрабатывали ядро Windows NT примерно также думали:
[Cutler] expressed his low opinion of the Unix process input/output model by reciting "Get a byte, get a byte, get a byte byte byte" to the tune of the finale of Rossini's William Tell Overture.
ВО даёт не столько знания, сколько умения и установки. Про наличие всяких O(N^m) легко изложить на странице текста, которую прочесть можно меньше, чем за минуту. Но вот "перекладыватель JSONов" должен
а) иметь навык оценивать любой алгоритм в том числе и с точки зрения O(N^m).
б) иметь установку, что эту оценку надо проводить обязательно.
А получение этих двух вещей - уже не страница текста и минута работы.
мне ВО мало что дало
Запросто. Может быть вы на ракетостроителя учились, а сейчас копаете картошку.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать.
В области OSS всё выглядит не так радужно: Вася выпустил программу и загадил поле. В результате, Петя даже не стал делать более продуманную версию, и все безуспешно воюют с Васиной программой, которая из-за плохой архитектуры изначально не может нормально решить задачу.
Если вы получали ВО, вы, скорее всего, проходили статистику. А значит, привыкли к тому, что есть корреляции, а есть исключения. И одно другого не отменяет. И учитывать следует и то, и другое.
Если контора, которая поддерживает и продаёт используемый код разорится или по какой-то причине решит прекратить поддержку, его всё-таки как-то можно будет использовать в "аварийном режиме". Или даже развивать самим/с помощью подрядчиков.
Поэтому крупняк так любит OSS. Да, когда есть разработчик - это прекрасно, но если разработчик по той или иной причине помре, процессы не останавливаются.
Вообще-то в програзме к.ф-м.н. от простого инженера очень часто отличается разительно. По повадкам, по знаниям, по увлечениям. К.ф-м.н обычно учится всю жизнь, поэтому в 35 его знания по теме просто на порядок выше знаний простого инженера.
Тем не менее, народ пишет на Питоне много чего, причём достаточно развесистого. Отсюда мораль:
Код на Питоне обязательно надо запускать после написания. Если код на Питоне ни разу не запускался, скорее всего, правильно он работать не будет.
Желательно писать программы, которые при любом запуске полностью проходят по всем ветвям исполнения. Классический пример — ML.
Ну и для остальных приходится писать чудовищное кол-во тестов.
Не, в Питоне драконы живут не совсем там. Они живут в семантике изменяемых данных — она крайне неочевидна. В результате и очень опытные энтузиасты Питона не могут вручную уверенно проинтерпретировать программу — всё время опасаются подвоха.
Классические:
Ну и недавний шедевр (спасибо тут кому-то) — что выдадут две программы
и
Хочу отметить, что если я все эти программы переведу на OCaml, практически кто угодно без труда их проинтерпретирует.
Увы, я неправ - триаж не требуется. Но меня такое, увы, отвлекает, т.к. я его автоматом делаю.
Ну я как бы продолжительное время работал в науке. Там задачи сложнее, и концентрацию требуется держать дольше.
Если вы прочтёте комментарий, с которого началась ветка, там предлагается делать триаж сразу по получении сообщения. Вот этот триаж предполагает, что вы выгружаете контекст, над которым работаете, чтобы загрузить новый и сделать триаж. Дело в том, что вероятность того, что вас спросят ровно по той задаче, над которой вы работаете сейчас, мала - обычно висят же несколько разных задач.
Я уже довольно давно сам отмечаю, когда некоторое время не могу дальше продвинуться. Как правило, это означает, что где-то не хватает каких-то данных. Дальше стандартные вещи - ищем, где же именно не хватает, переходим в над или под систему для определения этого.
Сижу, думаю о серьёзной задаче, тут сообщение, я отвлекаюсь, восстановление контекста и концентрации требует конкретного времени.
Вообще такой вопрос свидетельствует о полном непонимании того, что в програзме помимо "фронта работ - от забора и до обеда", есть ещё и риски. То есть, сроки, на самом деле - это некоторая случайная величина, которая уточняется по мере выполнения работ.
И теряете 40 минут на то, чтобы, блин, обратно сконцентрироваться на задаче. Красота.
А потом у вас выяснится, что помимо этапов 1, 2, 3, ... 25, нужно ещё сделать внезапно возникшие необходимые этапы 22а, 22б, ... 22х, ... 22я.
Я подозреваю, что тут как с графами - нет пока хорошего интерфейса на все случаи жизни. Кстати, опыт Python и JSON показывает, что огромное кол-во случаев при условии динамической типизации вполне закрывается буквально двумя структурами: массивом и hashmap.
Понимаете, эти срачи на тему "как должна выглядить ОС", были где-то в начале 2000х на LOR. В частности, упоминалось, что "всё есть файл" реально реализовано только в Plan 9, не в UNIX (см sockets). Что NT (ядро), сделанное Катлером сотоварищи построено на идеологии "всё есть объект". Правда написано на С, поэтому объекты реализованы как в glib. Дальше это было развито в средах выполнения .Net и JVM.
В общем, да, вы безусловно правы, что идеология UNIX стара, что можно что-то новое и интересное забабахать. Но вы тему не изучили ну совершенно, потому что люди забабахивали.
Мимо вас, например, полностью прошла идеология VM/370 "всё есть виртуальная машина". Где каждая программа выполнялась в своей собственной виртуальной машине.
Это ещё NT с такой идеологией. У Фантома, всё-таки, ещё персистентность.
Коллега, я тоже не понимаю, зачем там что-то бинарное взламывать, если можно просто перейти на открытое решение.
Когда разрабатывали ядро Windows NT примерно также думали:
ВО даёт не столько знания, сколько умения и установки. Про наличие всяких O(N^m) легко изложить на странице текста, которую прочесть можно меньше, чем за минуту. Но вот "перекладыватель JSONов" должен
а) иметь навык оценивать любой алгоритм в том числе и с точки зрения O(N^m).
б) иметь установку, что эту оценку надо проводить обязательно.
А получение этих двух вещей - уже не страница текста и минута работы.
Запросто. Может быть вы на ракетостроителя учились, а сейчас копаете картошку.
В области OSS всё выглядит не так радужно: Вася выпустил программу и загадил поле. В результате, Петя даже не стал делать более продуманную версию, и все безуспешно воюют с Васиной программой, которая из-за плохой архитектуры изначально не может нормально решить задачу.
Если вы получали ВО, вы, скорее всего, проходили статистику. А значит, привыкли к тому, что есть корреляции, а есть исключения. И одно другого не отменяет. И учитывать следует и то, и другое.
Если контора, которая поддерживает и продаёт используемый код разорится или по какой-то причине решит прекратить поддержку, его всё-таки как-то можно будет использовать в "аварийном режиме". Или даже развивать самим/с помощью подрядчиков.
Поэтому крупняк так любит OSS. Да, когда есть разработчик - это прекрасно, но если разработчик по той или иной причине помре, процессы не останавливаются.
Это не мода, это простая страховка от рисков.
Вообще-то в програзме к.ф-м.н. от простого инженера очень часто отличается разительно. По повадкам, по знаниям, по увлечениям. К.ф-м.н обычно учится всю жизнь, поэтому в 35 его знания по теме просто на порядок выше знаний простого инженера.
Тут диалектика: да, ВО меняет человека, но не всякий человек готов измениться именно так.