Стиль мы хотя бы можем условно разделять по замыслу автора. Если внутренности скрыты и есть ресурсы для построения иного физического плана выполнения, чем следует из написанного, говорим о декларативности

Сюда же можно добавить DSEL поверх Julia. Этот язык будет, скорее декларативным, чем императивным. Если только это не прямой калькулятор

Что такое DSEL?

Domain-specific embedded language

"Если внутренности скрыты" — декларативность ни разу не про оптимизации. Это как раз внешнее представление. Внутри всегда последовательность машинных команд, она не имеет отношения к стилю собственно текста программы. Хинт тут такой: если "оператор" (типа присваивания), то это императивный стиль, а если "объявление" (типа объявление переменной или указание заданного соотношения величин, которое должно соблюдаться в ходе всей программы), то декларативный.

Позволяет использовать ресурсы языка-носителя

Сама Julia говорит о мультипарадигмальности, но более современно, без понятия "декларативности": It is multi-paradigm, combining features of imperative, functional, and object-​oriented programming.

Это мы так дойдём до определения состояния. Если порядок изменения состояний задан - императивный подход. Не задан до финального этапа - декларативный.

В декларативном подходе нет "состояния" вообще (то есть не "не задан", а вообще нет). Указываются соотношения между сущностями, они должны соблюдаться. А порядка изменения каких—то состояний нет. Нет состояний, нету порядка выполнения )))

Но мы же говорим об императивном языке в своей основе, на котором реализованы множественные парадигмы. Раз язык императивен, то состояния есть

Путаются языки, стили и идея компиляции (в ходе компилирования меняется язык: скажем, декларативный чисто функциональный язык становится чисто императивным машинным языком).

Из-за этой постоянной путаницы люди отказались от противопоставления императивности (последовательности императивов-команд) и декларативности (тут куча всего разного, связанного с "объявлением зависимостей").

Поэтому мы воспроизводим споры начала 80х годов прошлого века, когда понятие декларативности вышло из обихода в силу его мутности (а понятие императивности осталось, ибо машинный язык пока есть всегда. Вот с квантовым программированием будет по другому!).

Вообще насколько я понимаю у декларативности много общего с абстракцией. Как мне кажется если исходить из того, что обычно пишут что декларативный подход это про то, что нужно сделать, а императивный это про то, как нужно сделать, то перегрузка методов в Julia вполне себе декларативный механизм.
Т.е. например, size(a) - декларатавный метод "получить размер a чтобы из себя a не представляло", а конкретные size(a::Vector), size(a::DataFrame) и т.д. это императивные конкретные реализации.
Возможно, конечно, я не очень правильно это разделение понимаю и Анатолий меня поправит.

Мммм...
Я правильно понимаю, что с точки зрения обывателя, лучше об этом различии вообще не думать, так как в обычной жизни оно интереса не представляет?

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

Спасибо.

Вчера спрашивали про пример как работать с CSV с помощью DataPipes.jl

Я тут небольшой гист накидал, вышло достаточно просто, нет даже необходимости преобразовывать в rowtable

https://gist.github.com/Arkoniak/595594a55b4d439b4827a0c2831eb2d5

Касательно того, куда такие вещи добавлять.

Так как я свои пакеты держу на гитхабе, то там обычно настроен Documenter и поэтому можно писать достаточно пространную документацию при желании, просто разбивать её на разные разделы, в зависимости от значения.

В случаях подобных этому я делаю просто отдельную секцию "Examples of usage" в которых по сути делаю туториалы на то, как пакет предполагается использовать в разных ситуациях. Разумеется всего на свете покрыть невозможно, но это потенциально может давать какие-то стартовые точки от которых дальше пользователь может уже отталкиваться и делать что-то свое.

В этом смысле нет никакого вреда в небольшом примере, который показывает как можно использовать пакет совместно с CSV.jl.

Кстати, когда я начал делать этот пример, то задумался, что было бы интересно посмотреть как можно делать операцию обратную к уплощению данных (data flattening).

То есть представьте, что есть две таблицы

id, name
1, John
2, George

и

person_id, age, weight
1, 10, 15
1, 15, 35
2, 10, 16
2, 15, 40

И мы бы хотели свернуть их во вложенную таблицу, типа такого

id, name, measurements
1, John, [(age = 10, weight = 15), (age = 15, weight = 35)]
2, George, [(age = 10, weight = 16), (age = 15, weight = 40)]