ооп, иерархии, подмножества

Я из подобных языков знаю только js, и только он используется активно. Подобное возможно на селфе, смолтоке, ранних лиспах, возможно IO, возможно Пролог. А так, свои костыли только.

Нужен язык, который способен обобщать, а не описывать.

Что именно ты хочешь «обощать»? Программирование сводится не к обобщению, а к специализации: к выделению свойств и закономерностей из хаоса и неопределенности.

И ты, кстати, неправильно написал «расширить» прямоугольник до квадрата. На самом деле сузить.

Слово extend по отношению к типам — жудкий яд, массово поражающий мозг програмистов.

И ты, кстати, неправильно написал «расширить» прямоугольник до квадрата. На самом деле сузить.

Вы правы, хотел исправить, не успел, но не суть.

Слово extend по отношению к типам — жудкий яд, массово поражающий мозг програмистов.

Тут типы не причем

Программирование сводится не к обобщению, а к специализации: к выделению свойств и закономерностей из хаоса и неопределенности.

Это скорей философский вопрос. Не готов обсуждать.

Тут типы не причем

Типы как раз при чем. Типы суть множества. А неверные слова провоцируют неверное понимание, что мы массово и видим обычно. Можно конечно стул называть столом, и все привыкнут постепенно. Но зачем?

что пытается все классифицировать

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

стул называть столом, и все привыкнут постепенно

И то и другое относится к мебели. Можешь называть это типом. если угодно. Думаю, наша цель - заставить машину понимать это без прямых указаний.

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

Нет не нужно, т.к. это не эффективно. А не эффективно, потому что ничего в мире не устроено таким образом - это попросту неверная модель.

Нет не нужно, т.к. это не эффективно. А не эффективно, потому что ничего в мире не устроено таким образом - это попросту неверная модель.

Это действительно может быть неэффективно с точки зрения скорости выполнения кода, но не скорости разработки. А устройство мира каждый видит по своему наверное, не буду здесь спорить.

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

Далеко ходить не надо, возьмем табурет. Я вижу, что табурет состоит из N ножек (обычно 4 или 3), крышки и гвоздей/шурупов/клея которыми соединяются ножки и крышка - готовая модель табурета.

Вот вам задачка на иное видение мира: опишите табурет с помощью классификации от простого к сложному или наоборот.

но не скорости разработки

Для моего видения табурета нужно 3 класса: ножка, крышка, гвоздь и правило их комбинирования. А для вашего?

Для моего видения табурета нужно 3 класса: ножка, крышка, гвоздь и правило их комбинирования. А для вашего?

Здесь может быть огромное количество классов, в зависимости от контекста. Мебель, промышленное изделие, дерево, вещь на которую можно присесть, оружие которым можно треснуть в лоб..., можно продолжать до бесконечности.

Здесь может быть огромное количество классов

можно продолжать до бесконечности

Да. Разработку в таком стиле можно продолжать до бесконечности.

нужно хотя бы иметь возможность выразить табуретку разными способами, кому как удобней

Я же говорю, каждому свое. Могу, кстати, привести любопытный пример из жизни. Когда-то я работал электриком на полставки в одном учреждении. И вот когда я наблатыкался, я стал на работу ходить с одними пассатижами, и мне хватало. А почему? Потому что пассатижи - это только на первый взгляд пассатижи. А если присмотреться - это молоток, кусачки, нож для разделки кабелей, плоскогибцы, гаечный ключ, шлямбур, и даже указатель напряжения. Так какой же класс у пассатиж? Как-то так. Но я не профи в программировании, я могу себе это позволить. Если Вы работаете в конторе, ест-нно Вам никто не даст программировать в таком стиле. Сейчас нужно классифицировать, так как Вы сказали, да.

возможность выразить табуретку разными способами, кому как удобней

Для не осиливших таблицу умножения, сложение удобнее - так себе аргумент.

стал на работу ходить с одними пассатижами, и мне хватало

Ну нет, еще же отвертка нужна.

Если Вы работаете в конторе, ест-нно Вам никто не даст программировать в таком стиле.

В конторе, да, пишешь как требуют и не жужжишь, лишь бы зарплату платили.

Для не осиливших таблицу умножения, сложение удобнее - так себе аргумент.

Моя двоюродная сестра всю жизнь преподет математику в школе. Хорошо училась, золотая медалистка etc. - в итоге последний х без соли, как и все учителя в провинции. Скажи мне, какой профит в ее таблице умножения? К слову, я однажды провел эксперимент, попытался имплементировать арифметику без использования каких либо примитивов языка, на голом месте. И сделал для себя потрясающий вывод: мы не знаем, на самом деле, что такое арифметические операции, по сути. Все что мы какбы знаем, ограничено зубрежкой. Если хочеш взорвать себе мозг, сделай то жае самое, это изменит твое отношение к математике, я гарантирую.

