LINUX.ORG.RU

Алан Перлис «Лучше иметь сто функций, работающих с одной структурой данных...»

 


1

3

Широко известна фраза Алана Перлиса «Лучше иметь сто функций, работающих с одной структурой данных, чем десять функций, работающих с десятью структурами данных».

Дык это. Почему?

предположение: у него функциональщина головного мозга

при функциональщине головного мозга поциент ищет способ свести элементы предметной области к уже известным структурам данных, и потом скормить их уже известным алгоритмам

stevejobs ★★★★☆
()

абсолютно весь код абсолютно плоский и абсолютно простой и понятный. вероятность ошибиться крайне мала

redixin ★★★★
()

Перлис

Вот как напишешь 100 однострочников, тогда поймешь

anonymous
()

я так понимаю, эта структура тогда будет иметь 100500 полей и не помещаться в кэш процессора? :)

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

при функциональщине головного мозга поциент ищет способ свести элементы предметной области к уже известным структурам данных, и потом скормить их уже известным алгоритмам

«I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships.» (c) Linus Torvalds

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

я не программист, но допустим у меня есть буфер длиной 512 байт.
чтоб его обработать я могу порезать на 10 кусочков и в каждой функции использовать свои создания массивов из буфера, свои переменные и свои смещения при чтении, свои циклы
на это я потрачу примерно время на создание новых буферов и массивов - это ((9000ns*10)+(900ns*10))+время на создание переменных. добавляем сюда ~100 объектов которые больше не нужны и нужно отработать GB.
но я не программист и Cи головного мозга мне не понять.

system-root ★★★★★
()

Спроси у Алана Перлиса, че ты к нам пристал?

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

Ох как я понимаю это. Код можно доработать. А вот, скажем, сделать миграцию большой базы это проблема. Большая проблема.

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

И ещё, продолжение той же идеи:

«Smart data structures and dumb code works a lot better than the other way around.» — Eric Raymond

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

Широко известна фраза Алана Перлиса «Лучше иметь сто функций, работающих с одной структурой данных, чем десять функций, работающих с десятью структурами данных».

потому-что в 10 структурах ты запутаешься быстрее, чем в одной.

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

Во многих местах он КО и также во многих - разрыв шаблона О_о

это субъективно. Объективно — у тебя шаблон кривой, вот его и рвёт.

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

Нет, разрыв шаблона у него, если он познал подобный дзен:

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

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

Он лиспер.

Суть в том что ольшая абстракция структуры данных позволяет больше абстрагировать код. Структура в данном случае - совсем не сишный struct со стомильенами полями. Пример, надо:
1. читать файл со строками, фильтровать, трасформировать.
2. брать список строк, фильтровать, трансформировать.
3. брать массив массив байтов, фильтровать, трансформировать.

Можно создать три структуры FileOfStrings, ListOfStrings, ArrayOfBytes и на каждый создать по две специализированных функции - filter, map.

А можно создать одну абстрактную структуру данных - Iterable[T] с абстрактным свойством итерируемо, и породить всего две обобощенныё функции. А точнее хоть стопицот обобщенных функций для всего что итерируемо - например мы уже умели это делать для списков строк, и поэтому обработка файла строк это всего лишь представление файла строк в виде абстрактной известной структуры, что позволяет использовать уже существующие функции.

Подобный подход собственно очевидет при создании библиотек коллекций - переходы к абстрагированию в структурах с целью увеличть количество используемых функций. Грубо говоря реализуете интерфейс «Список» для чего хотите - и получаете все все 100500 функций работающих со списками из каропки.

Все правильно сказал.

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

Нет, разрыв шаблона у него, если он познал подобный дзен:

Чтобы понять программу, необходимо отождествить себя и с машиной, и с программой.

То, что для одного человека константа, для другого — переменная.

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

а для меня все три заключения — К.О.

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

Он лиспер.

он программист. Для сишечки это тоже верно.

А можно создать одну абстрактную структуру данных - Iterable[T] с абстрактным свойством итерируемо, и породить всего две обобощенныё функции.

для этого не обязательно быть лиспером. В C/C++ такой подход тоже более удобен.

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

