Муки выбора первого юзабельного языка (pascal за язык не считается). Есть два ООП ЯП: лиспы точеные и питоны золоченые...

зато в реболе были диалекты — почти как в ракетке #lang mylang-syntax

Почему пистон тормозит — это вообще *загадка*.

1. Бинарные операции, как правило, вызов двух методов (__add + __radd, например).

2. Объекты позволяют менять свои поля и методы. И перед чтением/записью поля выполняются __getattribute__, __getattr__, __setattr__, __get__, __set__

http://www.sbcl.org/manual/#Package_002dLocal-Nicknames

Ъ функциональный подход с чистыми ф-циями, осложнит проектирование и раздует код еще раз в 10, как минимум.

class AccountClass a where
  withdraw :: a -> Rational -> a
  deposit :: a -> Rational -> a

data Account = Account Rational | AccountError String
  deriving Show

instance AccountClass Account where
  withdraw (Account balance) amount = 
    if balance >= amount 
    then Account (balance - amount)
    else AccountError "Insufficient funds"

  deposit (Account balance) amount = Account (balance + amount)

data AccountWithCredit = AccountWithCredit Rational Rational | AccountWithCreditError String
  deriving Show

instance AccountClass AccountWithCredit where
  withdraw (AccountWithCredit balance credit) amount = 
    if balance + credit >= amount 
    then AccountWithCredit (balance - amount) credit
    else AccountWithCreditError "Insufficient funds"

  deposit (AccountWithCredit balance credit) amount = Account (balance + amount) credit

http://www.sbcl.org/manual/#Package_002dLocal-Nicknames

Это только для имён пакетов. А проблема возникает с именами символов.

Можно, конечно, в текущем пакете дублировать. Типа (setf (macro-function do-iter) (macro-function iterate:iter)). Но многословно.

То что ты привел — это только подтверждение моих слов. Ты, во первых, полностью реализацию не сделал. Во-вторых, основную мысль ты подтвердил. Ты вместо того чтобы отнаследовать класс реализовал все заново, продублировал весь функционал. А теперь представь, что в Account не 3, а 100 методов. Там, по-ходу, даже не в 10 раз получается, а экспонцеально, lol

Ты, во первых, полностью реализацию не сделал.

Если ты про метод show, то сделал. «deriving Show» именно это делает. Или что пропустил?

А теперь представь, что в Account не 3, а 100 методов.

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

Так для упомянутой задачи было бы правильней:

class AccountClass a where
  changeBalance :: a -> Rational -> a

withdraw a i | i > 0 = changeBalance a (-i)

deposit a i | i > 0 = changeBalance a i

data Account = Account Rational | AccountError String
  deriving Show

instance AccountClass Account where
  changeBalance (Account balance) change = 
    if balance + change > 0
    then Account (balance + change)
    else AccountError "Insufficient funds"

data AccountWithCredit = AccountWithCredit Rational Rational | AccountWithCreditError String
  deriving Show

instance AccountClass AccountWithCredit where
  changeBalance (AccountWithCredit balance credit) amount = 
    if balance + credit + change >= 0
    then AccountWithCredit (balance + amount) credit
    else AccountWithCreditError "Insufficient funds"

Или что пропустил?

Ты больше половины пропустил. В моем коде AccountWithCredit нследует от Account, AccountWithCredit10 и AccountWithCredit20 от AccountWithCredit, account1 — от Account, account2 — от AccountWithCredit10, account3 — от AccountWithCredit20

то сделал. «deriving Show» именно это делает

Угу, я понял, это финт ушами для впечатления более лучшей краткости. Я вообще мог его не писать, можно было просто account balance print

то, скорее всего, ошибка в архитектуре.

Это обычное дело, если мой язык ни хрена не может, значет все что он не может — ошибки архитектуры, кто бы в этом сомневался.

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

account1 — от Account, account2 — от AccountWithCredit10, account3 — от AccountWithCredit20

account1 = Account 0

