Мир Россией не ограничен, в большинстве стран законы все-таки исполняются: доступ к таким данным дается только по решению суда, и обойти этот запрет практически невозможно (ведутся логи доступа).
Ну и разница даже между «за шоколадку» и «в один клик» колоссальна. Количество затраченных ресурсов отличается на несколько порядков. Это даже не учитывая, что доступ «за шоколадку» является уголовно наказуемым преступлением для обоих сторон сделки.
Можете уточнить, что именно вы подразумеваете, когда говорите «перевожу тысячи долларов за 10 минут»? Переводите с одного *коин-кошелька на другой, или же переводите с кошелька на карту? Если на карту, то какого банка: своего или любого?
Потому что если вы переводите между кошельками (т.е. в рамках одной системы), то банки в этом плане гораздо быстрее, большая часть внутрибанковых транзакций на порядки быстрее 10 минут. Да и говорить «перевожу доллары» некорректно — вы переводите коины, у которых сегодня есть какой-то эквивалент в долларах.
Грубо говоря, если вы хотите купить кофе за $5, то банковская транзакция для вас, как пользователя выглядит мгновенной (быстрее 10 минут).
Если же вы, допустим, хотите помочь родственнику купить недвижимость в другой стране и перевести ему $50,000, то у вас есть два варианта:
1. банковский перевод → покупка недвижимости
2. [опционально: конвертировать доллары в биткоины] → перевод биткоинов → конвертировать биткоины в обратно в доллары → покупка недвижимости.
Что в итоге тоже выливается минимум в один банковский перевод, что по определению не может быть быстрее.
Единственная ситуация, где биткоин перевод имеет преимущество по времени, это такой перевод, при котором у отправителя уже есть биткоины, а получатель не планирует конвертировать их доллары. Т.е. сделка проводится именно в биткоинах, а не в их долларовом эквиваленте.
Например вам дали кредит в 10 BTC, и через указанный срок вы обязаны вернуть именно 10 BTC, вне зависимости от того, как поменялся их курс к доллару. А такие сделки, из-за волатильности биткоина, практически никому не интересны. Он просто не может стать заменой фиатным деньгам пока у него такая волатильность.
Карта, привязанная к биткоин-кошельку — это дешевый маркетинговый ход для людей который хотят быть «в тренде». Вероятнее всего у вас эквивалент самой обычной кредитной карты, у которой кредит асинхронно погашается через BTC-кошелек (и также асинхронно пополняется). И, поскольку задержки у этой асинхронности довольно большие, банк попросту будет тормозить крупные платежи, никакого преимущества вы не получите.
По сути вы просто совмещаете все недостатки обоих систем, в обмен на удобство автоматического погашения кредита через BTC-кошелек.
Что за бред? СЕО — это офицер, офицеров назначает совет директоров. В некоторых (особенно маленьких) компаниях СЕО конечно может быть частью совета директоров и даже акционером, но синонимом это его никак не делает.
Безусловно в огромных транснациональных компаниях все очень неоднородно. Но шансов попасть в хорошую команду в Амазоне все-таки гораздо меньше, чем в FB/Google.
Успех продукта не означает что он создавался в приятной обстановке. Из большой четверки (Apple, Google, Facebook, Amazon) у Амазона самый низкий рейтинг на glassdoor, например.
Вы все правильно говорите, каждая проблема по отдельности решаема, и даже есть реализации, где отдельные проблемы решены. И, скорее всего, теоретически возможна технология, где решены все перечисленные проблемы.
Но на сегодняшний день, не существует ни одной реализации криптовалют, где все эти проблемы отсутствуют. И в ближайшем будущем они вряд ли появятся.
Как бы повело себя адекватное научное сообщество? Оно бы составило список хороших научных журналов или установило бы другой канал связи и начало бы с момента последней «валидной» транзакции.
Такое себе сферическое адекватное научное сообщество в вакууме.
Почему вы не рассматриваете ситуацию когда сообщество распадается на несколько «школ» (форков) и каждая тянет одеяло на себя? В жизни это происходит постоянно (религия, наука, политика...). Вот и в битке произошло.
Ну и стандартный вопрос: а судьи кто? Сообщество — это слишком абстрактно.
Как вам отделить «адекватное сообщество» от «врагов», которые захватили 51%? Каждое сообщество считает своих членов адекватными, а своих оппонентов — нет. Вам почему-то кажется что можно провести объективную грань между «адекватными» и «неадекватными». Но
это не так, грань — субъективна.
Проблема 51% процента возникает за счет децентрализации, а вы получается предлагаете от нее отказаться и ввести судей, которые решат кто из нас тут входит в «адекватное сообщество», а кого расстрелять?
Ок, видимо мне придется уточнить свою же фразу (уточнение выделил).
Достоинство ООП в том, что оно позволяет сравнительно легко выделить один из уровней абстракции, который соответствует реальному миру.
В качестве подтверждения могу вам предложить тотальное доминирование ООП в промышленной разработке и самый первый комментарий в этом треде, на который вы так возбудились. Я думаю вы не первый раз видите людей, жалующихся на сложность понимания ФП.
Какие классы/объекты Вы вы бы выделили? Какие сообщения они будут посылать друг другу?
Как-то мало информации вы выдали для того чтоб что-то проектировать. ТЗ когда-нибудь писали? «Написать бота» — это не ТЗ.
Вы, кстати, до сих пор не удосужились привести примеры упомянутых вами «многих случаев» где ФП удобнее для проектирования реального мира. От меня уже проектировать что-то требуете, а сами до сих пор не соизволили свои же слова подтвердить. Я все еще жду конкретных примеров, хотя бы парочку выдайте.
Как я погляжу, уже начали придумывать свои формулировки?
Неправильно глядите. Вы объясняете инкапсуляцию через «что», а я — через «зачем». К сожалению ООП в 90% случаев преподносится именно через «что». В итоге имеем карго-культ — нелепо повторяем какие-то вещи, без понимания сути.
Попробуйте вместо русской википедии почитать хотя бы английскую. Там про инкапсуляцию пишут не packing, а bundling. Разницу улавливаете?
Если нет, то я вам подскажу: упаковывают (pack) для сжатия или транспортировки. Например вино в ящики. Или файлы в архив/сеть.
А «связывают» (bundle) — по смыслу. Например вино и штопор. Или структуру «кошка» и метод «мяукать».
Какой смысл вы вкладывали в свою программу — знаете только вы. Для меня вы выдали слишком мало информации, чтобы ответить на ваш вопрос.
Я вижу вы таки осилили почитать про CLOS и теперь надеетесь подловить меня на том, что в ней нет википедийной инкапсуляции. Рекомендую меньше читать русскую Википедию.
Инкапсуляция — это не «упаковка в контейнер», а связь между функцией и данными, с которыми функция оперирует. В такой формулировке инкапсуляция является необходимой характеристикой ООП, и в такой формулировке она есть в CLOS: именно благодаря этой связи рантайм понимает какой именно метод нужно вызвать.
В том-то и дело, что с утверждениями copal я во многом согласен, а вот с тем, как вы их переформулировали — нет. Потому что в своей формулировке вы подменяете понятия и додумываете ложные выводы.
Т.е. вы примеры не хотите привести, но у меня просите.
Перечитайте тред. Вообще-то именно я вас упрекнул в отсутствии конкретики, на что вы отреагировали «если хотите конкретики, то приведите пример...». Немного неадекватно, вам не кажется?
И даже если проигнорировать, что я первый попросил вас о конкретике, заметьте, что вы требуете пример для чужого утверждения, которое вы пересказали собственными словами, заметно исказив его смысл. Я же, требуя от вас пример, цитирую вас слов в слово.
стоит ли тут использовать ООП или ФП
Вопрос «стоит ли» некорректен. Что «стоит» делать обычно зависит не только от задачи, а от доступных ресурсов. Если вы всю жизнь писали на Lisp, вам не «стоит» бросать все и решать эту задачу на каком-нибудь Java.
Правильнее спросить, как решение этих задач себе представит человек.
И в общем случае, поскольку в обоих примерах явно выражено изменяемое состояние (рука, колода, положение на экране), большинству людей естественнее будет именно ОО-подход.
Попробуйте научить играть в «дурака» другого человека. Очень сомневаюсь, что будете ему рассказывать, что «на каждом ходу у тебя будет новая рука, являющаяся функцией от прошлого состояния руки и извлеченных недостающих карт».
Получается, что другие методологии этого не позволяют?
Вот как, объясните мне как, из фразы «ООП хорошо позволяет сделать Х» вы делаете вывод «в ФП невозможно Х»? Это абсолютно неэквивалентные утверждения, почему вы постоянно вынуждаете собеседника доказывать, что он не верблюд?
В вас просто зашкаливает какой-то неадекватный максимализм.
Вообще-то любое программирование как раз про абстракции реального мира.
Перестаньте рассматривать абстракцию как часть догмы «абстракция, наследование, инкапсуляция, полиморфизм».
Абстракция — это не то, что Alan Kay засунул в ООП, а то, ради чего он его создал.
А статью пишите конечно. Чем больше популяризации ФП на реальных примерах, тем лучше.
Ага, понятно. ООП плохое потому что оно по определению однонаправленное, а если мне покажут контрпример, я просто скажу что это «не настоящее ООП» (ну или не «классическое»).
Слушайте, да вы просто ходящий сборник уловок демагога!
Ну и разница даже между «за шоколадку» и «в один клик» колоссальна. Количество затраченных ресурсов отличается на несколько порядков. Это даже не учитывая, что доступ «за шоколадку» является уголовно наказуемым преступлением для обоих сторон сделки.
Потому что если вы переводите между кошельками (т.е. в рамках одной системы), то банки в этом плане гораздо быстрее, большая часть внутрибанковых транзакций на порядки быстрее 10 минут. Да и говорить «перевожу доллары» некорректно — вы переводите коины, у которых сегодня есть какой-то эквивалент в долларах.
Грубо говоря, если вы хотите купить кофе за $5, то банковская транзакция для вас, как пользователя выглядит мгновенной (быстрее 10 минут).
Если же вы, допустим, хотите помочь родственнику купить недвижимость в другой стране и перевести ему $50,000, то у вас есть два варианта:
1. банковский перевод → покупка недвижимости
2. [опционально: конвертировать доллары в биткоины] → перевод биткоинов → конвертировать биткоины в обратно в доллары → покупка недвижимости.
Что в итоге тоже выливается минимум в один банковский перевод, что по определению не может быть быстрее.
Единственная ситуация, где биткоин перевод имеет преимущество по времени, это такой перевод, при котором у отправителя уже есть биткоины, а получатель не планирует конвертировать их доллары. Т.е. сделка проводится именно в биткоинах, а не в их долларовом эквиваленте.
Например вам дали кредит в 10 BTC, и через указанный срок вы обязаны вернуть именно 10 BTC, вне зависимости от того, как поменялся их курс к доллару. А такие сделки, из-за волатильности биткоина, практически никому не интересны. Он просто не может стать заменой фиатным деньгам пока у него такая волатильность.
Карта, привязанная к биткоин-кошельку — это дешевый маркетинговый ход для людей который хотят быть «в тренде». Вероятнее всего у вас эквивалент самой обычной кредитной карты, у которой кредит асинхронно погашается через BTC-кошелек (и также асинхронно пополняется). И, поскольку задержки у этой асинхронности довольно большие, банк попросту будет тормозить крупные платежи, никакого преимущества вы не получите.
По сути вы просто совмещаете все недостатки обоих систем, в обмен на удобство автоматического погашения кредита через BTC-кошелек.
Но на сегодняшний день, не существует ни одной реализации криптовалют, где все эти проблемы отсутствуют. И в ближайшем будущем они вряд ли появятся.
Почему вы не рассматриваете ситуацию когда сообщество распадается на несколько «школ» (форков) и каждая тянет одеяло на себя? В жизни это происходит постоянно (религия, наука, политика...). Вот и в битке произошло.
Ну и стандартный вопрос: а судьи кто? Сообщество — это слишком абстрактно.
Как вам отделить «адекватное сообщество» от «врагов», которые захватили 51%? Каждое сообщество считает своих членов адекватными, а своих оппонентов — нет. Вам почему-то кажется что можно провести объективную грань между «адекватными» и «неадекватными». Но
это не так, грань — субъективна.
Проблема 51% процента возникает за счет децентрализации, а вы получается предлагаете от нее отказаться и ввести судей, которые решат кто из нас тут входит в «адекватное сообщество», а кого расстрелять?
Вот правильный график:
Сравним его с вашим:
Не стыдно, а?
«A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data»
Открываем словарь:
bundling
связывание, складывание; пакетирование; сматывание
соединение; сочетание
группирование;
Упаковывания не нашел.
Забавно. И эти люди
запрещают мне ковырятьсяговорят мне не придумывать своих формулировок.Достоинство ООП в том, что оно позволяет сравнительно легко выделить один из уровней абстракции, который соответствует реальному миру.
В качестве подтверждения могу вам предложить тотальное доминирование ООП в промышленной разработке и самый первый комментарий в этом треде, на который вы так возбудились. Я думаю вы не первый раз видите людей, жалующихся на сложность понимания ФП.
Как-то мало информации вы выдали для того чтоб что-то проектировать. ТЗ когда-нибудь писали? «Написать бота» — это не ТЗ.
Вы, кстати, до сих пор не удосужились привести примеры упомянутых вами «многих случаев» где ФП удобнее для проектирования реального мира. От меня уже проектировать что-то требуете, а сами до сих пор не соизволили свои же слова подтвердить. Я все еще жду конкретных примеров, хотя бы парочку выдайте.
Попробуйте вместо русской википедии почитать хотя бы английскую. Там про инкапсуляцию пишут не packing, а bundling. Разницу улавливаете?
Если нет, то я вам подскажу: упаковывают (pack) для сжатия или транспортировки. Например вино в ящики. Или файлы в архив/сеть.
А «связывают» (bundle) — по смыслу. Например вино и штопор. Или структуру «кошка» и метод «мяукать».
Какой смысл вы вкладывали в свою программу — знаете только вы. Для меня вы выдали слишком мало информации, чтобы ответить на ваш вопрос.
Инкапсуляция — это не «упаковка в контейнер», а связь между функцией и данными, с которыми функция оперирует. В такой формулировке инкапсуляция является необходимой характеристикой ООП, и в такой формулировке она есть в CLOS: именно благодаря этой связи рантайм понимает какой именно метод нужно вызвать.
Перечитайте тред. Вообще-то именно я вас упрекнул в отсутствии конкретики, на что вы отреагировали «если хотите конкретики, то приведите пример...». Немного неадекватно, вам не кажется?
И даже если проигнорировать, что я первый попросил вас о конкретике, заметьте, что вы требуете пример для чужого утверждения, которое вы пересказали собственными словами, заметно исказив его смысл. Я же, требуя от вас пример, цитирую вас слов в слово.
Вопрос «стоит ли» некорректен. Что «стоит» делать обычно зависит не только от задачи, а от доступных ресурсов. Если вы всю жизнь писали на Lisp, вам не «стоит» бросать все и решать эту задачу на каком-нибудь Java.
Правильнее спросить, как решение этих задач себе представит человек.
И в общем случае, поскольку в обоих примерах явно выражено изменяемое состояние (рука, колода, положение на экране), большинству людей естественнее будет именно ОО-подход.
Попробуйте научить играть в «дурака» другого человека. Очень сомневаюсь, что будете ему рассказывать, что «на каждом ходу у тебя будет новая рука, являющаяся функцией от прошлого состояния руки и извлеченных недостающих карт».
Вот как, объясните мне как, из фразы «ООП хорошо позволяет сделать Х» вы делаете вывод «в ФП невозможно Х»? Это абсолютно неэквивалентные утверждения, почему вы постоянно вынуждаете собеседника доказывать, что он не верблюд?
В вас просто зашкаливает какой-то неадекватный максимализм.
Перестаньте рассматривать абстракцию как часть догмы «абстракция, наследование, инкапсуляция, полиморфизм».
Абстракция — это не то, что Alan Kay засунул в ООП, а то, ради чего он его создал.
А статью пишите конечно. Чем больше популяризации ФП на реальных примерах, тем лучше.
Слушайте, да вы просто ходящий сборник уловок демагога!