он программист. Для сишечки это тоже верно.

Он академик, а не программист. И к тому же RIP с 1990 года.

Я уж не говорю о том, что академики вроде него (да ещё в 80-е) крупных проектов никогда не видели и судить о них не могут вообще, какой бы у них ни был индекс цитирования. Ну и наконец, лисперы вечно грезят о каких-нибудь DSL с особым «удобным» синтаксисом, а ООП просто позволяет писать аналогично DSL так, чтобы любой другой программист мог понять независимо от пола и национальности. DSL переводит код в предметную область, ООП переводит структуры данных предметную область.

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

Я просто говорю кто такой Перлись а не что это только в лиспе возможно.

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

Не только о шаблонах. В моем примере абстракция итерируемой структуры и абстракция типа через генерики. Просто пример. Суть в том что к struct и полям это отношения не имеет Перлис в данном случае под структурой понимал структуру данных, а не «record».

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

Он академик, а не программист. И к тому же RIP с 1990 года.

мёртвый академик не может быть программистом?

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

да, мир не совершенен...

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

В твоем примере именно абстракция. Iterable[T] - это вообще не структура данных.

Только на очень простом уровне абстракции это не структура данных:)

In computer science, a data structure is a particular way of storing and organizing data.

Abstract Data Structure - in computer science, an abstract data type (ADT) is a mathematical model for a certain class of data structures that have similar behavior.

An abstract data type is defined indirectly, only by the operations that may be performed on it and by mathematical constraints on the effects (and possibly cost) of those operations.

Что я и сделал через Iterable.

Пример - характеристический способ описания множества. Можно создать Set положить туда 1,2,3 и будет множество из этих трех элементов. А можно с тем же интерфейсом задать множество чисто описанием {x | x >= 1, x <= 3 }, и вести себя точно так же как любая другая фигня имеющая интерфейс set.

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

In computer science, a data structure is a particular way of storing and organizing data.

В Iterable[T] нет ничего particular насчет storing или даже organizing данных. Ну то есть совсем ничего, и именно в этом его полезность.

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

В Iterable[T] нет ничего particular насчет storing или даже organizing данных.

На счет сторинг ичего - а вот на счет органайзингг да. Он говорит что данные организованы так что их можно просмотреть последовательно.

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

Я думаю, «организованы» читается: «как данные выглядят для внешнего наблюдателя». Iterable[T] выглядит как однонаправленный поток данных. List[T] выглядит как двухсвязный список. BinaryTree[T] выглядит как дерево. Что там внутри — это проблемы того, что внутри.

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

Интересно, как организованы данные в генераторе случайных чисел, который может скрываться за Iterable[T].

Внутренее строение интересно только в определенном приближении. В общем случае интересно «abstract data type is defined indirectly, only by the operations that may be performed on it and by mathematical constraints on the effects (and possibly cost) of those operations».

r ★★★★★
()

Программы на Лиспе населяют библиотеки функциями, которые оказываются настолько полезными, что они переживают породившие их приложения. [...] В Паскале обилие объявляемых структур данных ведет к специализации функций, которая сдерживает и наказывает случайное взаимодействие между ними. Лучше иметь 100 функций, которые работают с одной структурой данных, чем 10 функций, работающих с 10 структурами.

Речь о том, что 1 обобщенная структура данных полезнее 10 ее специализированных вариантов, т.к. будет больше возможностей для повторного использования.

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

кажется то что ты написал не имеет отношение к функциональщине? Просто здравый смысл - если вместо хитрого алгоритма можно использовать qsort или дерево ;)

OxiD ★★★★
()

Дык это. Почему?

Потому, что меньше шансов вызвать функцию с «не той» структурой. Очевидно же. И не надо помнить, что с чем вызывается - везде одна структура. Все порсто.

no-such-file ★★★★★
()
Ответ на: комментарий от OxiD

Имеет-имеет.