accountWithCredit10 = AccountWithCredit 0 10
accountWithCredit20 = AccountWithCredit 0 20

account2 = accountWithCredit10
account3 = accountWithCredit20

Я думал, то просто пример испоьзования

Я вообще мог его не писать, можно было просто account balance print

Если явно писать будет что-то вроде

class AccountClass a where
  changeBalance :: a -> Rational -> a
  printAccount :: a -> IO ()
  printAccount = putStrLn . show

вместо

class AccountClass a where
  changeBalance :: a -> Rational -> a

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

AccountWithCredit20 foo := method("bar")
account3 = accountWithCredit20
account3 foo print // --> bar

ты написал совершенно другой код,

Естественно, если объектов нет, то код другой. Мы же задачу решаем, а не объекты рисуем.

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

С чего это? Вроде строки примерно как у тебя. Задача решается так же.

Кстати, что будешь делать если при твоих условиях (уже написанное менять нельзя) появится необходимость добавить метод ко всей иерархии?

То есть, например,

withdrawBalanceKurs a i k = withdraw a (i*k)

Твой код?

Вроде строки примерно как у тебя

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

появится необходимость добавить метод ко всей иерархии?

Это взаимоисключающие понятия. Надо будет добавить хотя бы одну строку к главному классу.

Мы же задачу решаем

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

Задача решается так же.

Она не так же у тебя решается. У меня:

class[1000 lines here]
subClass [1 line here]
subSubClass [1 line here]

//у тебя
class[1000 lines here]
anotherClass [1000 lines here]
anotherClass [1000 lines here]

Надеюсь, понятно. И я вообще не уверен, что ты реализовал аккаунт. Где там стейт у тебя?

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

появится необходимость добавить метод ко всей иерархии?

Это взаимоисключающие понятия. Надо будет добавить хотя бы одну строку к главному классу.

Теперь ты «продемонстрировал отсутствие гибкости» ООП подхода.

В целом, ситуация, когда у существующего объекта появляется новая операция гораздо чаще, чем когда появляется новый класс с тем же интерфейсом, что и существующий.

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

Примерно так:

class Printable a where
  showP :: a -> IO ()
  showP = putStrLn . show

class AccountClass a where
  changeBalance :: a -> Rational -> a

instance AccountClass a => Printable a

withdraw a i | i > 0 = changeBalance a (-i)

deposit a i | i > 0 = changeBalance a i

data Account = Account Rational | AccountError String
  deriving Show

instance AccountClass Account where
  changeBalance (Account balance) change = 
    if balance + change > 0
    then Account (balance + change)
    else AccountError "Insufficient funds"

data AccountWithCredit = AccountWithCredit Rational Rational | AccountWithCreditError String
  deriving Show

instance AccountClass AccountWithCredit where
  changeBalance (AccountWithCredit balance credit) amount = 
    if balance + credit + change >= 0
    then AccountWithCredit (balance + amount) credit
    else AccountWithCreditError "Insufficient funds"

account1 = Account 0

accountWithCredit10 = AccountWithCredit 0 10
accountWithCredit20 = AccountWithCredit 0 20

account2 = accountWithCredit10
account3 = accountWithCredit20

subClass [1 line here]

anotherClass [1000 lines here]

Ну нет же.

У тебя

AccountWithCredit := Account clone do(
  credit ::= 0
  withdraw = method(amount, 
    if((balance + credit) >= amount, balance = balance - amount, "Insufficient funds" )
  )
)

у меня

data AccountWithCredit = AccountWithCredit Rational Rational | AccountWithCreditError String
  deriving Show

instance AccountClass AccountWithCredit where
  changeBalance (AccountWithCredit balance credit) amount = 
    if balance + credit + change >= 0
    then AccountWithCredit (balance + amount) credit
    else AccountWithCreditError "Insufficient funds"

Не сказал бы, что сильно больше

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

Ты же сам просил чистые функции.

Где там стейт у тебя?

