Вы в своей статье преподносите var как доказательство факта:
в статически типизированные языки пытаются привнести динамики
и это не соответствует реальности.
В var нет динамики. Ни в каком виде нет. Динамика - это когда что-то делается в процессе выполнения кода. Но var работает на этапе компиляции и только компиляции: статика в чистом виде.
Ваше предположение, что var появился в статически-типизированных языках под влиянием динамически-типизированных, абсолютно ошибочно. Между статическим выводом типов переменных в C#, Go, Java и полным отсутствием типов переменных в JavaScript, Python нет ничего общего.
Динамическая типизация, это когда одной и той же переменной можно присваивать значения совершенно разных типов. Вот если бы в Java можно было написать:
var x = 12;
x = "12345";
это была бы динамическая типизация.
Но нет, такое в Java невозможно. И конструкция:
var x = 12;
создаёт переменную целого типа, которой можно присваивать только целочисленные значения.
Var - не динамическая типизация, а всё та же статическая. Вся разница только в том, что вместо явного прописывания имени типа используется тип значения инициализирующего выражения, однозначно определяемый в момент компиляции. Это называется "выведение типа": оно используется во многих статически типизированных языках и не имеет никакого отношения к языкам с динамической типизацией.
Вы относите слово "неизменяемый" к содержимому структуры данных, но применительно к ключам ассоциативного массива (в Python - "словаря") смотреть надо не на неизменяемость содержимого, а на неизменяемость того, что хэшируется и/или сравнивается операциями == и !=.
В случае объектов хэшируется/сравнивается не содержимое объектов, а никак не изменяемые указатели (адрес в памяти, id в таблице объектов и т.п.) этих объектов. Независимо от того, как меняются значения полей объекта, указатель и хэш, полученный из этого указателя, остаются неизменными. Аналогично с функциями.
Научная фантастика отражает состояние науки, технологии, общества... А в науке и технике до второй мировой войны не было задач, требующих цифровых вычислительных машин. Аналоговая логарифмическая линейка обеспечивала приемлемую для большинства инженерных расчётов точность, а сложные, для того времени, системы просчитывались с помощью аналоговых же моделей (как, например, проектировал свои здания Гауди). Там же, где требовались массовые математический вычисления, вполне хватало тривиальных табуляторов.
Да, система команд PDP-11 прекрасна. Как эсперанто.
DEC погубила не система команд, а менеджеры. Именно концепции PDP-11 и VAX-11 стали основой и для 68k, и для 80386. Но в Motorola это сделали на много лет раньше, а Intel понадобилось несколько поколений процессоров, чтобы осознать всю бесперспективность своих оригинальных грабель.
Ну, тут надо и на код смотреть, и на компилятор
На ДВК был компилятор, портированный в RT-11 из Unix. Он использовал r0 и r1 как базовые регистры для вычислений, регистры r2-r4 для оптимизации процесса вычислений: хранение промежуточных значений, указателей, переменных цикла; r5 использовался для границы стекового фрейма. А т.к. регистры универсальны, то r2-r4 использовались в любых процессорных командах сразу - без промежуточного копирования через другие регистры.
В MS-DOS использовался компилятор либо Borland, либо Microsoft: в разное время я использовал разные версии обеих фирм и какой точно это был компилятор, уже не вспомню.
Задача была не на сложение двух чисел, а на автоматизацию бухгалтерских задач - когда 1C ещё не было. И компилятор для PDP-11 выдавал куда более оптимизированный код. Дело не в скорости выполнения одной команды (я же специально указал, что тактовая частота процессора в ДВК была ниже), а в количестве этих команд. Компилятор для Intel генерировал ассемблерный код существенно большей длины - именно потому, что ему приходилось использовать узкоспециализированные регистры, привязанные к конкретным процессорным командам.
Именно потому я в своём исходном комментарии и написал:
с точки зрения системы команд
Я не аппаратчик, а программист. И мне совсем не важно, какая именно физическая шина у процессора - важна именно разрядность регистров. Никто же не причисляет 8088, имеющий 8-битную физическую шину, к 8-битным процессорам.
И разве в 30386 физическая шина адреса была 32 битной? Да и 32-битная физическая шина данных была только у старших моделей.
Но куда важнее даже не разрядность процессоров, а наличие универсальных регистров и плоской адресации. ИМХО, именно отказ от принципов, на которых построена система команд в линейке 8086-80286, и переход к тому, что уже было у конкурентов, позволил создать процессор, для которого можно было написать компиляторы языков высокого уровня, эффективно оптимизирующие машинный код.
Из моего личного опыта: один и тот же C-код, производящий много целочисленных вычислений, на ДВК-3м2 (КМ1801ВМ3, 10 MHz) работал существенно быстрее, чем тот же самый код на IBM-PC/AT (20286, 12 MHz).
Например, Motorola 68k (надеюсь, построенный на нём Apple Macintosh вы считаете массовым компьютером?). Первое поколение (1979 год) имело 32-битную адресацию и 32-битную систему команд, реализуемую 16-битным ALU. Второе поколение (1984 год) - 32-адресация и 32-битное ALU.
Возможно, с точки зрения своей архитектуры Intel 80386 и был революционным - в проектировании микросхем я не разбираюсь. Но с точки зрения системы команд он был абсолютно зауряден: универсальные регистры и плоская 32-битная адресация - то, что в других процессорных архитектурах появилось намного раньше, чем в x86, и с позиции программиста 80386 - не "революция", а погоня за ушедшими вперёд конкурентами.
Поток демагогии, в средине которого под видом "осуждения эвристик" аккуратно подсовывают пропаганду лженауки. Что, полагаю, и является главной целью этой статьи.
P.S. Каждая современная "нейросеть" - это и есть эвристика в чистом виде.
"Ответы" убиты. В мае 2025 года под видом очередного "обновления" сервис ответов на вопросы был уничтожен и на его место помещена очередная типовая помойка "мнений" и "историй".
Чтобы научить программированию, учить надо совсем не написанию кода. И именно это автор статьи не понимает (или сознательно делает вид, что не понимает). А когда именно начинать учить, совершенно не важно. Более того, я выше прямым текстом говорю о том, что детские конструкторы куда лучше попыток навязать ребёнку программирование.
В моё время программированию начинали обучать в 17 лет - на первом курсе ВУЗа. И это никому не мешало становиться профессиональными программистами. Но, с другой стороны, познакомился с идеей программирования я за много лет до этого: в книге "Кибернетика без математики" (с мамонтом на обложке), не содержащей ни одной строчки программного кода. И прочитанная в подростковом возрасте книга "Принцесса или тигр" (которая совсем не про программирование) дала мне, как будущему программисту, несравнимо больше, чем любой самоучитель языка программирования.
Нет запроса на "программирование". Есть запрос на интересную ребёнку развивающую деятельность. И универсальный пластмассовый или металлический конструктор, позволяющий комбинировать детали как угодно, а не собирать единственную указанную в инструкции модель, даст для развития дошкольника несравнимо больше, чем попытки научить программировать.
Физику в школе начинают учить не тогда, когда учащийся дорастает до её понимания, а когда уровень математических знаний достигает минимально необходимого для понимания формул в учебнике физики. Но та же "Занимательная физика" Перельмана прекрасно воспринималась за несколько лет до начала преподавания физики в школе.
Если же говорить про программирование, то начинать обучать детей надо не с языков программирования (даже если это будет Scratch), а вот с такого: https://www.youtube.com/watch?v=cDA3_5982h8. И решать алгоритмические задачи дошкольник может - если эти задачи сформулированы на доступном дошкольнику уровне.
В позднесоветские времена в журнале "Знание-сила" (если память не подводит) была серия статей человека, обучавшего пятилеток математике. И, например, чтобы они поняли, что такое параллельный перенос, центральная и осевая симметрии, оказалось достаточно обычной детской мозаики.
В этом возрасте дети уже имеют хоть ограниченное второй сигнальной системой, но уже вполне полноценное абстрактное мышление. Из другой статьи того же автора: в задаче на классификацию дети не могли понять, как можно обозначить одним значком красный кубик и красный шарик (они же разные), но задача была решена, когда один из детей додумался (самостоятельно), что значок должен обозначать не предмет, а слово "красный". Т.е. дети уже умеют оперировать абстракциями - в виде слов "человеческого" языка.
Опять под видом "обучения программированию" пытаются впарить дрессировку в кодинге. Вместо обучения способам решения программистских задач (т.е. алгоритмам) заучивание и бездумное воспроизведение типового кода, кое-как решающего простые типовые задачи. Без малейшего понимая того, что любую задачу можно решить множеством разных способов и что работа квалифицированного программиста - не написание кода, а нахождение эффективного для данного конкретного случая алгоритма решения задачи.
А уж предлагать Python и JS, провоцирующие новичка писать говнокод и никак не дающие учащемуся оценить качество придуманного им способа решения задачи - это откровенная диверсия, направленная на сокращение числа профессиональных программистов.
P.S. Зато подобное "обучение" и подобные рекламные статьи обеспечивают российским "курсам программирования" (большинство из которых откровенно мошеннические) максимальную доходность. Что и объясняет нескончаемых поток таких материалов в рунете.
Я из того поколения разработчиков, которых учили, что качественно спроектированный язык программирования должен быть ортогональным. И это одна из причин, почему Go нравится мне намного больше большинства актуальных императивных языков программирования, в которых почти одно и то же можно сделать десятком разных способов - лишь бы замученный своей тяжёлой долей разработчик не надорвался, нажав при наборе кода на несколько клавиш больше.
Любой язык программирования - лишь вспомогательный инструмент для решения определённого круга задач. Разные задачи - разные инструменты. И не существует языка, одинаково подходящего для всего.
Тот же GC противопоказан только в системном программировании и в Real-Time. А в прикладном софте (которого несравнимо больше, чем системного софта и систем управления физическим процессами вместе взятых) GC - это безусловное увеличение надёжности кода.
Язык C - прекрасный инструмент для системного программирования. Но как язык прикладного программирования он обладает фатальным недостатком: вся ответственность перекладывается на кодера. В C-коде очень просто допустить ошибку и очень сложно её найти. Это инструмент для очень опытных разработчиков, но кодеры нижнего-среднего уровня мало того, что неизбежно будут ошибаться, так ещё и не смогут понять, что ошиблись. Microsoft по меньшей мере десятилетие активно вычищала баги из ядра Windows, написанного на C.
А ещё у C абсолютно ужасный синтаксис. Да, с появлением C++ многое в C причесали, но, например, кошмарное объявление типа как шаблона никуда не делось: https://habr.com/ru/articles/116255/. В этом отношении из всех известных мне C-style языков наиболее удачен Go (язык прикладного уровня) - в котором из C выбросили всё, что делает язык ненадёжным, и добавили ровно то, что реально необходимо, при этом максимально унифицировав и упростив синтаксис.
Да, при использовании компилируемых языков такое решение безусловно эффективнее. Но в интерпретируемых языках (к коим относится и Python) всё не столь однозначно.
Каждая операция в языке с динамической типизацией - это большие накладные расходы. И сравнение в цикле десяти пар строк длины 1 (в Python нет символов - только строки) может производиться намного дольше, чем сравнение двух строк длины 20. Накладные расходы на сам цикл, на курсор, на доступ к элементам строки, на проверку типов операндов в каждой операции сравнения с одной стороны и единственная операция сравнения с единственной проверкой типов операндов другой стороны.
Так что без реальных экспериментов на разных входных данных невозможно сказать, что именно в Python будет эффективнее: две операции (однократное создание среза длины N и однократное сравнение среза и исходной строки) над длинными строками, или (N/2)*5 операций (цикл, дополнительный курсор, доступ по индексу слева, доступ по индексу справа, сравнение двух строк длины 1) выполняемых в оптимизированном алгоритме.
Статья называется: "Очистка данных перед загрузкой в хранилище. Подробное руководство с техническими деталями". В реальности же в статье нет ни "подробного руководства", ни "технических деталей". И даже о том, как именно надо очищать данные до загрузки, в статье нет ни слова. Зато все три примера демонстрируют очистку данных после загрузки в хранилище. Причём очистка производится модификацией данных в таблице, из которой эти данные были прочитаны. Подобные запросы прекрасно смотрелись бы в статье "Как нельзя производить очистку данных", но предлагать такое как образец очистки...
Если статья рассчитана на "непрошаренных", то это не повод обещать в заголовке то, чего в статье ни в каком виде нет, и использовать заведомо низкокачественные примеры, никак не соответствующие теме статьи.
Никто не писал в статье, что мы рассмотрим все варианты кода на все языках программирования.
Если вы не рассматриваете примеры кода, то зачем упоминать языки программирования, библиотеки, программные пакеты? Вставленные только для того, чтобы эти названия присутствовали в тексте статьи - в окружении воды, не несущей никакой реальной информации.
Да, такая схема имеет место быть. Но в ней используют отдельные таблицы для хранения сырых и полуобработанных данных: каждая стадия обработки берт данные из одних таблиц и записывает в другие таблицы. И в этой схеме нет запросов, модифицирующих данные, записанные в исходных таблицах.
Хотелось бы понять, где именно в статье показано использование Python, R, ETL для "очистки данных"? Зачем эти абсолютно бессмысленные упоминания, выставление тегов и размещение в хабах, никак не относящихся к содержательной части статьи? Информационный мусор в надежде привлечь посетителей?
И где вообще объявленная в заголовке статьи "очистка перед загрузкой в хранилище"? Вся содержательная часть статьи (после отжима воды) - три SQL'ных костыля, применяемых к уже загруженным в хранилище данным и необходимых только потому, что структура реляционной базы данных разрабатывалась абсолютно некомпетентными "специалистами".
Первый запрос не нужен, т.к. недопущение дублей автоматически реализуется на уровне создания таблицы БД - добавлением уникальных индексов и/или триггеров.
Второй запрос не нужен, т.к. дефолтные значения для столбцов задаются, опять же, при создании таблицы. И если в столбце таблицы не должно быть NULL, такой столбец изначально создаётся с модификатором NOT NULL.
Но если два первых запроса ещё более-менее понятны (напахали со структурой, бывает, но в этом случае корректирующий запрос выполняется единственный раз - перед внесением правок в структуру таблиц), то третий SQL-запрос вызывает, мягко говоря, недоумение... Во первых, функция ISDATE существует только в MS SQL Server и не может иметь никакого отношения к хабу PostgreSQL (в котором статья находится в настоящий момент). Во вторых, если столбец даты имеет тип DATE, то весь этот запрос абсолютно бессмысленен, т.к. никак не меняет данные в таблице. Но если столбец для хранения даты имеет тип VARCHAR, то это даже не некомпетентность, а невежество создателя таблицы.
P.S. Сама идея "очищать данные", записанные в реляционную СУБД - показатель непонимания автором того, что такое РСУБД. Реляционные базы предназначены для уже "очищенных" и полностью структурированных данных и использовать их для "сырых" данных - это как пытаться спилить столетний дуб ножовкой по металлу. Для хранения "сырых" данных предназначены совсем другие хранилища, не имеющие никакого отношения к РСУБД.
Вы в своей статье преподносите var как доказательство факта:
и это не соответствует реальности.
В var нет динамики. Ни в каком виде нет. Динамика - это когда что-то делается в процессе выполнения кода. Но var работает на этапе компиляции и только компиляции: статика в чистом виде.
Ваше предположение, что var появился в статически-типизированных языках под влиянием динамически-типизированных, абсолютно ошибочно. Между статическим выводом типов переменных в C#, Go, Java и полным отсутствием типов переменных в JavaScript, Python нет ничего общего.
Динамическая типизация, это когда одной и той же переменной можно присваивать значения совершенно разных типов. Вот если бы в Java можно было написать:
это была бы динамическая типизация.
Но нет, такое в Java невозможно. И конструкция:
создаёт переменную целого типа, которой можно присваивать только целочисленные значения.
Var - не динамическая типизация, а всё та же статическая. Вся разница только в том, что вместо явного прописывания имени типа используется тип значения инициализирующего выражения, однозначно определяемый в момент компиляции. Это называется "выведение типа": оно используется во многих статически типизированных языках и не имеет никакого отношения к языкам с динамической типизацией.
Вы относите слово "неизменяемый" к содержимому структуры данных, но применительно к ключам ассоциативного массива (в Python - "словаря") смотреть надо не на неизменяемость содержимого, а на неизменяемость того, что хэшируется и/или сравнивается операциями == и !=.
В случае объектов хэшируется/сравнивается не содержимое объектов, а никак не изменяемые указатели (адрес в памяти, id в таблице объектов и т.п.) этих объектов. Независимо от того, как меняются значения полей объекта, указатель и хэш, полученный из этого указателя, остаются неизменными. Аналогично с функциями.
Научная фантастика отражает состояние науки, технологии, общества... А в науке и технике до второй мировой войны не было задач, требующих цифровых вычислительных машин. Аналоговая логарифмическая линейка обеспечивала приемлемую для большинства инженерных расчётов точность, а сложные, для того времени, системы просчитывались с помощью аналоговых же моделей (как, например, проектировал свои здания Гауди). Там же, где требовались массовые математический вычисления, вполне хватало тривиальных табуляторов.
DEC погубила не система команд, а менеджеры. Именно концепции PDP-11 и VAX-11 стали основой и для 68k, и для 80386. Но в Motorola это сделали на много лет раньше, а Intel понадобилось несколько поколений процессоров, чтобы осознать всю бесперспективность своих оригинальных грабель.
На ДВК был компилятор, портированный в RT-11 из Unix. Он использовал r0 и r1 как базовые регистры для вычислений, регистры r2-r4 для оптимизации процесса вычислений: хранение промежуточных значений, указателей, переменных цикла; r5 использовался для границы стекового фрейма. А т.к. регистры универсальны, то r2-r4 использовались в любых процессорных командах сразу - без промежуточного копирования через другие регистры.
В MS-DOS использовался компилятор либо Borland, либо Microsoft: в разное время я использовал разные версии обеих фирм и какой точно это был компилятор, уже не вспомню.
Задача была не на сложение двух чисел, а на автоматизацию бухгалтерских задач - когда 1C ещё не было. И компилятор для PDP-11 выдавал куда более оптимизированный код. Дело не в скорости выполнения одной команды (я же специально указал, что тактовая частота процессора в ДВК была ниже), а в количестве этих команд. Компилятор для Intel генерировал ассемблерный код существенно большей длины - именно потому, что ему приходилось использовать узкоспециализированные регистры, привязанные к конкретным процессорным командам.
Именно потому я в своём исходном комментарии и написал:
Я не аппаратчик, а программист. И мне совсем не важно, какая именно физическая шина у процессора - важна именно разрядность регистров. Никто же не причисляет 8088, имеющий 8-битную физическую шину, к 8-битным процессорам.
И разве в 30386 физическая шина адреса была 32 битной? Да и 32-битная физическая шина данных была только у старших моделей.
Но куда важнее даже не разрядность процессоров, а наличие универсальных регистров и плоской адресации. ИМХО, именно отказ от принципов, на которых построена система команд в линейке 8086-80286, и переход к тому, что уже было у конкурентов, позволил создать процессор, для которого можно было написать компиляторы языков высокого уровня, эффективно оптимизирующие машинный код.
Из моего личного опыта: один и тот же C-код, производящий много целочисленных вычислений, на ДВК-3м2 (КМ1801ВМ3, 10 MHz) работал существенно быстрее, чем тот же самый код на IBM-PC/AT (20286, 12 MHz).
Например, Motorola 68k (надеюсь, построенный на нём Apple Macintosh вы считаете массовым компьютером?). Первое поколение (1979 год) имело 32-битную адресацию и 32-битную систему команд, реализуемую 16-битным ALU. Второе поколение (1984 год) - 32-адресация и 32-битное ALU.
Возможно, с точки зрения своей архитектуры Intel 80386 и был революционным - в проектировании микросхем я не разбираюсь. Но с точки зрения системы команд он был абсолютно зауряден: универсальные регистры и плоская 32-битная адресация - то, что в других процессорных архитектурах появилось намного раньше, чем в x86, и с позиции программиста 80386 - не "революция", а погоня за ушедшими вперёд конкурентами.
Поток демагогии, в средине которого под видом "осуждения эвристик" аккуратно подсовывают пропаганду лженауки. Что, полагаю, и является главной целью этой статьи.
P.S. Каждая современная "нейросеть" - это и есть эвристика в чистом виде.
"Ответы" убиты. В мае 2025 года под видом очередного "обновления" сервис ответов на вопросы был уничтожен и на его место помещена очередная типовая помойка "мнений" и "историй".
Чтобы научить программированию, учить надо совсем не написанию кода. И именно это автор статьи не понимает (или сознательно делает вид, что не понимает). А когда именно начинать учить, совершенно не важно. Более того, я выше прямым текстом говорю о том, что детские конструкторы куда лучше попыток навязать ребёнку программирование.
В моё время программированию начинали обучать в 17 лет - на первом курсе ВУЗа. И это никому не мешало становиться профессиональными программистами. Но, с другой стороны, познакомился с идеей программирования я за много лет до этого: в книге "Кибернетика без математики" (с мамонтом на обложке), не содержащей ни одной строчки программного кода. И прочитанная в подростковом возрасте книга "Принцесса или тигр" (которая совсем не про программирование) дала мне, как будущему программисту, несравнимо больше, чем любой самоучитель языка программирования.
Нет запроса на "программирование". Есть запрос на интересную ребёнку развивающую деятельность. И универсальный пластмассовый или металлический конструктор, позволяющий комбинировать детали как угодно, а не собирать единственную указанную в инструкции модель, даст для развития дошкольника несравнимо больше, чем попытки научить программировать.
Физику в школе начинают учить не тогда, когда учащийся дорастает до её понимания, а когда уровень математических знаний достигает минимально необходимого для понимания формул в учебнике физики. Но та же "Занимательная физика" Перельмана прекрасно воспринималась за несколько лет до начала преподавания физики в школе.
Если же говорить про программирование, то начинать обучать детей надо не с языков программирования (даже если это будет Scratch), а вот с такого: https://www.youtube.com/watch?v=cDA3_5982h8. И решать алгоритмические задачи дошкольник может - если эти задачи сформулированы на доступном дошкольнику уровне.
В позднесоветские времена в журнале "Знание-сила" (если память не подводит) была серия статей человека, обучавшего пятилеток математике. И, например, чтобы они поняли, что такое параллельный перенос, центральная и осевая симметрии, оказалось достаточно обычной детской мозаики.
В этом возрасте дети уже имеют хоть ограниченное второй сигнальной системой, но уже вполне полноценное абстрактное мышление. Из другой статьи того же автора: в задаче на классификацию дети не могли понять, как можно обозначить одним значком красный кубик и красный шарик (они же разные), но задача была решена, когда один из детей додумался (самостоятельно), что значок должен обозначать не предмет, а слово "красный". Т.е. дети уже умеют оперировать абстракциями - в виде слов "человеческого" языка.
Опять под видом "обучения программированию" пытаются впарить дрессировку в кодинге. Вместо обучения способам решения программистских задач (т.е. алгоритмам) заучивание и бездумное воспроизведение типового кода, кое-как решающего простые типовые задачи. Без малейшего понимая того, что любую задачу можно решить множеством разных способов и что работа квалифицированного программиста - не написание кода, а нахождение эффективного для данного конкретного случая алгоритма решения задачи.
А уж предлагать Python и JS, провоцирующие новичка писать говнокод и никак не дающие учащемуся оценить качество придуманного им способа решения задачи - это откровенная диверсия, направленная на сокращение числа профессиональных программистов.
P.S. Зато подобное "обучение" и подобные рекламные статьи обеспечивают российским "курсам программирования" (большинство из которых откровенно мошеннические) максимальную доходность. Что и объясняет нескончаемых поток таких материалов в рунете.
Я из того поколения разработчиков, которых учили, что качественно спроектированный язык программирования должен быть ортогональным. И это одна из причин, почему Go нравится мне намного больше большинства актуальных императивных языков программирования, в которых почти одно и то же можно сделать десятком разных способов - лишь бы замученный своей тяжёлой долей разработчик не надорвался, нажав при наборе кода на несколько клавиш больше.
Любой язык программирования - лишь вспомогательный инструмент для решения определённого круга задач. Разные задачи - разные инструменты. И не существует языка, одинаково подходящего для всего.
Тот же GC противопоказан только в системном программировании и в Real-Time. А в прикладном софте (которого несравнимо больше, чем системного софта и систем управления физическим процессами вместе взятых) GC - это безусловное увеличение надёжности кода.
Язык C - прекрасный инструмент для системного программирования. Но как язык прикладного программирования он обладает фатальным недостатком: вся ответственность перекладывается на кодера. В C-коде очень просто допустить ошибку и очень сложно её найти. Это инструмент для очень опытных разработчиков, но кодеры нижнего-среднего уровня мало того, что неизбежно будут ошибаться, так ещё и не смогут понять, что ошиблись. Microsoft по меньшей мере десятилетие активно вычищала баги из ядра Windows, написанного на C.
А ещё у C абсолютно ужасный синтаксис. Да, с появлением C++ многое в C причесали, но, например, кошмарное объявление типа как шаблона никуда не делось: https://habr.com/ru/articles/116255/. В этом отношении из всех известных мне C-style языков наиболее удачен Go (язык прикладного уровня) - в котором из C выбросили всё, что делает язык ненадёжным, и добавили ровно то, что реально необходимо, при этом максимально унифицировав и упростив синтаксис.
Да, при использовании компилируемых языков такое решение безусловно эффективнее. Но в интерпретируемых языках (к коим относится и Python) всё не столь однозначно.
Каждая операция в языке с динамической типизацией - это большие накладные расходы. И сравнение в цикле десяти пар строк длины 1 (в Python нет символов - только строки) может производиться намного дольше, чем сравнение двух строк длины 20. Накладные расходы на сам цикл, на курсор, на доступ к элементам строки, на проверку типов операндов в каждой операции сравнения с одной стороны и единственная операция сравнения с единственной проверкой типов операндов другой стороны.
Так что без реальных экспериментов на разных входных данных невозможно сказать, что именно в Python будет эффективнее: две операции (однократное создание среза длины N и однократное сравнение среза и исходной строки) над длинными строками, или (N/2)*5 операций (цикл, дополнительный курсор, доступ по индексу слева, доступ по индексу справа, сравнение двух строк длины 1) выполняемых в оптимизированном алгоритме.
Статья называется: "Очистка данных перед загрузкой в хранилище. Подробное руководство с техническими деталями". В реальности же в статье нет ни "подробного руководства", ни "технических деталей". И даже о том, как именно надо очищать данные до загрузки, в статье нет ни слова. Зато все три примера демонстрируют очистку данных после загрузки в хранилище. Причём очистка производится модификацией данных в таблице, из которой эти данные были прочитаны. Подобные запросы прекрасно смотрелись бы в статье "Как нельзя производить очистку данных", но предлагать такое как образец очистки...
Если статья рассчитана на "непрошаренных", то это не повод обещать в заголовке то, чего в статье ни в каком виде нет, и использовать заведомо низкокачественные примеры, никак не соответствующие теме статьи.
Если вы не рассматриваете примеры кода, то зачем упоминать языки программирования, библиотеки, программные пакеты? Вставленные только для того, чтобы эти названия присутствовали в тексте статьи - в окружении воды, не несущей никакой реальной информации.
P.S. Спасибо, что поправили теги и хабы.
Да, такая схема имеет место быть. Но в ней используют отдельные таблицы для хранения сырых и полуобработанных данных: каждая стадия обработки берт данные из одних таблиц и записывает в другие таблицы. И в этой схеме нет запросов, модифицирующих данные, записанные в исходных таблицах.
Хотелось бы понять, где именно в статье показано использование Python, R, ETL для "очистки данных"? Зачем эти абсолютно бессмысленные упоминания, выставление тегов и размещение в хабах, никак не относящихся к содержательной части статьи? Информационный мусор в надежде привлечь посетителей?
И где вообще объявленная в заголовке статьи "очистка перед загрузкой в хранилище"? Вся содержательная часть статьи (после отжима воды) - три SQL'ных костыля, применяемых к уже загруженным в хранилище данным и необходимых только потому, что структура реляционной базы данных разрабатывалась абсолютно некомпетентными "специалистами".
Первый запрос не нужен, т.к. недопущение дублей автоматически реализуется на уровне создания таблицы БД - добавлением уникальных индексов и/или триггеров.
Второй запрос не нужен, т.к. дефолтные значения для столбцов задаются, опять же, при создании таблицы. И если в столбце таблицы не должно быть NULL, такой столбец изначально создаётся с модификатором NOT NULL.
Но если два первых запроса ещё более-менее понятны (напахали со структурой, бывает, но в этом случае корректирующий запрос выполняется единственный раз - перед внесением правок в структуру таблиц), то третий SQL-запрос вызывает, мягко говоря, недоумение... Во первых, функция ISDATE существует только в MS SQL Server и не может иметь никакого отношения к хабу PostgreSQL (в котором статья находится в настоящий момент). Во вторых, если столбец даты имеет тип DATE, то весь этот запрос абсолютно бессмысленен, т.к. никак не меняет данные в таблице. Но если столбец для хранения даты имеет тип VARCHAR, то это даже не некомпетентность, а невежество создателя таблицы.
P.S. Сама идея "очищать данные", записанные в реляционную СУБД - показатель непонимания автором того, что такое РСУБД. Реляционные базы предназначены для уже "очищенных" и полностью структурированных данных и использовать их для "сырых" данных - это как пытаться спилить столетний дуб ножовкой по металлу. Для хранения "сырых" данных предназначены совсем другие хранилища, не имеющие никакого отношения к РСУБД.