LINUX.ORG.RU

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

 ,


1

4

Известный товарищ Роб Пайк сформулировал не менее известные правила, которые вроде должны помогать в программировании. Наиболее загадочным для меня представляется последнее: «Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.»

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

★★★

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

Да, конечно. Хотя это правило сформулировал Брукс: «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»).

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

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 2)

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

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

unt1tled ★★★★ ()

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

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

umren ★★★★★ ()

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

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

netrino ()

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

slackwarrior ★★★★★ ()

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

shell-script ★★★★★ ()

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

portquest2016 ()
Ответ на: комментарий от portquest2016

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

portquest2016 ()

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

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

portquest2016 ()
Ответ на: комментарий от portquest2016

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

Нет, не надо.

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

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

Waterlaz ★★★★ ()
Ответ на: комментарий от portquest2016

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

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

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

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

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от umren

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

deep-purple ★★★★★ ()

По сабжу: да.

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

hlamotron ()

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

1. Простые.

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

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

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

anonymous ()

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

buratino ★★★★★ ()
Ответ на: комментарий от unt1tled

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

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

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

monk ★★★★★ ()
Ответ на: комментарий от portquest2016

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

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

unlog1c ★★★ ()

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

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

shkolnick-kun ★★★★ ()
Ответ на: комментарий от monk

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

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

hotpil ★★★ ()
Ответ на: комментарий от shkolnick-kun

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

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

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

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

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

anonymous ()
Ответ на: комментарий от hotpil

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

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

Hertz ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.