[flood] о наследовании [re: БЭМ! (yet another опенсорсный]
Даже в Коммон Лиспе?в лиспе, вообще, почти ничего нет - в том смысле, что заданную абстракцию должен поддерживать и сам язык, с учетом заданной абстракции должен быть выстроены библиотеки и т.д.
одного лишь условия, что абстракция может быть выражена на данном языке - не достаточно.
в лиспе, вообще, почти ничего нет - в том смысле, что заданную абстракцию должен поддерживать и сам язык, с учетом заданной абстракции должен быть выстроены библиотеки и т.д.Самое смешное что никто не спрашивает "а зачем" нужно это суперпупер наследование даже если оно там есть? Ты это как безусловный плюсик сразу засчитал.
одного лишь условия, что абстракция может быть выражена на данном языке - не достаточно.
А если подумать головой, то круг задач диктует абстракции для решения этих задач. Хочется видеть объяснение какие потребности они углядели чтобы хотеть делать какой-то тип абстракции.
В презентациях этого нет.
Ну, скажем, на лиспе, например, почти все мыслимые абстракции выражаются примерно с одинаковой сложностью. А как с ФП в яве?
Ну, скажем, на лиспе, например, почти все мыслимые абстракции выражаются примерно с одинаковой сложностью.в том смысле, что одинаково долго, и при этом ничего не гарантируется в итоге?
А как с ФП в яве?она же тьюринг-полная, значит и ФП там успешно выражается
зы
выразить можно что угодно на чем угодно.
не возможностью выражения отличаются одни языки от других
Действительно, но функциональную программу на лиспе выразить проще, чем императивную, а на яве наоборот. Что же касается возможностей и областей применения яп, они оба gp. А про веб приложения можно Пола Грэма почитать, как он всех обскакал на лиспе в 90е.
А если подумать головой, то круг задач диктует абстракции для решения этих задач. Хочется видеть объяснение какие потребности они углядели чтобы хотеть делать какой-то тип абстракции.строго говоря, не всегда так. Человечеству известны как индукция, так и дедукция.
Но БЭМ, да, выглядит как унылое говно.
строго говоря, не всегда так. Человечеству известны как индукция, так и дедукция.Ты зачем-то говоришь о том как эти абстракции придумывались, дедуктивно или индуктивно. Я говорю только про использование.
Действительно, но функциональную программу на лиспе выразить проще, чем императивную, а на яве наоборот.почему проще? а потому что язык предлагает гарантии поведения остального кода (если, конечно, не брать еще чисто синтаксические заморочки)
соответственно, если абстракция согласована с языком, то гарантии предоставляются, но если абстракция реализуется самостоятельно, то очень часто таких гарантий получить невозможно
Ты зачем-то говоришь о том как эти абстракции придумывались, дедуктивно или индуктивно. Я говорю только про использование.Я, так же как и ты, о подходах при решении конкретных задач.
1. От частного к общему (индукция): берем набор конкретных задач и находим/придумываем абстракцию, которая решает эти задачи.
2. От общего к частному (дедукция): берем абстракцию и пытаемся применить ее к конкретной задаче.
Встречается и то и другое.
соответственно, если абстракция согласована с языком, то гарантии предоставляются, но если абстракция реализуется самостоятельно, то очень часто таких гарантий получить невозможноГарантии чего? То, что абстракция (или механизм языка) реализована строго тем или иным образом — палка о двух концах. Например, хотелось бы подпатчить сборку мусора в дотнете, а нельзя. Это, правда, не про язык, а про платформу, но с языком такое тоже верно, модифицировать сам язык иногда бывает трудновато, даже если компилятор-интерпретатор открытый.
Я, так же как и ты, о подходах при решении конкретных задач.Ага, я не об этом как раз.
1. От частного к общему (индукция): берем набор конкретных задач и находим/придумываем абстракцию, которая решает эти задачи.
2. От общего к частному (дедукция): берем абстракцию и пытаемся применить ее к конкретной задаче.
Встречается и то и другое.
Гарантии чего?гарантия того, что все выполняют предусловия необходимые для работы абстракции.
или в более мощном виде: возможность удостовериться за O(1) работы программиста: насколько данный код удовлетворяет предусловиям для данной абстракции, и за тот же O(1) преобразовать его в код, который в той или иной мере удовлетворяет требованиям данной абстракции
вот тот же ФП не работает, если у функций есть побочные эффекты, и соответственно если все стандартные и сторонние либы пронизаны побочными эффектами, то использовать ФП будет очень и очень затруднительно.
например, хотелось бы подпатчить сборку мусора в дотнете, а нельзя.бери да патчи. кто тебе мешает? неудобно говоришь?.. так это опять же не выполнены предусловия того же повторного наследования: имеющиеся зависимости явно не прописаны.
"а зачем" нужно это суперпупер наследование даже если оно там есть?предоставить широкие возможности модификации виджета, в том числе тем людям, которые не знаю как оно устроено внутри.
предоставить широкие возможности модификации виджета, в том числе тем людям, которые не знаю как оно устроено внутри.Опять за свое. А нужны кому-то эти широкие возможности? Если нужны то кому и когда?
Опять за свое. А нужны кому-то эти широкие возможности? Если нужны то кому и когда?нужны конечным "разработчикам" для решения своих задач.
например:
зы
, вообще, вон хочет широкие возможности по изменению gc, а не только виджетов
а в соседнем треде ты жалуешься, что у BBB маленькое api
Оказывается Дарк Грей не знает про CLOS в Коммон Лиспе. Позор!
вот тот же ФП не работает, если у функций есть побочные эффекты, и соответственно если все стандартные и сторонние либы пронизаны побочными эффектами, то использовать ФП будет очень и очень затруднительно.не надо обобщать, это проблемы самого чистого языка Хаскела, а не всех Ф языков
в Схеме нет таких проблем, потому что нет разделения чистого и грязного кода (немного синтаксически выделяют мутабельные операции с помощью суффикса "!")
нужны конечным "разработчикам" для решения своих задач.Отличный ответ: нужны программистам для программирования программ.
:
Не вижу никакой связи с БЭМ. БЭМ делает ненужным знание html, css & javascript? Тут в этом проблема.
Ну и если плагина нет, скажем, в jquery, то не будет его и в другом фрэймворке. Просто потому что задачка редкая.
В одной предметной области абстракции потихоньку сходятся к одним и тем же.
Про БЭМ так и непонятна предметная область, задачи, которые на нем особенно хорошо решать, почему для них нужны какие-то новые абстракции и что они облегчают.
, вообще, вон хочет широкие возможности по изменению gc, а не только виджетов
а в соседнем треде ты жалуешься, что у BBB маленькое api
Если в этой каше из API, фрэймворка и open/closed source есть мысль, то сформулируй ее, пожалуйста.
ЗЫ: У вас на ВМК есть спецкурс на котором на каждую вашу строчку кода и на каждую задачку вам задают вопрос "зачем это надо?"?
Я, так же как и ты, о подходах при решении конкретных задач.Нет, мы об одном и том же, просто ты не верно понимаешь мои сообщения. Вот это твое сообщение
1. От частного к общему (индукция): берем набор конкретных задач и находим/придумываем абстракцию, которая решает эти задачи.
2. От общего к частному (дедукция): берем абстракцию и пытаемся применить ее к конкретной задаче.
Встречается и то и другое.
Ага, я не об этом как раз.
А если подумать головой, то круг задач диктует абстракции для решения этих задач. Хочется видеть объяснение какие потребности они углядели чтобы хотеть делать какой-то тип абстракции.
совпадает с тем, что у меня написано в пункте 1. А пункт 2 ты пропускаешь, на это я и хотел обратить твое внимание. Но раз не хочешь этого замечать, дело твое.
в Схеме нет таких проблем, потому что нет разделения чистого и грязного кода (немного синтаксически выделяют мутабельные операции с помощью суффикса "!")это едва ли уже можно назвать ФП: большинство возможностей ФП в такой ситуации не смогут работать.
это едва ли уже можно назвать ФПя предлагаю не использовать понятие ФП в таких заявлениях, потому что оно задекларировано в профессиональных кругах и сайд-эффекты никак не влияют на это понятие.
введи свое определение и оперируй им, иначе ты заставляешь двух квалифицированных людей общаться на разных языках, следовательно, они друг друга не поймут
это напоминает мне восклицание главного архитектора Акрониса: ООП почти никто не умеет применять, потому что суть ООП - это инверсия зависимости
можно, конечно, использовать понятие чистое ФП, но зачем? особенно если учесть, что чистая функция - это фактически второй(по вики) кит ФП.
ФП без чистых функций, это как ООП, но без полиморфизма: и там, и там форма есть, но профита не очень.
ФП без чистых функций, это как ООП, но без полиморфизма: и там, и там форма есть, но профита не очень.
Что за бред. Основной плюс ФЯ - это замыкания, функции любого порядка, тейл рекурсия, паттерн матчинг, строгая но гибкая система типов и т.д. в разных сочетаниях. Функции без сайд эффектов тоже плюс, но в чистых языках плюс не в этом, а в ленивых вычислениях. Еще раз говорю, КЛОС в коммон лиспе отличная ООП система, уж получше убожества, что есть в С++. Джаве, С# и компании.
Основной плюс ФЯ - это замыкания, функции любого порядка, тейл рекурсия, паттерн матчинг, строгая но гибкая система типов и т.д. в разных сочетаниях.вот всё это не будет работать, если функции не чистые.
не будет работать в том смысле - что будет почти невозможно предсказать поведение такой программы
> Функции без сайд эффектов тоже плюс, но в чистых языках плюс не в этом, а в ленивых вычислениях.
ленивые вычисления опять же требуют, чтобы функции были чистые
вот всё это не будет работать, если функции не чистые.Как это невозможно? Что помешает-то?
не будет работать в том смысле - что будет почти невозможно предсказать поведение такой программы
Как это невозможно? Что помешает-то?ФП построено на условии: код может выполняться не в том порядке в котором написан. это позволяет проводить всякие оптимизирующие преобразования кода: ленивость, отбрасывание кода не влияющего на результат и т.д.
всё это приводит к тому, что side-эффекты будут проявляться в произвольном порядке, и предсказать что будет в итоге невозможно.
если же у ФП забрать возможность преобразовывать код, то получится обычное процедурное программирование
Это касается только ленивых ФЯ которых меньшинство. Насчет последнего предложения — пожалуйста перестань нести бред, ФП не похоже на классическое процедурное никаким местом.
ленивые вычисления опять же требуют, чтобы функции были чистыетакое ощущение, что под ленивостью ты понимаешь "то ли вызовут, то ли не вызовут и хз сколько раз". это не так, там все вполне детерминировано
например, в Схеме с помощью print внутри функций новичкам как раз показывают какие выражения и в каком порядке вычисляются
например, в Схеме с помощью print внутри функций новичкам как раз показывают какие выражения и в каком порядке вычисляютсятак показывают же, а не строят по этой же схеме программу у которой важен вывод на консоль
Ну в Хаскелле, например, есть монады, через которые реализуется детерминированный порядок вычисления.
Ну в Хаскелле, например, есть монады, через которые реализуется детерминированный порядок вычисления.напомню, исходное утверждение
1. возможность удостовериться за O(1) работы программиста: насколько данный код удовлетворяет предусловиям для данной абстракции,монада - это уже mutable-код, который преобразован в такой вид, с которым согласована работа ФП-абстракции
2. за тот же O(1) преобразовать его в код, который в той или иной мере удовлетворяет требованиям данной абстракции
Оставить комментарий
Papazyan
Даже в Коммон Лиспе?