Стейт в функциональных языках снаружи. Вот переданная переменная изменяет своё значение

makeDeposit :: STRef s Account -> Fractional -> ST s ()
makeDeposit account i = 
  modifySTRef account $ \v -> deposit v i

В гипотетической же ситуации с 100 независимыми методами просто будет 100 классов типов по одному методу с реализацией по-умолчанию. И если тебе надо переопределить 1 метод, то просто определяешь экземпляр типа для этого класса типов. Примерно так:

То же самое можно сделать и в ООП, создаешь класс, затем от него наследуешь 100 классов, хоть с собственными методами, хоть с наследуемыми, и затем переопределяешь один этот метод в суперклассе. Это все настолько элементарно, что даже удивительно, что с виду адекватные люди выдают это за фичу. Детский сад.

Ты же сам просил чистые функции.

Я имел в виду с монадами и прочим говном, которое обеспечивает стейт. Какой аккаунт ты без стейта взялся показывать? Ты в своем уме вообще? Ты завел в банке счет, положил туда 1000 баксов, а как ты снимать их будешь? Ты может перегрелся? Отдохнуть надо?

Естественно, я не стал писать 100/1000/10000 методов, для демонстрации принципа этого достаточно было. А это рассуждение в стиле акына, что вижу о том пою.

Потому что им не занимались ребята из гугла или мозиллы.

Занимались. Что-то не выгорело.

Я конечно тред особо не читал, но скажу свое мнение. Питон - отличный язык для умственно отсталых. Если ты такой - тебе будет с ним очень комфортно.

Занимались

По сравнению с v8 - нет:

«Томас Воутерс (Thomas Wouters), Джеффри Ясскин (Jeffrey Yasskin) и Коллин Винтер (Collin Winter) сами являются штатными сотрудниками Google[2], однако большинство участников проекта не являются сотрудниками Google

Главный спонсор проекта Google потерял интерес дальнейшему развитию проекта»

Но, в некотором смысле, Unladen жив под именем Pyston.

Занимались

По сравнению с v8 - нет

Хочешь сказать, что при должном подходе питон возможно, принципиально, ускорить?

Конечно. Мало того, что нет никаких принципиальных отличий Python от JS, так PyPy является живым доказательством.

он не чисто объектно-ориентированный язык

нихренасибе, это с каких пор недостаток?

и он не полностью свободный

поэтому речь и идет про Red.

Ты ведь нимом интересуешь - на твой взгляд Red перспективнее или как?

Да, Red точно перспективнее в плане высокоуровневого программирования, рантайма, интроспекции и тд. А на низком уровне диалект Red/System примерно соответствует ниму.

определяешь экземпляр типа для этого класса типов

затем переопределяешь один этот метод в суперклассе

Здесь у нас терминологическая путаница. «определяешь экземпляр типа» в ООП будет «указываешь, что класс является наследником данного суперкласса и определяешь в нём необходимые методы», а не изменение суперкласса

Я имел в виду с монадами и прочим говном, которое обеспечивает стейт.

www.linux.org.ru/add_comment.jsp?topic=12156738&replyto=12162753

Какой аккаунт ты без стейта взялся показывать?

Account — это и есть стейт банковского счёта. Если мне надо их различать (у меня несколько счетов в коллекции), то могу добавить в структуру данных номер счёта.

Ты завел в банке счет, положил туда 1000 баксов, а как ты снимать их будешь?

Так и буду: newAccount = withdraw account 1000. Результатом будет новое состояние этого счёта в банке.

Какой аккаунт ты без стейта взялся показывать? Ты в своем уме вообще?

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

Так и буду:

ЯННП. Давай, для ясности, выкинем все лишнее, и перепишем вот так.

Account := Object clone do(
   balance ::= 0
   withdraw := method(amount, balance = balance - amount)
   deposit := method(amount, balance = balance + amount)
)

Person := Object clone

John := Person clone do(
   account := Account clone
)

Jack := Person clone do(
   account := Account clone
)