В ООП принято мыслить паттернами и делать переиспользование на уровне паттернов и объектов (в крайнем случае - упакованных на уровне библиотек, но это упаковка чисто ООПшная - мы засунем компоненты в консервную банку, а когда захочется жрать - достанем оттуда и сожрем). Это позволяет обходиться без жирной «стандартной библиотеки», и каждый раз писать новый узкоспециализированный код с новыми узкоспециализированными стуктурами данных, идеально подходящий именно под конкретную задачу. Паттерн на паттерне паттерном погоняет. Не знаешь конвенций, не знаешь паттернов, не умеешь руками писать сортировки - не сделаешь вообще ничего.

В функциональщине напротив нужно иметь жирную библиотеку с готовой машинерией, умеющей обрабатывать стандартные структуры данных стандартным способом. И задача программиста строится в адаптации СВОИХ структур данных ко СТАНДАРТНЫМ. Когда нестандартная задача сведена к стандартным структурам, подключается «жирный фреймворк» который сам всё делает за программиста.

Мне кажется, что ООП и функциональщина равноправны и равноважны из-за того, что идеально соответствуют разным БАЗОВЫМ способам мышления. ООП для тех, кто ненавидит исследования - не нужно изучать вообще ничего, изучил 3 операции - и вперед писать велосипеды! Например, Стив Возняк, который это называет главной причиной своего успеха. Функциональщина подходит для тех, кто любит изучать и разбираться в уже существующем, и потом юзать «всю мощь» готовых тулзов для конкретных минималистичных инженерных решений.

Я, например, ненавижу исследования. И функциональные платформы рассматриваю не как готовую реальную платформу для готового реального использования, а как метод самообразования, повышающий мое умение думать, кругозор, набор паттернов если хочешь. В случае чего я не возьму стандартную библиотеку Скалы, а заново напишу какую-то минимальную фичу из нее конкретно под нужную задачу на каком-нибудь кодогенераторе (возможно, самописном -)

stevejobs ★★★★☆
()
Ответ на: комментарий от OxiD

Это ж хипстер. У них все, что не ООП, то функциональщина. В модных журнальчиках сейчас ажиотаж на функциональщину.

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

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

Вообще я знаю разработчиков которые любят паттерны - и у меня такое ощущение что для них главное - применить паттерн ;) Это становится самоцелью, даже если есть простое и красивое решение на поверхности.

И так же я знаю что когда ставится задача часто рассуждают в тех терминах в которых задачу поставил менеджер (или кто-то еще), и решается она в тех же самых терминах. Часто среди них нет ни сортировки, ни конечных автоматов, ни каких-либо других стандартных структур - функций.

Это приводит к тому что задача решается построением монструозного алгоритма, с монструозными структурами данных. Из-за его монструозности его начинают строить паттернами.

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

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

Еще кажется что использование паттернов о котором ты пишешь (которые погоняют) это тоже в каком-то смысле переиспользование стандартных возможностей же.

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

В ООП принято
В функциональщине напротив

Вы прослушали радиопередчу «сказки и легенды мира программирования».

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

Еще кажется что использование паттернов о котором ты пишешь (которые погоняют) это тоже в каком-то смысле переиспользование стандартных возможностей же.

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

Во-первых, то, что находится только в твоей голове, удобно продавать. Классический пример: делаем какую-то объектную либу, выкладываем в опенсорц, и потом продаем тренинги по ее использованию. Или идем работать technology advocate в контору, которая на нее подсела. И тут уже не важно, программирование это или психоанализ, у нас просто есть некое тайное знание, которое заставляет шестеренки вертеться. Всё это можно было бы вербализовать на уровне фреймворка, но зачем? У нас-то всё работает, потому что это МЫ написали эту либу, а все остальные (у которых не работает) - могут заплатить нам бабла. И даже если кто-то пойдет писать «расширенное апи», он всё равно не вербализует знания автора, если уж сам автор не может/не захотел этого делать.

Во-вторых, с позиции пользователя, если либу придумали не мы, то ее придется изучать. Загружать в голову какой-то хлам. Сейчас всяких либ и фреймворков 100500, если начать их все изучать - короткий путь в дурку. Если предсавить «свой мозг» и «чужое апи» как какие-то хранилища информации, то скорость доступа до «своего мозга» гораздо быстрее.

Это ж хипстер. У них все, что не ООП, то функциональщина. В модных журнальчиках сейчас ажиотаж на функциональщину.

