Об вещах, исправляющих мозг программистам

[metaclass]

По опыту общения с программистами всяких клиентов, НИИ и сторонних систем появилось мнение, ЧТО им всем нужно преподавать и спрашивать на экзаменах до тех пор, пока не поймут, для вправления мозгов.

Нужны всего лишь две вещи: реляционная теория и основы функционального программирования. Причем желательно как можно более обобщенно,а не на частных случаях.
Первое хорошо вправляет мозг в плане использования некошерных данных (типа "а вот тут у нас число в виде строки" или "поля должны адресоваться по номеру или позиции в файле")
А второе вправит мозг в плане нормальной реализации систем в виде слабо связанных модулей, а не "все в одном" и приучит не делать тупые неявные зависимости. А если язык со строгой типизацией - то еще и приучит не хранить в одном поле дату/время/пол домашнего животного/фазу луны/возраст бабушки.

Comments

[lionet.livejournal.com]

А что это исправит? Какую проблему решаем?

[metaclass.livejournal.com]

Проблема в том, что люди не понимают, о чем им говорят и пишут в документации - нету такой понятийной базы в голове, напрочь.
Ну и программы пишут соответственного качества.

[lionet.livejournal.com]

А зачем их писать надлежащего качества? У нас уже давно attention economy (английский термин для копроэкономики) — еду создавать может один процент населения, остальное занимается креативным проведением времени: кто на лыжах катается, кто — по девочкам, а кто и программист.

Смысла в этой деятельности с гулькин нос, оптимизация ничего ценного не даёт.

А вот от пессимизации проектов и отношений возникают интересные теории. Теория хаоса например.

[vp.livejournal.com]

отлично :)

[raydac.livejournal.com]

+1000
трабла в деградации программеров не в том что они деградируют, а в том что окружающая среда требует от них деградации

[paranoekk.livejournal.com]

Так иди преподавать :)

[sergiej.livejournal.com]

Я уже говорил, в CSV поля адресуются по номеру в файле. CSV некошерен?

[metaclass.livejournal.com]

CSV адресуется по имени поля, список которых идет первой строкой. Адресовать по номеру - это отгребать несчитанное количество геморроя каждый раз, когда кто-нибудь что-нибудь перепутает в порядке или количестве полей.
А CSV без имен полей некошерен, ибо не соответствует определению отношения в реляционной модели. Поэтому я и говорю, что нужно всех заставить ее учить до просветления.

[vp.livejournal.com]

Ну вот видиш, в приведенном РФЦ вообще слабо сказано про первую строку с именами полей. Так что ахтунг полный :)

[metaclass.livejournal.com]

Если стандарт придуман неадекватами, не знающими теорию - он идет в лес и вместо этого делается нестандартно но теоретически правильно. Тем более что стандарт не запрещает делать строку с именами, соответственно, лучше делать с ней, чем без нее.

[sergiej.livejournal.com]

:)
то есть описание последовательности полей в начале любого файла в котором данные адресуются по последовательности делает файл кошерным?

[wizzard]

В реляционную модель далеко не всё ложится. Или ложится, но при этом производительность в доску падает.

Видео, например. Различные естественно иерархические структуры вроде программного кода, модулей и т.д.

Кроме того, почему-то строго нормализованные БД выливаются в десяток-другой вложенных подзапросов на построение репорта.

А еще реляционную модель тяжко эволюционировать, NOT NULL и ключи со временем (с приходом сторонних датасетов) отмирают, и база превращается в графоподобную ересь вроде RDF, что есть еще большее уродство.

Единственный выход - это обьектно-ориентированные БД, кластеризованные на манер map-reduce семантики. И кэши, кэши, кэши. И универсальные скоростные сериализаторы, компилирующиеся из описаний данных в какой-нибудь C#, а лучше в C.

Потому что всё хорошо до тех пор, пока система является активной, а не реактивной.

Особенный маразм - это те самые научные датасеты, обьем огромный, а качество никакое.

---

А вот функциональное программирование - это есть хорошо. И дискретная математика, и теория графов.

[metaclass.livejournal.com]

Да, эволюция в реляционных БД это тяжкий кошмар. Но я предполагаю, что она везде будет кошмаром, как только возникают две разные сущности - сохраненный образ объекта и его представление в коде. Единственный более-менее представимый вариант - это при изменении структуры объекта в программе принуждать разработчика писать функцию преобразования "старых" объектов в "новые".