John account deposit(100)
Jack account deposit(300)

John account withdraw(10)
Jack account withdraw(50)

Jack account balance println // 250
John account balance println // 90

Как будет выглядеть вариант без стейта? В какую такую структуру ты собрался добавлять что-то? Где это видано?

Ведущие ученые из области CS говорят, что аккаунт — это то что не может чистое ФП. Может ты открытие важное сделал? Может тебе нобелевскую премию вручат?

«указываешь, что класс является наследником данного суперкласса и определяешь в нём необходимые методы», а не изменение суперкласса

Ну и что? От этого что суть меняется? Разница в том, что я и в рантайме смогу переопределить или добавить метод, а ты — нет.

это с каких пор недостаток?

Со времен смоллтока, видимо.

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

этих уродливых отступов.

Рукожоп.

Для меня больше важна возможность пользоваться ООП и не пользоваться им когда мне надо.

Но многословно.

Одна из задач макросов - уменьшение многословности

(defmacro alias (nick name)
  `(setf (macro-function ,nick) (macro-function ,name)))

(alias do-iter iterate:iter)

Как будет выглядеть вариант без стейта?

newIORef

modifyIORef

readIORef

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

К слову, в clojure с алиасами из коробки все в порядке.

Как будет выглядеть вариант без стейта?

но создается ощущение, что ты меня за идиота держишь.

Account без стейта. Даже Person без стейта. Стейт есть только у переменных john и jack.

Похоже, ты начинаешь что-то подозревать.

Э-э-э, да? Больше и сложнее любого из остальных четырёх. Хотя, Java это только вредит.

Всё гуглится, если уж решили меряться количеством правил в BNF.

CL: http://cui.unige.ch/isi/bnf/LISP/BNFlisp.html В Common Lisp есть ещё макросы чтения, которые вызывают произвольную функцию, чтобы прочитать следующий за ним список, но без них BNF такой. Стандартные ридер-макросы для процесса разработки не принципиальны. Tcl: http://rosettacode.org/wiki/Category:Tcl#Grammar Тут кое чего не хватает, но он будет даже не в два раза больше. Кроме того, аргумент expr и первый аргумент if - арифметическое выражение с другой BNF, вроде этой: https://en.wikipedia.org/wiki/Syntax_diagram#Example Только ещё есть квадратные скобки, которые имеют такой же смысл как и в основном синтаксисе Tcl.

И да, в обоих языках ключевых слов нет.

Java вообще один из самых простых языков с «обычным» инфиксным синтаксисом, если не самый простой. https://docs.oracle.com/javase/specs/jls/se7/html/jls-18.html

Python: https://docs.python.org/3/reference/grammar.html

Erlang: Не знаю для чего это (intelij-erlang? o_O) Но похоже на правду. Даже новый синтаксис хеш-таблиц из 18.0 есть.

Ок, по количеству правил Erlang всё же сложнее.

Всё гуглится, если уж решили меряться количеством правил в BNF.

А как еще более-менее объективно оценить сложность синтаксиса? На глазок, что ли?

Ок, по количеству правил Erlang всё же сложнее

На лисп с тиклем изначально надежды было мало.

CL: http://cui.unige.ch/isi/bnf/LISP/BNFlisp.html В Common Lisp есть ещё макросы чтения, которые вызывают произвольную функцию, чтобы прочитать следующий за ним список, но без них BNF такой.

Там даже правил для кавычек нет. Реальная бнф CL раз в 20 больше.

Да, я уже посмотрел внимательно. :) Но не в 20. Там не хватает строк («кавычек»), float (1.234) и rational (12/34) чисел, буквы (#\a) символа в пакете (пакет:символ) и символа вне пакетов (#:символ). Это всё по одному правилу. Кейворд с точки зрения синтаксиса - частный случай символа в пакете, когда пакет не указан явно. Своё правило для этого не нужно.

И нет, в Tcl действительно правил для никаких чисел нет. С точки зрения парсера это строки.