Именно, функциональщина - это «тайное знание» из первого пункта, которое сейчас популярно и выгодно продавать. И его нужно рекламировать, для этого есть соответствующие места типа журнальчиков. Кто скажет, что за 5 минут разобрался в хацкеле и ему не нужно никаких учителей - пусть первый бросит в меня шоколадку.

Всё посоны, некогда писать, только что подобрал на свалке винтажные советские очки, еду на Площадь Ленина фигачить лук

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

Именно, функциональщина - это «тайное знание» из первого пункта, которое сейчас популярно и выгодно продавать.

В принципе логично. Молодую и неопытную лохоIT-индустрию уже кинули на бабки на ООП-лохотроне. Теперь самое время повторить успех, впрарив новый функционал-лохотрон под видом борьбы с ООП-лохотроном.

anonymous
()

Дык это. Почему?

Попробуем поиграть словами.

«Лучше иметь сто браузеров, работающих с одной разметкой HTML, чем десять браузеров, работающих с десятью разными разметками HTML».

«Лучше иметь сто офисных пакетов, работающих с форматом ODF, чем десять офисных пакетов, работающих с десятью разными форматами».

Следующий абзац я хотел написать про 100 дистрибутивов и одну структуру /etc и понял что это фейл

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

Тебе шапочка из фольги не жмет?

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

BinaryTree[T] выглядит как дерево. Что там внутри — это проблемы того, что внутри.

Если BinaryTree не выглядит внутри как двоичное дерево, то о чем еще можно оворить...

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

Вот и не путай структуры данных с абстрактными типами данных. Это разные вещи. Iterable твой можно назвать абстрактным типом данных, но никак не структурой данных.

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

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

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

Неа. Что именно ты называешь «связным списком»? Это не более чем некоторые свойства структуры. Каким образом ты можешь формально определить эти свойства? Только через тип и характеристики операций.

Пример - в сях связный список это что-то типа struct el { void * value, el * next }. В эралнге это пара [ V | Rest ]. В скале это case class El[T](value:T, next: El[T]). Как ты видишь с точки зрения _реализации_ это разные вещи. Общего у них только _характеристики_. А характеристики и есть то самое что определяет структуру данных. На определенном уровне размышления достаточно представления linked list как [V|-]-->[V|-]-->null. Однако такой рисуночек - это всего лишь графическая «реализация» некоего набора свойств, которе доступны для исследования только через операции над структурой.

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

Неа.

Что неа? Это по определению так. Открой любой букварь по алгоритмам и структурам данных.

Что именно ты называешь «связным списком»?

Структура данных, состоящая из узлов, каждый из которых содержит данные и ссылку на следующий узел(если список односвязный).

в сях связный список это что-то типа struct el { void * value, el * next }. В эралнге это пара [ V | Rest ]. В скале это case class El[T](value:T, next: El[T]). Как ты видишь с точки зрения _реализации_ это разные вещи.

С точки зрения реализация - это одинаковые вещи. Мелкие отличия обусловлены разницей в абстрактной машине языков и не более. Главное, что мы содержим данные и ссылку на следующий элемент.

С другой стороны, об абстрактном типе данных «список», ты не можешь сказать, что и как он хранит и из чего состоит. У тебя есть лишь набор операций, а массив там внутри или список связный на данном уровне тебе не интересно.

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

Что неа? Это по определению так. Открой любой букварь
букварь

I rest my case.
В том то и дело - что на подобном уровне абстракции - это разве что для букваря. А взрослые определения я привел выше.

Структура данных, состоящая из узлов, каждый из которых содержит данные и ссылку на следующий узел

Есть такой себе xor linked list. Узлы в нем не содержат в ноде ссылку на следующий узел.

С другой стороны, об абстрактном типе данных «список», ты не можешь сказать, что и как он хранит и из чего состоит.

Это потому что ты определил абстрактный тип данных «список» и набор операций над _любым_ списком. А если ты начнешь уточнять характеристики операций - то тут то и появятся разные списки. Например список (все тот же) имеющий сложность доступа к элементу O(1). Или список имеющий сложность вставки в голову O(1). И вот тут то и начинаются интересности.

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