Ну нет, еще же отвертка нужна.

Пассатижи в большинстве случаев заменяют отвертку.

Все что мы какбы знаем, ограничено зубрежкой

Есть такая штука - общая алгебра.

Пассатижи в большинстве случаев заменяют отвертку.

Редко. Чаще всего всякая электрофурнитура бывает прикручена мелкими винтиками «на 3» с маленькой круглой головкой, которую пассатижами хрен захватишь, или вовсе головка «в потай» - тут поможет только отвертка. Другой вариант использования отвертки - подковырнуть какую-нибудь крышечку на защелках, например у распаечной коробки или «ореха». В общем - без отвертки никак нельзя.

Есть такая штука - общая алгебра.

Да я не о том. Я говорю что, мы знаем математику, на обывательском уровне, как и учителя и даже профи, расширяются в сторону количества но не качества. Трудность программиста в этом плане в том что он должен понимать это на качественно ином уровне, как будто он понимает, это как «понимала бы машина», как формализм, выраженный на физическом уровне. Например операция деления, на бытовом уровне, это простейшая операция, а когда пишешь на машине, понимаешь, что она нетривиальна, в отличии от сложения и умножения, которые есть по сути вариациями конкатенации, и ее комбинаций, возможно даже противоречива.

Редко. Чаще всего

Ну, не надо понимать все так буквально. Конечно были случаи. Но факт остается фактом, в 95% случаев я обходился пассатижами.

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

Ну вы таки погуглите на тему общей алгебры и теории чисел.

Ну вы таки погуглите на тему общей алгебры и теории чисел.

Спасибо, посмотрю, посмотрю. Но я убежден что теория никогда не заменит практику, если вообще нужна. Практика нам дает возможность строить свои, контекстозависимые, правильные абстракции. Невозможно, к примеру, стать, хорошим боксером, изучив теорию бокса. Надо стоять на ринге и получать по е..., Кстати, в MIT, я слышал, придерживались именно этой точки зрения, и выпускали лучших инженеров в мире.

с чего ты решил, что типы - это множества? Это не так, по крайней мере в языках, которые используют

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

умножение выражается через сложение. а множества, модели и классы - просто пересекаются(?). Я вообще хз что такое «классы». Например, в моей в «ершов, палютин, матлогика», модель == множество, набор операций и набор выделенных элементов (плюс механика оперирования моделями, типа изоморфизма, гомоморфизма, изоморфного вложения итп). Каким образом выразить механику моделей на «классах»? Бытовая интуиция подсказывает, что раз классы УЖЕ загнаны в рамки «правил ООП» (которые не енфорсятся конпелятором, но это ничего не значит - это не спасет от анальной кары коллег за грубые нарушения Lyskov substitution), то добиться равенства не получится.

Вот значит и нужен такой язык, который позволит описать тип квадрата как type Square a is Rectangle a where width(a) == height(a)

Common Lisp:

(deftype square
  `(and rectangle
        (satisfies (lambda (x) (= (width x) (height x))))))

Есть красивая теория:

http://common-lisp.net/~frideau/lil-ilc2012/lil-ilc2012.html#(part._.Bootstra...

Идея в том, что наследоваться должны не объекты, а интерфейсы.

Например так:

(define-interface <hash-table>
    (<map-join-from-fold-left-insert>
     <map-join/list-from-join>
     <map-update-key-from-lookup-insert-drop>
     <map-map/2-from-fold-left-lookup-insert-drop>
     <map>)
...)

Только тогда приходится второй параметр передавать в методы.

Или из (печального) опыта: если мы думаем «моделями», то если есть два объекта, их модели равны тогда, когда есть взаимооднозначное преобразование, превращающее одну модель в другую. С другой стороны, в Java строка типа if MyObject.getClass.isAssignableFrom(java.lang.System) всего лишь проверяет, что имя класса MyObject больше, чем имя «java.lang.System». Ну офигеть теперь. Это, конечно, хорошо, что мы уже научились сравнивать строки. Но в результате это приводит к такому пыщ-эффекту, что в Java во всех классах нужно вручную писать метод equals и hashCode, но по факту почти везде они либо не делают ничего, либо делают ересь (как раз по той причине, что их нужно писать везде и вручную, а людям работать надо, думать в таких объемах над философией некогда!). Т.е. в самом типичном коде прямоугольник с равными сторонами будет не equals квадрату, только потому, что имена типов разные. На этот счет есть свои кости и костыли (например, статья «как писать метод эквивалентности в Жабке» от атца Скалы, Одерски), но это ж капец. Я не уверен, что написание горы canEqual, hasEqual, shouldEqual, approxEqual итп есть правильная «таблица умножения», это скорее что-то типа задачи конем обойти шахматную доску и прийти в нужную точку. Как в анекдоте про специальную олимпиаду - даже если ты выиграл специальную олимпиаду, все равно ты инвалид.

о, а ведь точно. Для передачи методов можно забабахать какую-нибудь фичу в IDE =)

Для передачи методов можно забабахать какую-нибудь фичу в...

по ссылке:

(defun mysort (alist)
  (with-interface (<number-map> <map>)
    (let ((m (alist-map alist)))
      (fold-right m #'acons nil))))

Внутри with-interface методы интерфейса <map> получают реализацию интерфейса <number-map>. То есть (alist-map alist) будет реально вызывать (alist-map <number-map> alist).

В динамике это не интересно, можно сделать в любом ЯП.

А в статике почти ничего интересного сделать нельзя.

Разве что в статике без мутабельности. Там действительно можно писать

class (Rect s) => Square s where ...

и никаких проблем нет, так как изменить переданный объект невозможно.

Common Lisp:

(deftype square
  `(and rectangle
        (satisfies (lambda (x) (= (width x) (height x))))))

