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

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

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

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

Перлис

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

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

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

«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

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

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

Он вообще какой-то странный, этот ваш Перлис. http://ru.wikiquote.org/wiki/Алан_Перлис

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

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

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

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

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

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

тяжело писать на жабе, да?

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

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

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

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

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

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

Он лиспер.

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

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

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

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

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

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

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

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

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

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

Он лиспер.

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

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

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

Как-то сомнительно, чтобы речь шла просто о шаблонах/дженериках.

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

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

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

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

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

а чем отличается код от структур данных?

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

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

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

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

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

В твоем примере именно абстракция. 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.

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

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

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

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

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

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

Интересно, как организованы данные в генераторе случайных чисел, который может скрываться за 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».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Черт, поздно я тебя прочитал ;))

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Неа.

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

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

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

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

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

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

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

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

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

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

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

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

http://i.images.cdn.fotopedia.com/pchjansen-dgzCPWcXg3c-hd/People_around_the_...