«Правило» программирования от Роба Пайка

Что, действительно так?

Да, конечно. Хотя это правило сформулировал Брукс: «Representation is the essence of programming» («Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious»).

«Мифический человеко-месяц», классика.

Ага, плохо придуманные структуры == много говнокода.

Hashtable для всего == мало логикокода, быстро, стабильно, шелковисто.

полностью с ним согласен, хотя правил его не читал.

алгоритм логично просто приходит в голову, если твои структуры данных «правильные».

Кто только это правило не формулировал

«Bad programmers worry about the code. Good programmers worry about data structures and their relationships.» - Linus Torvalds

Пагугли «кэш френдли» и почему на совр. видухах нужно мапить структуры с вершинами и т.д. именно так, как нужно.

Да, так и есть. Один из наглядных примеров. newsbeuter. Отличный консольный rss-реадер, в котором полностью всё хранится в одной таблице в бд. В итоге через год использования с большим количеством подписок банальное открытие любой ленты начинает заметно тормозить. Про поиск или какую-то сортировку я уже молчу.

Это в целом правильно, только не правильна терминология. Надо делать упор на то, что структуры данных — это объекты. Естественно, если объект имеет интерфейс/протокол, удобный для решения конкретной задачи, это гораздо эффективней чем лепить лапшу из функций, которые будут имитировать суррогат такого поведения. Собственно, это та же самая идея, которая лежит в основе DSL

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

Можно ли привести примеры, в которых данные хорошо/плохо организованы?

типичным примером может служить файловая система unix. например, несмотря на громкие заявления «все есть файл», директория не является файлом. В теории, мы бы могли читать и писать в директорию напрямую, к примеру, не понадобилось бы отдельной сущности, такой как ls, можно было бы просто cat mydir, и тд. Много можно было бы делов короче наворочать. Это просто пример. Система становится от этого избыточной и неуклюжей. Кроме того, невозможно порождать свои собственные сущности, все что есть захардкорено.

Надо делать упор на то, что структуры данных — это объекты.

Нет, не надо.

Естественно, если объект имеет интерфейс/протокол, удобный для решения конкретной задачи, это гораздо эффективней чем лепить лапшу из функций, которые будут имитировать суррогат такого поведения.

Ты так говоришь, будто объект в данном контексте чем-то существенно отличается от структура+лапша функций для работы с этой структурой.

файловая система unix. например, несмотря на громкие заявления «все есть файл», директория не является файлом

С точки зрения структур данных - является. В ранних версиях и API доступа был как у обычного файла - это было неудобно и сделали специальный.

можно было бы просто cat mydir

Точно. И cat был бы методом каталога.

Это если у тебя есть хороший боевой опыт, иначе — будет говнокод.

По сабжу: да.

Задача: поиск чувака по ID. Пример плохой структуры для этого: неотсортированный по ID массив чуваков.

В FreeBSD вроде так и осталось.

Программы должны быть:

1. Простые.

2. Хорошо документированные.

3. С дружественным интерфейсом.

4. Эффективные (функциональные).

дую ктонить в теме спик рашн?

Hashtable для всего == мало логикокода, быстро, стабильно, шелковисто.

Переписывал программу с Perl на Си с целью увеличения производительности. Сначала переписал 1-в-1: так как в Perl основная структура — Hashtable, то у меня получилось аналогично. Получил ускорение в 3 раза.

Затем обратил внимание, что у многих таблиц можно заранее пронумеровать ключи. Заменил эти таблицы на массивы. Получил ускорение ещё в 30 раз.

Надо делать упор на то, что структуры данных — это объекты.

О, опять анонимоус.

Хорошее правило, но есть нюанс: не существует взаимнооднозначной связи между структурой данных и алгоритмом, её обслуживающим.

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

Сначала переписал 1-в-1: так как в Perl основная структура — Hashtable, то у меня получилось аналогично. Получил ускорение в 3 раза.

Забавно. Я как-то получил ускорение в 10 раз, сделав решительный переход Python -> Fortran. Интерпретаторы - зло.

не существует взаимнооднозначной связи между структурой данных и алгоритмом, её обслуживающим.

Вот это верно!!! Есть 3 сущности: функции, работающие с множеством типов, которые играют по определённым правилам; есть правила игры; есть типы и отдельно информация о том, как эти типы играют по нужным правилам.

Эту парадигму реализуют ряд языков программирования, как то Haskell (функции + классы типов + типы) или Rust (трейты вместо классов типов).

Есть менее удачно спроектированные языки, вроде объектно-ориентированных с их наследованием и интерфейсами. Там правила игры приклеены к типам. ООП-быдло подумало, что «полиморфный» относится к типам, поэтому и приклеило правила к типам; когда как тип не может быть полиморфным или не полиморфным, полиморфизм — в коде, могущим работать с разными типами.

ООПе-подход плодит лишние проблемы: вот у нас есть класс и мы не можем менять его определение. Как же нам сказать, что этот класс реализует интерфейс?

Интерпретаторы - зло.

Для прототипирования - добро.