А чем это принципиально отличается от банального:

(define (square x)
  (and (rectangle? x) (sitisfies? (lambda(x) (= (width  x) (height x))) x)))

Идея в том, что наследоваться должны не объекты, а интерфейсы.

Основной вопрос не в том, что наследовать, а как наследовать.

чем это принципиально отличается от банального

Абсолютно ничем. Чуть-чуть синтаксического сахара.

легко реализуемого на любом ЯП

В scheme да. Тип «квадрат» = «все x, для которых (square? x) = #t».

В других языках может быть другое понятие типа. Например, в C++

В других языках может быть другое понятие типа

Ваш «тип» - это всего лишь предикат. плюсы я не знаю, но в любом ЯП с ФВП, это будет также легко.

Как в анекдоте про специальную олимпиаду - даже если ты выиграл специальную олимпиаду, все равно ты инвалид.

Безотносительно к озвученой тобой концепции, просто ремарка, по ходу пьесы:

Если ты не инвалид, это не значит, что ты смог бы выиграть паролимпиаду.

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

есть, все-таки, множество объектов, отвечающих предикату, а не сам предикат.

Семантически «тип значения 5 — простое; значение 5 принадлежит множеству простых; простое — целое число, делящееся только на себя и единицу». Типу можно ставить в соответствие как множество, так и предикат. По факту, в любом случае, тип — свойство объекта.

в любом ЯП с ФВП, это будет также легко

В Haskell даже тип percent = «целое число от 0 до 100», насколько я знаю, описать нельзя.

тип — свойство объекта

Я не имел в виду все эти загогулины, которые нагородили в «продвинутых» ЯП. Я про тривиальный, бытовой смысл.

В Haskell даже тип percent = «целое число от 0 до 100», насколько я знаю, описать нельзя.

Сорри за нубский вопрос, но зачем нужен тип процент, если поцент - это просто натуральное число, и не обязательно даже целое, и не обязательно в этом диапазоне даже.

В Haskell даже тип percent = «целое число от 0 до 100», насколько я знаю, описать нельзя.

щито?!

В Haskell даже тип percent = «целое число от 0 до 100», насколько я знаю, описать нельзя.

А почему, кстати, нельзя, можете на пальцах объяснить? Видать из-за супер-мега-адвансед-type-system? Видать какой-то моноид попадает не в ту категорию функторов?
ЗЫ Когда я писал про ЯП с ФВП, я не имел в виду это дерьмо. Я это за ЯП не считаю.

Если знаешь, напиши, такой тип.

А почему, кстати, нельзя, можете на пальцах объяснить?

Могу. Потому что подтипов нет.

Если точнее, то можно написать прямым перечислением чисел от 0 до 100. Но вот складывать/умножать без явного преобразования типов уже не выйдет.

Ну я предполагаю, что опытный хаскель-бой способен накостылить что-то, чтобы обойти это, но это не отменяет того факта, что данный подход, действительно никуда не годен.

Я, кстати, уже писал где-то, что подход Haskell, - это класс-ооп, ид сбоку. Почему, интересно, его так назвали? Неужели Карри нес подобную чушь (я не знаком с его трудами, к своему стыду)

Потому что подтипов нет.

Основная проблема мневидится не в том что нет подтипов (а потом понадобятся подтипы подтипов), а в том что «есть типы».

перечисли все числа с 0 до 100 вручную (что бы ни считалось «числом»). Если одно из них - попадает в тип, нет - не попадает.