Этого треда уже нет.
Это копия, сохраненная 1 января 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 1 января 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
92 Кб, 800x600Для чего нужно ООП?
Какие проблемы и задачи оно решает?
Почему пользоваться классами и объектами, а не допустим списками? Ведь суть одна и та же.
В ООП объект со своими параметрами.
В списке просто именованный список со своими членами.
Я нуб-студент
Какие проблемы и задачи оно решает?
Почему пользоваться классами и объектами, а не допустим списками? Ведь суть одна и та же.
В ООП объект со своими параметрами.
В списке просто именованный список со своими членами.
Я нуб-студент
>>607925 (OP)
Проблему утилизации обширных быдло-масс в ИТ. цитата
>Какие проблемы и задачи оно решает?
Проблему утилизации обширных быдло-масс в ИТ. цитата
>>607925 (OP)
мало писал в процедурном стиле раз не понял зачем ООП
мало писал в процедурном стиле раз не понял зачем ООП
>>607925 (OP)
Тут целую простыню текста можно расписать по этому поводу, неохота, вдруг ты даже читать не станешь. Поэтому ты расскажи как бы ты в процедурном стиле описал новый тип данных? У тебя есть стандартные типы - целое, число с плавающей точкой, символ, булеан. А тебе нужен, например такой тип как время в формате hh:mm:ss.
Это всего лишь особенности реализации. В некоторых скриптовых языках объект реализован как ассоциативный массив.
>Какие проблемы и задачи оно решает?
Тут целую простыню текста можно расписать по этому поводу, неохота, вдруг ты даже читать не станешь. Поэтому ты расскажи как бы ты в процедурном стиле описал новый тип данных? У тебя есть стандартные типы - целое, число с плавающей точкой, символ, булеан. А тебе нужен, например такой тип как время в формате hh:mm:ss.
>Почему пользоваться классами и объектами, а не допустим списками?
Это всего лишь особенности реализации. В некоторых скриптовых языках объект реализован как ассоциативный массив.
>>607925 (OP)
Сейчас набегут
Это не просто список. Его элементы могут быть разных типов, в том числе представлять собой вложенные списки, из чего следует, что такая интерпретация ООП плохо ложится на статическую типизацию.
Технически, ООП не даёт ничего такого, что нельзя было бы сделать без него. Вся разница в удобстве. Запись:
alice.friends.bob
куда понятнее, чем:
Сейчас набегут
Это не просто список. Его элементы могут быть разных типов, в том числе представлять собой вложенные списки, из чего следует, что такая интерпретация ООП плохо ложится на статическую типизацию.
Технически, ООП не даёт ничего такого, что нельзя было бы сделать без него. Вся разница в удобстве. Запись:
alice.friends.bob
куда понятнее, чем:
> aline[17][4]
>>608059
/thread
/thread
>>608143
Но в этих записях не раскрывается ни наследование, ни инкапсуляция, ни полиморфизм, которые и составляют ООП.
Просто структуры данных - ещё не ООП.
Реализовать на голом Си виртуальные функции, конечно, возможно, но заебёшься это делать.
Но в этих записях не раскрывается ни наследование, ни инкапсуляция, ни полиморфизм, которые и составляют ООП.
Просто структуры данных - ещё не ООП.
Реализовать на голом Си виртуальные функции, конечно, возможно, но заебёшься это делать.
>>607979
Разве быдло-массы пишут на Smalltalk? Или ты от скудоумия приплетаешь недо-ООП из Python/Java/C# к настоящему ООП?
>быдло-масс
Разве быдло-массы пишут на Smalltalk? Или ты от скудоумия приплетаешь недо-ООП из Python/Java/C# к настоящему ООП?
>>609528
О, адепт "настоящего ООП" в треде. Давай, расскажи, как это здорово - падать в рантайме из-за того, что объект "не понял сообщение".
О, адепт "настоящего ООП" в треде. Давай, расскажи, как это здорово - падать в рантайме из-за того, что объект "не понял сообщение".
>>607925 (OP)
Изи пример. Я разрабатываю ЭБУ, а ты- фару. Мне нужно знать контракт, как управлять тобой: вкл/выкл/коррекция пучка света по вертикали. На остальное мне поебать, как оно там внутри тебя будет реализовано.
Это и есть инкапсуляция.
Далее. У тебя есть моделька самолета и ты просчитываешь, какой мощности должны быть двигатели. На остальное поебать: цвет самолета, количество мест, наличие биотуалетов.
Это и есть абстракция.
Далее. У тебя есть кошечка. Она родила котят. Все котята имеют хаост, усы, по два уха.
Это наследование.
Один котенок - бойкий альфач, а другой- омежка, как ты.
Это полиморфизм.
Изи пример. Я разрабатываю ЭБУ, а ты- фару. Мне нужно знать контракт, как управлять тобой: вкл/выкл/коррекция пучка света по вертикали. На остальное мне поебать, как оно там внутри тебя будет реализовано.
Это и есть инкапсуляция.
Далее. У тебя есть моделька самолета и ты просчитываешь, какой мощности должны быть двигатели. На остальное поебать: цвет самолета, количество мест, наличие биотуалетов.
Это и есть абстракция.
Далее. У тебя есть кошечка. Она родила котят. Все котята имеют хаост, усы, по два уха.
Это наследование.
Один котенок - бойкий альфач, а другой- омежка, как ты.
Это полиморфизм.
>>609551
Пчел, ты...
>Далее. У тебя есть кошечка. Она родила котят. Все котята имеют хаост, усы, по два уха.
>Это наследование.
>Один котенок - бойкий альфач, а другой- омежка, как ты.
>Это полиморфизм.
Пчел, ты...
>>609528
Не. Быдломассам лестно думать, будто-бы они решают дофига важную задачу в духе объективизЪма. Язык любой.
Не. Быдломассам лестно думать, будто-бы они решают дофига важную задачу в духе объективизЪма. Язык любой.
>>609539
Это настолько здорово, что адепты псевдо-ООП в любом серьезном проекте внедряют Пружину.
Это настолько здорово, что адепты псевдо-ООП в любом серьезном проекте внедряют Пружину.
>>609539
Полный бред. В рантайме падают только статические языки. Smalltalk по дефолту тебе просто покажет окошко что объект-name не может принять сообщение-name. Pharo, Ruby и Objective-C кидают исключения, которые можно поймать.
>падать в рантайме из-за того, что объект "не понял сообщение".
Полный бред. В рантайме падают только статические языки. Smalltalk по дефолту тебе просто покажет окошко что объект-name не может принять сообщение-name. Pharo, Ruby и Objective-C кидают исключения, которые можно поймать.
>>609587
И много конечный пользователь должен таких окошек поймать за программиста, который исправил бы это на этапе компиляции?
И много конечный пользователь должен таких окошек поймать за программиста, который исправил бы это на этапе компиляции?
>>609594
Почему нерабочий софт должен попасть к конечному пользователю?
Проблемы макак, которые не читают документацию и не пишут тесты для своего софта.
Почему нерабочий софт должен попасть к конечному пользователю?
Проблемы макак, которые не читают документацию и не пишут тесты для своего софта.
>>609528
ЯВА С СИСЯРПОМ НЕНАСТОЯЩЕЕ ООП
@
ЖС С КЛОЖЕЙ НАНСТОЯЩЕЕ ФП
@
ПОПИСЯТЬ С ПОКАКОЙТО НЕНАСТОЯЩАЯ ЖИЗНЬ
ЯВА С СИСЯРПОМ НЕНАСТОЯЩЕЕ ООП
@
ЖС С КЛОЖЕЙ НАНСТОЯЩЕЕ ФП
@
ПОПИСЯТЬ С ПОКАКОЙТО НЕНАСТОЯЩАЯ ЖИЗНЬ
>>609603
Запросто попадает. Много раз видел, как программы/либы, написанные на динамической дрисне и позволяющие вызывать несуществующие методы ("посылать сообщения объектам, которые не могут их принять", как вы это называете), срут в консоли, что такого-то метода нет. Спасибо хоть, что не все они аварийно завершаются после этого.
Проблема макак в том, что они выбирают языки, на которых прходится писать во много раз больше тестов. Но они этого не делают. На то они и макаки.
> Почему нерабочий софт должен попасть к конечному пользователю?
Запросто попадает. Много раз видел, как программы/либы, написанные на динамической дрисне и позволяющие вызывать несуществующие методы ("посылать сообщения объектам, которые не могут их принять", как вы это называете), срут в консоли, что такого-то метода нет. Спасибо хоть, что не все они аварийно завершаются после этого.
> Проблемы макак, которые не читают документацию и не пишут тесты для своего софта.
Проблема макак в том, что они выбирают языки, на которых прходится писать во много раз больше тестов. Но они этого не делают. На то они и макаки.
>>609610
Проблема в рукожопых макаках, а не языках. На любом языке можно написать программу или либу где будут глюки и вылеты.
Проблема в рукожопых макаках, а не языках. На любом языке можно написать программу или либу где будут глюки и вылеты.
>>609625
Именно что в языках. Одна и та же макака напишет на статическом языке более качественный продукт, чем на динамическом просто потому, что компилятор статического языка чаще будет бить макаку по пальцам, когда интерпретатор динамического будет молчать до последнего.
Именно что в языках. Одна и та же макака напишет на статическом языке более качественный продукт, чем на динамическом просто потому, что компилятор статического языка чаще будет бить макаку по пальцам, когда интерпретатор динамического будет молчать до последнего.
>>608094
Тип для чего? Для хранения? Для хранения подошла бы структура с 3 полями. Если нужно какое-то преобразование или получение даты, написал бы функцию. Но все подобные функции уже есть и работают со структурами (в си так). Ооп удобно, когда функционала много, а для простых задач вроде твоей, достаточно описанного выше.
Тип для чего? Для хранения? Для хранения подошла бы структура с 3 полями. Если нужно какое-то преобразование или получение даты, написал бы функцию. Но все подобные функции уже есть и работают со структурами (в си так). Ооп удобно, когда функционала много, а для простых задач вроде твоей, достаточно описанного выше.
>>609956
Удобно хранить тип данных, вместо с методами работы с ним. Очень блядь удобно. Невыносимо удобно.
Вот блядь некоторые предпочитают не писать велосипеды, а писать полезное ПО.
Это и есть ООП лол. прикинь да, в си в большинстве серьезных проектов пишут в ООП или с нехуевой примесью ООП
Удобно хранить тип данных, вместо с методами работы с ним. Очень блядь удобно. Невыносимо удобно.
>Если нужно какое-то преобразование или получение даты, написал бы функцию.
Вот блядь некоторые предпочитают не писать велосипеды, а писать полезное ПО.
>о все подобные функции уже есть и работают со структурами (в си так)
Это и есть ООП лол. прикинь да, в си в большинстве серьезных проектов пишут в ООП или с нехуевой примесью ООП
>>610096
Нееее, ты што, истинное ООП только в смоллтолке, а все остальные - жалкие подражатели с псевдо-ООП
Нееее, ты што, истинное ООП только в смоллтолке, а все остальные - жалкие подражатели с псевдо-ООП
>>609956
Вот тут возникает первая проблема. Данные внутри структуры должны быть согласованны, не может быть в сутках 27:83:132.
Это правильно, но тебе придется написать жирный комментарий: ВРУЧНУЮ ПОЛЯ СТРУКТУРЫ НЕ МЕНЯТЬ! Только через эти функции. Можно еще вести соглашение, например, именовать такие поля, начиная с нижнего подчеркивания: _hh, _mm, _ss. Но где гарантия, что все в проекте будут внимательно читать документацию, или кто-то посчитает, что он то уж точно знает, что делает и ему можно изменять эти поля. Приходится полагаться на внимательность, добросовестность, ум программиста. Но ведь лучше поручить контроль за доступом к полям структуры компилятору, пометив такие поля, как закрытые. Это первое свойство ООП - инкапсуляция.
>структура с 3 полями
Вот тут возникает первая проблема. Данные внутри структуры должны быть согласованны, не может быть в сутках 27:83:132.
>преобразование или получение даты, написал бы функцию
Это правильно, но тебе придется написать жирный комментарий: ВРУЧНУЮ ПОЛЯ СТРУКТУРЫ НЕ МЕНЯТЬ! Только через эти функции. Можно еще вести соглашение, например, именовать такие поля, начиная с нижнего подчеркивания: _hh, _mm, _ss. Но где гарантия, что все в проекте будут внимательно читать документацию, или кто-то посчитает, что он то уж точно знает, что делает и ему можно изменять эти поля. Приходится полагаться на внимательность, добросовестность, ум программиста. Но ведь лучше поручить контроль за доступом к полям структуры компилятору, пометив такие поля, как закрытые. Это первое свойство ООП - инкапсуляция.
>>610119
Так а структура тут при чем? Согласование еще происходит на этапе получения этой даты в специальной функции. Структура нужна только для хранения.
А где гарантия, что какой-нибудь самый умный не решит сделать все приватные поля класса публичными?
>Данные внутри структуры должны быть согласованны
Так а структура тут при чем? Согласование еще происходит на этапе получения этой даты в специальной функции. Структура нужна только для хранения.
>ВРУЧНУЮ ПОЛЯ СТРУКТУРЫ НЕ МЕНЯТЬ!
А где гарантия, что какой-нибудь самый умный не решит сделать все приватные поля класса публичными?
>>610432
По ТЗ эта структура должна быть изменяемой, к ней можно добавлять и отнимать секунды, минуты и часы.
Этот факт легко отследить. А вот если во многих местах программы кто попало вопреки соглашениям решил изменять условно-приватные поля, то уже гораздо труднее определить, в каком участке кода произошла ошибка.
>Структура нужна только для хранения.
По ТЗ эта структура должна быть изменяемой, к ней можно добавлять и отнимать секунды, минуты и часы.
>А где гарантия, что какой-нибудь самый умный не решит сделать все приватные поля класса публичными?
Этот факт легко отследить. А вот если во многих местах программы кто попало вопреки соглашениям решил изменять условно-приватные поля, то уже гораздо труднее определить, в каком участке кода произошла ошибка.
Как будто ООП это только классы. Это жи целая концепция в рамках которой надо уметь мыслить.
Наследование полиморфизм и инкапсуляция, аминь.
Все штуки нужные и реально используются на практике.
Как ты списки то наследовать будешь?
Наследование полиморфизм и инкапсуляция, аминь.
Все штуки нужные и реально используются на практике.
Как ты списки то наследовать будешь?
>>609639
>Именно что в языках
>Дебил купил права и въехал в столб на первом повороте.
>Виноват автомобиль.
>>610501
Эмм..., может быть создам новый список, который содержит в себе ссылку на старый?
> Как ты списки то наследовать будешь?
Эмм..., может быть создам новый список, который содержит в себе ссылку на старый?
>>610066
Ну засунь их в список.
Чё? В ооп типа методы для работы с данными сами пишутся?
Не
>Удобно хранить тип данных, вместо с методами работы с ним. Очень блядь удобно. Невыносимо удобно.
Ну засунь их в список.
>Вот блядь некоторые предпочитают не писать велосипеды, а писать полезное ПО.
Чё? В ооп типа методы для работы с данными сами пишутся?
>прикинь да, в си в большинстве серьезных проектов пишут в ООП или с нехуевой примесью ООП
Не
>>607925 (OP)
ООП нужен для управления сложностью большими проектами.
Пока ты пишешь лабы, странички магазинов и т.п. ты будешь удивляться зачем они нужны.
Когда ты пишешь что-то длиннее нескольких тысяч строк и это должно периодически меняться по желанию заказчика ты будешь удивляться как эти дебилы пытаются сделать что-то без ОПП.
ООП нужен для управления сложностью большими проектами.
Пока ты пишешь лабы, странички магазинов и т.п. ты будешь удивляться зачем они нужны.
Когда ты пишешь что-то длиннее нескольких тысяч строк и это должно периодически меняться по желанию заказчика ты будешь удивляться как эти дебилы пытаются сделать что-то без ОПП.
>>610590
Ты путаешь причину со следствием. Подушка безопасности не научит тебя водить машину.
Ты путаешь причину со следствием. Подушка безопасности не научит тебя водить машину.
>>610594
>Когда ты пишешь что-то длиннее нескольких тысяч строк и это должно периодически меняться по желанию заказчика ты будешь удивляться как эти дебилы пытаются сделать что-то без ОПП
>The Linux kernel
>Written in: C and assembly
>139 тысяч строк кода
>это чистое ядро
>с драйверами 15 миллионов
>>610603
И? Отсутствие классов в языке исключает возможность использовать объектно-ориентированный подход?
И? Отсутствие классов в языке исключает возможность использовать объектно-ориентированный подход?
>>610595
И её отсутствие не научит.
Сам факт того, что в языке статическая/динамическая типизация, ни на йоту не научит кого-то чему-то.
И её отсутствие не научит.
Сам факт того, что в языке статическая/динамическая типизация, ни на йоту не научит кого-то чему-то.
>>610623
Где я писал, что подушка научит?
Дебил с купленными правами будет дебилом с купленными правами на любой машине.
Где я писал, что подушка научит?
Дебил с купленными правами будет дебилом с купленными правами на любой машине.
>>608059
ФП позволяет делать все то же что и ООП. Не вижу у тебя аргументов за ООП. Как не вижу чтобы ты вообще понимал что это такое.
ФП позволяет делать все то же что и ООП. Не вижу у тебя аргументов за ООП. Как не вижу чтобы ты вообще понимал что это такое.
>>610672
Вообще-то дело в том, что фп реализуется в терминах ооп, и наоборот. Как машина тьюринга и лямбда-исчисление.
Замыкания - это "объекты для бедных", равно как и объекты - "замыкания для бедных".
>пукинчанский
Вообще-то дело в том, что фп реализуется в терминах ооп, и наоборот. Как машина тьюринга и лямбда-исчисление.
Замыкания - это "объекты для бедных", равно как и объекты - "замыкания для бедных".
>>610672
Машина Тьюринга не имеет такой гибкости как Комбинаторная логика, Лямбда-исчисление, Рекурсивные функции, которые позволяют из маленького ядра построить любую вычислительную систему. Грубо говоря, они позволяют строить свой язык программирования. Машина Тьюринга не дает такой гибкости. Машина Тьюринга это система с хранением состояния, а это противоречит математике. Состояние это зло, все ошибки происходят из-за него.
Машина Тьюринга не имеет такой гибкости как Комбинаторная логика, Лямбда-исчисление, Рекурсивные функции, которые позволяют из маленького ядра построить любую вычислительную систему. Грубо говоря, они позволяют строить свой язык программирования. Машина Тьюринга не дает такой гибкости. Машина Тьюринга это система с хранением состояния, а это противоречит математике. Состояние это зло, все ошибки происходят из-за него.
>>610694
Используется. Если ты не юзал или не видел, то это не значит, что этого не существует.
Используется. Если ты не юзал или не видел, то это не значит, что этого не существует.
>>610694
СИКП 3 глава. Первое издание выпущено в 1985 году. То есть уже тогда это использовали.
СИКП 3 глава. Первое издание выпущено в 1985 году. То есть уже тогда это использовали.
>>610689
Не совсем верно. Присвоения это можно и полезно, но только ИНОГДА БЛЯДЬ, а не как в императивных языках где оно везде: и к месту и не к месту.
Оно заебись тогда и только тогда, когда его отсутствие приводит к снижению модульности системы вследствие того, что потроха дочернего модуля (которые могли бы быть выражены стейтом) протекают в родительский.
Например какой-нибудь простенький ГСЧ: берёт текущее время в качестве зерна и делает случайное число. Если его сделать без присвоений, тогда мы вынуждены будем из родительского модуля явно передавать ему зерно, а значит родительский модуль должен будет сам его генерировать, а значит у нас устройство родительского модуля начинает зависеть от устройства дочернего. А ведь нам просто нужно было случайное число, нас не ебёт как там дочерний модуль его рожает.
Но для того чтобы просуммировать последовательность нам присвоение нахуй не всралось. Такие дела.
>Состояние это зло, все ошибки происходят из-за него.
Не совсем верно. Присвоения это можно и полезно, но только ИНОГДА БЛЯДЬ, а не как в императивных языках где оно везде: и к месту и не к месту.
Оно заебись тогда и только тогда, когда его отсутствие приводит к снижению модульности системы вследствие того, что потроха дочернего модуля (которые могли бы быть выражены стейтом) протекают в родительский.
Например какой-нибудь простенький ГСЧ: берёт текущее время в качестве зерна и делает случайное число. Если его сделать без присвоений, тогда мы вынуждены будем из родительского модуля явно передавать ему зерно, а значит родительский модуль должен будет сам его генерировать, а значит у нас устройство родительского модуля начинает зависеть от устройства дочернего. А ведь нам просто нужно было случайное число, нас не ебёт как там дочерний модуль его рожает.
Но для того чтобы просуммировать последовательность нам присвоение нахуй не всралось. Такие дела.
>>607925 (OP)
Что называется объекты завезли а соответствующее мышление не завезли. Как писали портянки процедурные так и пишем.
То что статические методы в принципе существуют (в джаве, которая на минуточку флагман и главный ооп язык) - уже символизирует полный и бесповоротный фейл ооп как парадигмы.
То есть у нас типа "всё есть объект", но на самом деле объекта нет а метод несуществующего объекта (т.е. по сути старую добрую процедуру из си) мы вызвать можем. Охуенно, заебись, дайте два. Зато мы не можем определить процедуру в глобальном скоупе (ты чё, у нас жи ооп). Но сделать ютилити класс и вызывать его методы, не создавая при этом объектов этго класса мы можем. Ага.
>ООП
>ряя инкапсуляция наследование полиморфизм
>открываешь какой-нибудь спринг
>FileUtils
>пошла простыня из статических методов
Что называется объекты завезли а соответствующее мышление не завезли. Как писали портянки процедурные так и пишем.
То что статические методы в принципе существуют (в джаве, которая на минуточку флагман и главный ооп язык) - уже символизирует полный и бесповоротный фейл ооп как парадигмы.
То есть у нас типа "всё есть объект", но на самом деле объекта нет а метод несуществующего объекта (т.е. по сути старую добрую процедуру из си) мы вызвать можем. Охуенно, заебись, дайте два. Зато мы не можем определить процедуру в глобальном скоупе (ты чё, у нас жи ооп). Но сделать ютилити класс и вызывать его методы, не создавая при этом объектов этго класса мы можем. Ага.
>>610753
А, да нет, я-то отвечал тому анону который говорил "все ошибки из-за стейта", неясно выразился короче.
А, да нет, я-то отвечал тому анону который говорил "все ошибки из-за стейта", неясно выразился короче.
>>610748
Нет, это символизирует, что нет универсальных парадигм. Когда борщехлёбы передают в функцию огромный тип с кучей полей, потому что нет классов, и рекурсивно вызывают эту функцию с немного изменённым состоянием, чтобы изменить значение одного поля, тоже ни о чём хорошем не говорит. По сути, они изменяют состояние вручную, как на сишке вручную пишут ООП.
> символизирует полный и бесповоротный фейл ооп как парадигмы
Нет, это символизирует, что нет универсальных парадигм. Когда борщехлёбы передают в функцию огромный тип с кучей полей, потому что нет классов, и рекурсивно вызывают эту функцию с немного изменённым состоянием, чтобы изменить значение одного поля, тоже ни о чём хорошем не говорит. По сути, они изменяют состояние вручную, как на сишке вручную пишут ООП.
>>610790
Я хуйню спорол, хотел сказать что то "ооп" со статическими методами это не ооп никакое, это процедурные портянки натянутые на "гыгы смарите можно кароче функцию в класс засунуть и тогда её вызывать нужно будет не через скобки а через точку"
Я хуйню спорол, хотел сказать что то "ооп" со статическими методами это не ооп никакое, это процедурные портянки натянутые на "гыгы смарите можно кароче функцию в класс засунуть и тогда её вызывать нужно будет не через скобки а через точку"
>>610817
Нет противоречий между ФП и настоящим ООП. Проблемы только с псевдо-ООП парашей.
https://lispcast.com/is-smalltalk-a-functional-language-is-lisp-object-oriented/
Нет противоречий между ФП и настоящим ООП. Проблемы только с псевдо-ООП парашей.
https://lispcast.com/is-smalltalk-a-functional-language-is-lisp-object-oriented/
>>610855
Основан он все равно на Лямбда-исчислении. Можно даже сказать, что это реализация Лямбда-исчисления. Лисп это не Common Lisp, это собирательное название семейства лиспоподобных языков.
Основан он все равно на Лямбда-исчислении. Можно даже сказать, что это реализация Лямбда-исчисления. Лисп это не Common Lisp, это собирательное название семейства лиспоподобных языков.
>>610872
https://medium.com/smalltalk-talk/lisp-smalltalk-and-the-power-of-symmetry-8bd96aaa0c0c
https://medium.com/smalltalk-talk/lisp-smalltalk-and-the-power-of-symmetry-8bd96aaa0c0c
>It’s true that the usual flavor of Object-Oriented Programming (“OOP,” as in “OOPs what was I thinking when I designed this class hierarchy”) has issues. Languages such as Java, C++, and even Python seem to think that “object-oriented” means mostly “classes and inheritance.” Which is sort of like saying that “driving” means mostly “buttons and pedals.” What most of these languages seem to miss is that Smalltalk’s class system, like Lisp’s macro system, is a symptom of the power already available in the language, not its cause. If it didn’t already have it, it wouldn’t really be that hard to add it in yourself.
>Without Smalltalk’s underlying fundamentals, class inheritance becomes nothing more than a tool for code reuse. As such, it is neither the only nor necessarily the best such tool. The real power of Smalltalk’s object system, including its classes, is not inheritance–it’s reflection. Just as Lisp macros are powerful because they can operate on any Lisp code, including themselves, Smalltalk classes are powerful because they themselves are objects. Smalltalk, like Lisp, runs in the same context it’s written in. It’s objects all the way down.
>>607925 (OP)
Положняк такой, есть 4 типа Ооп.
ООП-0 - оно же истинное ооп, придуманная теоретиками неюзабельная хуйня наравне с функциональщиной.
ООП-1 - классическое, классовое, реализованное практиками, получило наиболее широкое распространение благодаря c++/java/c#.
ООП-2 - прототипное. Попытка отказаться от классов, применяется в скриптовых языках, особой популярностью не пользуется, даже в js классы добавили.
ООП-3 - различные попытки побороть сложность и проблемы, порожденные классическим ооп-1, главным образом за счет отказа от наследования (go, rust). Пока еще мир не завоевало.
Положняк такой, есть 4 типа Ооп.
ООП-0 - оно же истинное ооп, придуманная теоретиками неюзабельная хуйня наравне с функциональщиной.
ООП-1 - классическое, классовое, реализованное практиками, получило наиболее широкое распространение благодаря c++/java/c#.
ООП-2 - прототипное. Попытка отказаться от классов, применяется в скриптовых языках, особой популярностью не пользуется, даже в js классы добавили.
ООП-3 - различные попытки побороть сложность и проблемы, порожденные классическим ооп-1, главным образом за счет отказа от наследования (go, rust). Пока еще мир не завоевало.
>>610582
Это композиция
Это композиция
>>610855
Следовательно ооп нигде не используется, следовательно мы никуда не уходили из мира процедурного программирования.
Модульность есть и в си - вот тебе процедура, вот тебе файл который можно компилировать отдельно от других.
Объекты это модульность в чистом виде и есть, если у тебя проблемы с тем, чтобы обернуть класс в класс-декоратор, который будет добавлять нужный функционал, не нарушая SRP, то у меня для тебя плохие новости - ты не можешь в объектную модульность, ты можешь только в процедурную модульность, поэтому создавай файл с расширением .с и пиши свою хуйню туда.
>рассматривали классы не только с позиции ООП
Следовательно ооп нигде не используется, следовательно мы никуда не уходили из мира процедурного программирования.
Модульность есть и в си - вот тебе процедура, вот тебе файл который можно компилировать отдельно от других.
Объекты это модульность в чистом виде и есть, если у тебя проблемы с тем, чтобы обернуть класс в класс-декоратор, который будет добавлять нужный функционал, не нарушая SRP, то у меня для тебя плохие новости - ты не можешь в объектную модульность, ты можешь только в процедурную модульность, поэтому создавай файл с расширением .с и пиши свою хуйню туда.
>>611227
https://youtu.be/BwPT8_bB8dY?t=501
Юра, ты как в этот тред-то пролез?
>придуманная теоретиками неюзабельная хуйня
https://youtu.be/BwPT8_bB8dY?t=501
Юра, ты как в этот тред-то пролез?
>>611280
Молишься на заокеанского бога?
Молишься на заокеанского бога?
>>611290
Что он преподает, смолтолк что-ли?
Что он преподает, смолтолк что-ли?
6 Кб, 996x43>>611254
Знаешь как сомнения прояснить? Открой да посмотри
Вангую сейчас начнётся "ряя на любом йазыке можно песать ооп, там тожи йесть элименты ооп", только из элементов ооп там только абстракция (которая свойственная программированию как таковому, не только ооп)
>Сомневаюсь
Знаешь как сомнения прояснить? Открой да посмотри
Вангую сейчас начнётся "ряя на любом йазыке можно песать ооп, там тожи йесть элименты ооп", только из элементов ооп там только абстракция (которая свойственная программированию как таковому, не только ооп)
Ну я даже не знаю. Работаю .NET макакой второй год, вторая кампания ради зп ушел. Так вот на новой работе на столько издеваются с ASP NET MVC, что они нахуй стейты притащили из ебаных WinForms. Логика размазана по нескольким либам и неймспасам, проблема в том, что оно всё параллельно растет и дуплицирует друг друга и у нас десятки классов, которые должны были быть одним и чтобы просто дернуть table из дб мне нужно через 5 кругов велосипедных абстракций проходить entity не завезли. Нахуй оно надо. Я не говорю, что class based OOP заставляет так писать, но как правило так пишут. Даже на C++ с классами так хуево все не размывают в спагетти, как на Шарпе.
Конечно, анон сейчас скажет, мол ты кампанию хуевую выбрал, но это моя последняя работа в энтерпрайзе и последняя работа с мейнстрим ООП языками.
Конечно, анон сейчас скажет, мол ты кампанию хуевую выбрал, но это моя последняя работа в энтерпрайзе и последняя работа с мейнстрим ООП языками.
>>610924
То есть теперь рефлексия это чисто ОО-фишка?
То есть теперь рефлексия это чисто ОО-фишка?
>>610891
Так смешно наблюдать как ОО-дауны переобуваются последние 30 лет, как только их начали макать в собственное говно.
>Классы это не ООП
>они две недели назад сам уволились
Так смешно наблюдать как ОО-дауны переобуваются последние 30 лет, как только их начали макать в собственное говно.
>>611506
Это называется развитие.
И только шизы-ФПшники, у которых развития нет, будут упорствовать в своём невежестве до последнего.
> переобуваются
Это называется развитие.
И только шизы-ФПшники, у которых развития нет, будут упорствовать в своём невежестве до последнего.
>>611506
Фактически классы это необязательная (а по мнению некоторых и нежелательная) фича.
Для реализации ооп классы необязательны. Может существовать система, при которой класса как такового нет, а есть первый объект, и последующие объекты, создаваемые по образу первого. И чего мы при таком подходе лишаемся, так это возможности лепить статические методы (нет класса - нет статических методов, их просто некуда писать), а это как раз замечательно.
Потому что "статические методы" должны быть процедурами, коими они концептуально являются, так что программист сразу видит "ага, тут я написал процедуру, следовательно я обосрался".
Фактически классы это необязательная (а по мнению некоторых и нежелательная) фича.
Для реализации ооп классы необязательны. Может существовать система, при которой класса как такового нет, а есть первый объект, и последующие объекты, создаваемые по образу первого. И чего мы при таком подходе лишаемся, так это возможности лепить статические методы (нет класса - нет статических методов, их просто некуда писать), а это как раз замечательно.
Потому что "статические методы" должны быть процедурами, коими они концептуально являются, так что программист сразу видит "ага, тут я написал процедуру, следовательно я обосрался".
>>611375
https://github.com/github/linguist
https://github.com/github/linguist
>The percentages are calculated based on the bytes of code for each language as reported by the List Languages API.
112 Кб, 1948x858>>611509
Лол. Таким макаром, лет через цать, окажется, что ооп это фп.
>>611523
Ты сам понимаешь, что ты пишешь?
Во первых, чтобы избавиться от статических методов-процедур необязательно избавляться от классов, но это не имеет значения, т.к. ООП это всего лишь надстройка над процедурной парадигмой. Под ООП всегда подразумевалось, подразумевается и будет подразумеваться как бы вы не старались, маньки мутабельные структы со связанным неймспейсом, в котором определены процедуры-методы, меняющие поля структа. Т.е. ты всегда пишешь в процедурном стиле, если ты пишешь ООП, вне зависимости от того определяешь ты статические или обычные методы.
Таким образом ООП наследует и преумножает все проблемы процедурной парадигмы.
>развитие
Лол. Таким макаром, лет через цать, окажется, что ооп это фп.
>>611523
Ты сам понимаешь, что ты пишешь?
Во первых, чтобы избавиться от статических методов-процедур необязательно избавляться от классов, но это не имеет значения, т.к. ООП это всего лишь надстройка над процедурной парадигмой. Под ООП всегда подразумевалось, подразумевается и будет подразумеваться как бы вы не старались, маньки мутабельные структы со связанным неймспейсом, в котором определены процедуры-методы, меняющие поля структа. Т.е. ты всегда пишешь в процедурном стиле, если ты пишешь ООП, вне зависимости от того определяешь ты статические или обычные методы.
Таким образом ООП наследует и преумножает все проблемы процедурной парадигмы.
>>611552
Не окажется. Чистое ФП не работает, и ООП никогда к такому не придёт.
> лет через цать, окажется, что ооп это фп
Не окажется. Чистое ФП не работает, и ООП никогда к такому не придёт.
>>611552
Никто не говорил что от классов обязательно надо избавляться (мнения на этот счёт расходятся), а из тех, кто всё-таки говорил, никто не утверждал что от классов надо избавляться чисто ради того, чтобы порезать статические методы (их можно и без этого убрать)
Да, да, конечно. Извини что тебя затронул. Все будет как ты скажешь.
>>611561
Оно и не должно быть чистым. Стейт в ряде случаев предпочтителен.
> Во первых, чтобы избавиться от статических методов-процедур необязательно избавляться от классов
Никто не говорил что от классов обязательно надо избавляться (мнения на этот счёт расходятся), а из тех, кто всё-таки говорил, никто не утверждал что от классов надо избавляться чисто ради того, чтобы порезать статические методы (их можно и без этого убрать)
>ООП всегда подразумевалось, подразумевается и будет подразумеваться
Да, да, конечно. Извини что тебя затронул. Все будет как ты скажешь.
>>611561
>Чистое ФП не работает
Оно и не должно быть чистым. Стейт в ряде случаев предпочтителен.
193 Кб, 1200x1200>>611552
Наследование нужно избегать, это уже сказали. Но бывают случае когда оно нужно и удобно.
Именно поэтому нужны мультипарадигменные языки и с ООП и с ФП.
Из ООП прижился полиморфизм на интерфейсах. Из ФП лямбды, замыкание.
В котлине все классы закрыты по-умолчанию. А дата-классы не наследуются (являются структурами). При этом есть и функции и лямбды.
И что самое мне нравится, можно сделать "жирные функции", то есть когда можешь указать параметры kwargs
foo("my value", end="\n", sep="/")
Наследование нужно избегать, это уже сказали. Но бывают случае когда оно нужно и удобно.
Именно поэтому нужны мультипарадигменные языки и с ООП и с ФП.
Из ООП прижился полиморфизм на интерфейсах. Из ФП лямбды, замыкание.
В котлине все классы закрыты по-умолчанию. А дата-классы не наследуются (являются структурами). При этом есть и функции и лямбды.
И что самое мне нравится, можно сделать "жирные функции", то есть когда можешь указать параметры kwargs
foo("my value", end="\n", sep="/")
>>611569
А еще из ООП прижалась инкапсуляция.
А еще из ООП прижалась инкапсуляция.
>>611565
Тогда это уже не кукарекание про самую лучшую парадигму, а выбор инструментов под задачи. К чему программирование идёт, так это к мультипарадигменности уже.
> Оно и не должно быть чистым. Стейт в ряде случаев предпочтителен.
Тогда это уже не кукарекание про самую лучшую парадигму, а выбор инструментов под задачи. К чему программирование идёт, так это к мультипарадигменности уже.
>>611571
Ни у кого, кроме борщехлёбов, оно не работает. Ни одного крупного проекта на чистом ФП без костылей и извращений не написано.
Ни у кого, кроме борщехлёбов, оно не работает. Ни одного крупного проекта на чистом ФП без костылей и извращений не написано.
>>611574
Об этом речь и идёт. Использовать фп везде, где можно - это гуд. Использовать процедуроговнецо там, где без проблем можно писать функционально - не гуд.
>а выбор инструментов под задачи
Об этом речь и идёт. Использовать фп везде, где можно - это гуд. Использовать процедуроговнецо там, где без проблем можно писать функционально - не гуд.
>>611576
Мантры
Мантры
>>611581
Вот бы ещё те, у кого оно работает, показали хоть один пример, а то остаётся только на слово верить.
Вот бы ещё те, у кого оно работает, показали хоть один пример, а то остаётся только на слово верить.
>>610869
Ты заебал, смолток в могиле посылает сам себе сообщения, обж-с скоро к нему присоединится. Этого шизика послушать, так ООП это любая актор-бейсед хуйня, например ерланг. Но факт в том, что 99% программистов услышав слово ООП подумают про джаву, кресты и пхп, а не про ерланг. Можно конечно жить в альтернативном манямирке, где голова это на самом деле жопа и просто никто об этом не знает. Я понимаю почему так может считать Алан Кей, старческая деменция, маразм, вся хуйня, вон его кореш Тед Нельсон ещё больше поехал со своим Xanadu, на который всю жизнь вьебал, а оно никому нахуй не нужно, теперь ходит как дурачек всем рассказывает что НАСТОЯЩИЙ интернет и гиперссылки это вообще не то что все думают, но вот уебанов, которые транслируют старческие бредни я понять не могу.
Ты заебал, смолток в могиле посылает сам себе сообщения, обж-с скоро к нему присоединится. Этого шизика послушать, так ООП это любая актор-бейсед хуйня, например ерланг. Но факт в том, что 99% программистов услышав слово ООП подумают про джаву, кресты и пхп, а не про ерланг. Можно конечно жить в альтернативном манямирке, где голова это на самом деле жопа и просто никто об этом не знает. Я понимаю почему так может считать Алан Кей, старческая деменция, маразм, вся хуйня, вон его кореш Тед Нельсон ещё больше поехал со своим Xanadu, на который всю жизнь вьебал, а оно никому нахуй не нужно, теперь ходит как дурачек всем рассказывает что НАСТОЯЩИЙ интернет и гиперссылки это вообще не то что все думают, но вот уебанов, которые транслируют старческие бредни я понять не могу.
>>611584
Кстати, неоднократно натыкался на тех, кто реально так считает и проводит в пример эрланг.
мимо
> Этого шизика послушать, так ООП это любая актор-бейсед хуйня, например ерланг.
Кстати, неоднократно натыкался на тех, кто реально так считает и проводит в пример эрланг.
мимо
353 Кб, 1250x1250>>611589
https://pl.kotl.in/hclcmiTPB
https://pl.kotl.in/JCIfJovQW
>Проблема проектирования "какающей лошади и летающего пегаса"
>Решение через наследование
https://pl.kotl.in/hclcmiTPB
>Решение через делегирование
https://pl.kotl.in/JCIfJovQW
>>611597
А вот в пщ-треде как раз заливают, что либы для джавы - это ненужное легаси, а отсутствие либ в пщ - это на самом деле фича такая.
А вот в пщ-треде как раз заливают, что либы для джавы - это ненужное легаси, а отсутствие либ в пщ - это на самом деле фича такая.
>>611607
У меня разный, проверил даже без кук. Переоткрой
У меня разный, проверил даже без кук. Переоткрой
>>611608
Котлин не сможет себе прибрать к рукам жвм - засудят.
А оракл может плохо отреагировать, если котлин помимо андроида еще в энтерпрайз ворвется. Поэтому непонятно что будет в будущем.
Котлин не сможет себе прибрать к рукам жвм - засудят.
А оракл может плохо отреагировать, если котлин помимо андроида еще в энтерпрайз ворвется. Поэтому непонятно что будет в будущем.
>>611608
Уже представляю новость "Оракл подал в суд на жетбреинс за использование платформы Java".
Уже представляю новость "Оракл подал в суд на жетбреинс за использование платформы Java".
>>611610
Лол, вчера с десяток строк в градле добавил пачку либ, которые я писал бы так же качественно, наверное, год.
То есть, те либы мне сэкономили тысячи человеко часов работы.
Конечно, наличие большого числа библиотек это зло, питонисты тоже согласяться. гоферы ебанутые
Лол, вчера с десяток строк в градле добавил пачку либ, которые я писал бы так же качественно, наверное, год.
То есть, те либы мне сэкономили тысячи человеко часов работы.
Конечно, наличие большого числа библиотек это зло, питонисты тоже согласяться. гоферы ебанутые
>>611610
Потому что в самой компании гугол тебе любую либу напишут за один час. Но на гитхаб не выложат.
>а отсутствие либ в пщ - это на самом деле фича такая.
Потому что в самой компании гугол тебе любую либу напишут за один час. Но на гитхаб не выложат.
>>611614
OpenJDK может
Оракл уже реагирует, пилит тонну фич в джаву и релизит каждые полгода как не в себе (смотри видос про планы до 2024). Конкуренция это хорошо.
Котлин это не только JVM, это и native и js.
>Котлин не сможет себе прибрать к рукам жвм
OpenJDK может
>А оракл может плохо отреагировать.
Оракл уже реагирует, пилит тонну фич в джаву и релизит каждые полгода как не в себе (смотри видос про планы до 2024). Конкуренция это хорошо.
Котлин это не только JVM, это и native и js.
>>611620
Они ее не смогут изменять сильно, иначе не пройдут тесты совместимости и их засудят. А менять только один синтаксис, ну такое.
> >Котлин не сможет себе прибрать к рукам жвм
> OpenJDK может
Они ее не смогут изменять сильно, иначе не пройдут тесты совместимости и их засудят. А менять только один синтаксис, ну такое.
>>611619
Вот и получается, что пщ - это язык исключительно для внутренних нужд гугла. А кто ещё его юзает - тот ССЗБ.
Вот и получается, что пщ - это язык исключительно для внутренних нужд гугла. А кто ещё его юзает - тот ССЗБ.
>>611625
Нет, компилятор в js, по типу ts или dart
Нет, компилятор в js, по типу ts или dart
>>611622
Зачем менять? Философия котлина зиждется на совместимости с джавой. Я даже не переписывал код на котлин, у меня так джава и котлин вместе
Зачем менять? Философия котлина зиждется на совместимости с джавой. Я даже не переписывал код на котлин, у меня так джава и котлин вместе
>>611640
Но это пока совместимость выгодна котлину. А вот если со временем все популярные библиотеки и множество проектов перепишут на котлю, что тогда? Поглощать оракл?
Но это пока совместимость выгодна котлину. А вот если со временем все популярные библиотеки и множество проектов перепишут на котлю, что тогда? Поглощать оракл?
>>607925 (OP)
Если говорим про реальную пользу для работы, то нужно для того, чтобы ты, в теории, мог расширять функциональность без лишних телодвижений.
Еще можно всякие прикольные штуки, типа внедрения зависимостей делать, благодаря этой хуйне все вообще классно выходит: Скажем, ты написал лог, вынес на уровень интерфейса базовое описание лога:
interface ILog{
void Write(LogLevel level, string message);
}
Потом ты сделал импплементацию этого лога в виде класса ConsoleLog, человек который пользуется интерфейсом, заинжектил этот класс, год все было хорошо, но теперь ваше приложение должно работать как сервис и встала задача писать лог не в консоль, а в файл, еще и в json - формате. Ты за часик сделал новую имплементацию JsonFileLog, и человек просто заинжектил новый класс, при этом в классе, что использует лог ничего не поменялось, но теперь лог пишется в файл. Красота же. А если у вас крутой архитектор, то вы вообще давно сделали так, что для замены лога можно просто прописать в конфигурационном файле какой лог брать в случае запуска и даже пересобирать не придется, ты просто кинешь dll куда надо, в конфиг файле добавишь пару строчек и у клиента теперь лог пишется в файл.
Далеко не одна и та же.
> Для чего нужно ООП?
Если говорим про реальную пользу для работы, то нужно для того, чтобы ты, в теории, мог расширять функциональность без лишних телодвижений.
Еще можно всякие прикольные штуки, типа внедрения зависимостей делать, благодаря этой хуйне все вообще классно выходит: Скажем, ты написал лог, вынес на уровень интерфейса базовое описание лога:
interface ILog{
void Write(LogLevel level, string message);
}
Потом ты сделал импплементацию этого лога в виде класса ConsoleLog, человек который пользуется интерфейсом, заинжектил этот класс, год все было хорошо, но теперь ваше приложение должно работать как сервис и встала задача писать лог не в консоль, а в файл, еще и в json - формате. Ты за часик сделал новую имплементацию JsonFileLog, и человек просто заинжектил новый класс, при этом в классе, что использует лог ничего не поменялось, но теперь лог пишется в файл. Красота же. А если у вас крутой архитектор, то вы вообще давно сделали так, что для замены лога можно просто прописать в конфигурационном файле какой лог брать в случае запуска и даже пересобирать не придется, ты просто кинешь dll куда надо, в конфиг файле добавишь пару строчек и у клиента теперь лог пишется в файл.
> Почему пользоваться классами и объектами, а не допустим списками? Ведь суть одна и та же.
Далеко не одна и та же.
>>611697
Если бы ты со своей шмоней не пиздел лишнего, то и не пошел бы на хуй. П
Если бы ты со своей шмоней не пиздел лишнего, то и не пошел бы на хуй. П
>>611584
И кого это должно волновать? Мне, например, похую.
99% программистов живут, и чё?
Нацистская германия жила почти в полном составе в альтернативном манямире где арийцы это богоизбранная высшая раса.
Веганы живут в манямире где мясо несъедобно.
Вот только ты верно заметил - от того, что 99% назовут голову жопой, она не станет жопой, а останется головой.
>Но факт в том, что 99% программистов услышав слово ООП подумают про джаву, кресты и пхп
И кого это должно волновать? Мне, например, похую.
>Можно конечно жить в альтернативном манямирке, где голова это на самом деле жопа и просто никто об этом не знает
99% программистов живут, и чё?
Нацистская германия жила почти в полном составе в альтернативном манямире где арийцы это богоизбранная высшая раса.
Веганы живут в манямире где мясо несъедобно.
Вот только ты верно заметил - от того, что 99% назовут голову жопой, она не станет жопой, а останется головой.
>>611717
Ты сам начал оскорбления. Теперь не обижайся.
Ты сам начал оскорбления. Теперь не обижайся.
>>611615
Да я ёбу дал, не реализуется. Только наоборот
Да я ёбу дал, не реализуется. Только наоборот
>>611307
А на весну это чем похоже?
А на весну это чем похоже?
>>611584
Он на Лиспе всю жизнь пишет.
> Я понимаю почему так может считать Алан Кей, старческая деменция, маразм, вся хуйня
Он на Лиспе всю жизнь пишет.
1
>>611668
Нет, ну вот котлин и джава совместимы. Можно оставлять джаву в проекте, а новые вещи писать на котлине.
Вдруг жетбраинс захотят сделать какие-то глобальные фичи на уровне jvm.
Вот дженерики нормальные сделать! Тут без изменений в машине ну никак.
Нет, ну вот котлин и джава совместимы. Можно оставлять джаву в проекте, а новые вещи писать на котлине.
Вдруг жетбраинс захотят сделать какие-то глобальные фичи на уровне jvm.
Вот дженерики нормальные сделать! Тут без изменений в машине ну никак.
>>611824
Они не хотят, мало того что это нарушит лицензии там какие-то, так это еще похерит совместимость со всей джавой.
Поверь, именно это они делать не будут.
>Вдруг жетбраинс захотят сделать какие-то глобальные фичи на уровне jvm.
Они не хотят, мало того что это нарушит лицензии там какие-то, так это еще похерит совместимость со всей джавой.
Поверь, именно это они делать не будут.
>>611645
А чем это джавовые дженерики неполноценные? Тем что инфа в рантайме вырезается? Так это только и дает возможность сделать продвинутые системы типов, как в скале, например. А том же дотнете в F# как раз не завезли типы высших рангов из-за того, что шарповые дженерики реифицируются.
Если язык достаточно выразительный, то инфо по полиморфным типам можно пихать в рантайм опционально с помощью вшитых в язык ad-hoc решений (звучит плохо, но на деле не так страшно). Примеры: Scala (ClassTag, TypeTag), Haskell (Generic)
То, что реификация дженериков необходима - популярное заблуждение.
А чем это джавовые дженерики неполноценные? Тем что инфа в рантайме вырезается? Так это только и дает возможность сделать продвинутые системы типов, как в скале, например. А том же дотнете в F# как раз не завезли типы высших рангов из-за того, что шарповые дженерики реифицируются.
Если язык достаточно выразительный, то инфо по полиморфным типам можно пихать в рантайм опционально с помощью вшитых в язык ad-hoc решений (звучит плохо, но на деле не так страшно). Примеры: Scala (ClassTag, TypeTag), Haskell (Generic)
То, что реификация дженериков необходима - популярное заблуждение.
>>611897
Лисп не универсальный наверное нихуя? То ли ты меня троллишь, то ли я пытаюсь. Не, нахуй не нужно. Лисп это батя.
Лисп не универсальный наверное нихуя? То ли ты меня троллишь, то ли я пытаюсь. Не, нахуй не нужно. Лисп это батя.
>>612090
Если честно, никогда не понимал этот прикол.
Если честно, никогда не понимал этот прикол.
>>611584
ООП - это когда ты в своем коде можешь выполнять полиморфную функцию, не объявляя прямой зависимости на эту функцию. Так что да, эрланг и акторы - это ООП.
То есть когда один выдающийся человек с именем высказывает мнение, то это автоматически маразм, но когда 99% (высранных тобой из жопы) абстрактных людей, высказывают мнение - это автоматически правда? Ты дурачок?
>ООП это любая актор-бейсед хуйня, например ерланг
ООП - это когда ты в своем коде можешь выполнять полиморфную функцию, не объявляя прямой зависимости на эту функцию. Так что да, эрланг и акторы - это ООП.
>Я понимаю почему так может считать Алан Кей, старческая деменция, маразм
>Но факт в том, что 99% программистов
То есть когда один выдающийся человек с именем высказывает мнение, то это автоматически маразм, но когда 99% (высранных тобой из жопы) абстрактных людей, высказывают мнение - это автоматически правда? Ты дурачок?
>>612177
Работодателю, например.
Работодателю, например.
>>612177
Профессии.
Профессии.
>>612090
Хороший комикс, забавно и без злобы.
Хороший комикс, забавно и без злобы.
>>612292
Любая модуляризация кода увеличивает его пригодность для командной работы, даже процедурная абстракция.
Любая модуляризация кода увеличивает его пригодность для командной работы, даже процедурная абстракция.
>>611732
>>612141
Дебилушка, смолток проиграл потому что это было ультратормозное говнище, и vtables с early-binding по дефолту тупо быстрее. Во-вторых, это просто квинтэссенция динамического петушения когда что угодно может вызывать послать сообщение чему угодно, сообщение может перехватить что угодно и ответить что угодно, самостоятельно решая что ошибка, а что нет.
Ну то есть программировать на этом может быть весело, но для разработки и поддержки реальных систем - это слишком дорого и хуёво.
Единственный способ его реанимировать - всё покрыть хотя бы простой типизацией, вынести месседж пассинг дрисню в отдельное подмножество языка и тоже типизировать. То есть получился бы Kotlin + Typed Akka.
>>612141
Дебилушка, смолток проиграл потому что это было ультратормозное говнище, и vtables с early-binding по дефолту тупо быстрее. Во-вторых, это просто квинтэссенция динамического петушения когда что угодно может вызывать послать сообщение чему угодно, сообщение может перехватить что угодно и ответить что угодно, самостоятельно решая что ошибка, а что нет.
Ну то есть программировать на этом может быть весело, но для разработки и поддержки реальных систем - это слишком дорого и хуёво.
Единственный способ его реанимировать - всё покрыть хотя бы простой типизацией, вынести месседж пассинг дрисню в отдельное подмножество языка и тоже типизировать. То есть получился бы Kotlin + Typed Akka.
>>612512
Нахуя ты к двоим обращаешься в единственном числе?
Нахуя ты к двоим обращаешься в единственном числе?
>>612512
А почему тогда Эрланг используют?
>Ну то есть программировать на этом может быть весело, но для разработки и поддержки реальных систем - это слишком дорого и хуёво.
А почему тогда Эрланг используют?
>>612524
А ерланге хотя бы разделение есть: вызов функций - это вызов функций, а посылка сообщений - это посылка сообщений.
Плюс в ерланге акторы были чтоб обеспечить конкаренси, изоляцию и, как результат, отказоустойчивость, а в смолтолке не было ничего из этого, зато были акторы для всего просто чтоб были.
А ерланге хотя бы разделение есть: вызов функций - это вызов функций, а посылка сообщений - это посылка сообщений.
Плюс в ерланге акторы были чтоб обеспечить конкаренси, изоляцию и, как результат, отказоустойчивость, а в смолтолке не было ничего из этого, зато были акторы для всего просто чтоб были.
>>611584
В средневековье 99% жителей планеты думали что Солнце вращается вокруг Земли.
>факт в том, что 99% программистов услышав слово ООП подумают про джаву, кресты и пхп
В средневековье 99% жителей планеты думали что Солнце вращается вокруг Земли.
>>612512
Как же оно тогда работало на Xerox Alto? Первая ОС где окна можно двигать мышью по экрану была написана на SmallTalk.
Молчал бы с этим убогим говном для индусов
>это было ультратормозное говнище
Как же оно тогда работало на Xerox Alto? Первая ОС где окна можно двигать мышью по экрану была написана на SmallTalk.
> Kotlin
Молчал бы с этим убогим говном для индусов
>>612867
А сейчас 99% думает что земля вращается вокруг солнца (хотя реально вокруг центра масс солнечной системы, не всегда находящегося внутри гелиосферы), но считает себя умнее. Дебичи не меняются.
А сейчас 99% думает что земля вращается вокруг солнца (хотя реально вокруг центра масс солнечной системы, не всегда находящегося внутри гелиосферы), но считает себя умнее. Дебичи не меняются.
>>612877
И вполне обоснованно. Считать, что земля вращается вокруг Солнца умнее, чем наоборот.
>но считает себя умнее
И вполне обоснованно. Считать, что земля вращается вокруг Солнца умнее, чем наоборот.
>>612877
Так-то есть центр массы галактики и Земля вращается вокруг него, что не мешает ей ещё и вращаться вокруг Солнца. Вот, кстати, интересный вопрос про центр массы вселенной: есть ли он (если не брать за центр вселенной мой хуец, бтв) и будет ли правильно строить модель движения вокруг него?
Так-то есть центр массы галактики и Земля вращается вокруг него, что не мешает ей ещё и вращаться вокруг Солнца. Вот, кстати, интересный вопрос про центр массы вселенной: есть ли он (если не брать за центр вселенной мой хуец, бтв) и будет ли правильно строить модель движения вокруг него?
>>612976
Если считать вселенную более менее однородной, то центр обозреваемой вселенной где? ... Бинго, you name it, это Земля.
Если считать вселенную более менее однородной, то центр обозреваемой вселенной где? ... Бинго, you name it, это Земля.
>>612979
Но она неоднородна, бесконечное расширение - функция от времени, там где время минимально - масса черных дыр должна быть больше, а значит это и есть центр вселенной?
Но она неоднородна, бесконечное расширение - функция от времени, там где время минимально - масса черных дыр должна быть больше, а значит это и есть центр вселенной?
>>612999
Я залез и педивикию и таки
Я залез и педивикию и таки
>но в 1990-е Маргарет Геллер и Джон Хукра выяснили, что на масштабах порядка 300 мегапарсеков Вселенная практически однородна[4]
>>613005
Это теория из 90, сейчас не всё так однозначно, см.`Великая стена Геркулес-Северная корона`.
Это теория из 90, сейчас не всё так однозначно, см.`Великая стена Геркулес-Северная корона`.
>>613000
В сравнении с BCPL медленнее.
В сравнении с BCPL медленнее.
>>613031
Ну так это собственно сабж. А я хотел посмотреть хотя бы CRUD проект на смоллтоке, а не на сишку.
Ну так это собственно сабж. А я хотел посмотреть хотя бы CRUD проект на смоллтоке, а не на сишку.
>>613038
Пусть индусы на яве пишут.
https://github.com/feenkcom/gtoolkit
https://github.com/PolyMathOrg/PolyMath
>CRUD
Пусть индусы на яве пишут.
https://github.com/feenkcom/gtoolkit
https://github.com/PolyMathOrg/PolyMath
>>613076
Вот это мощный язык, современные теперь кажутся упрощенными для идиотов.
Вот это мощный язык, современные теперь кажутся упрощенными для идиотов.
ООП решает проблему локализации кода путём нагромождения миллиона нелокализованных объектов в каждый проект и оверрайда операндов так чтобы было непонятно что они делают. ООП появился из-за общего желания поменьше думать об имплементации и побольше использовать крутые плюшки.
>>613297
операторов в смысле.
операторов в смысле.
>>613297
Если при проектировании возникает вопрос "что достойно отдельного объекта?"
Ответ на него достаточно прост. Объекта достойно всё.
Если при проектировании возникает вопрос "что достойно отдельного объекта?"
Ответ на него достаточно прост. Объекта достойно всё.
>>612867
Охуенные у тебя аналогии.
Вращение Земли вокруг Солнца - проверяемый факт, определение оопе - придуманная людьми гуманитарная хуйня и споры о том что же такое НАСТОЯЩЕЕ оопе , это как споры как звучит НАСТОЯЩИЙ готик-рок или что НА САМОМ ДЕЛЕ изображено на картине очередного абстракциониста.
Охуенные у тебя аналогии.
Вращение Земли вокруг Солнца - проверяемый факт, определение оопе - придуманная людьми гуманитарная хуйня и споры о том что же такое НАСТОЯЩЕЕ оопе , это как споры как звучит НАСТОЯЩИЙ готик-рок или что НА САМОМ ДЕЛЕ изображено на картине очередного абстракциониста.
>>607925 (OP)
Основная причина использования ООП - это переиспользование кода. ООП свободно позволяет это делать за счет полиморфизма, наследования и инкапсуляции.
>Для чего нужно ООП?
>Какие проблемы и задачи оно решает?
Основная причина использования ООП - это переиспользование кода. ООП свободно позволяет это делать за счет полиморфизма, наследования и инкапсуляции.
>>613461
Нужно для полноценной реализации полиморфизма
Сокрытие деталей имплементации.
>Наследование говно
Нужно для полноценной реализации полиморфизма
>инкапсуляия это сокрытие
Сокрытие деталей имплементации.
>>613747
Попался! Это в первую очередь объединение данных и кода, манипулирующий ими.
Сокрытие там как фича.
А то, что это только сокрытие учат только на говнокурсах.
>Сокрытие деталей имплементации.
Попался! Это в первую очередь объединение данных и кода, манипулирующий ими.
Сокрытие там как фича.
А то, что это только сокрытие учат только на говнокурсах.
>>613848
Если нет инкапсуляции, то сокрытие равноценно не использованию данного типа данных практически свой None. Инкапсуляция в обоих смыслах возможна даже в процедурном C. Другое дело реализовано ли на уровне классов встроенных в язык или каким либо другим способом.
Если нет инкапсуляции, то сокрытие равноценно не использованию данного типа данных практически свой None. Инкапсуляция в обоих смыслах возможна даже в процедурном C. Другое дело реализовано ли на уровне классов встроенных в язык или каким либо другим способом.
>>613865
У кошки в базовой комплектации нет накладных ушек, это инъекция зависимости.
У кошки в базовой комплектации нет накладных ушек, это инъекция зависимости.
31 Кб, 442x442Ctrl + F "Поддержка" - 1 результат.
Писать говно по принципу написал один раз и пошел дальше можно на чём угодно(на фп языках это естественно быстрее), разницы нет. Но вот если тебе(а зачастую не только тебе, а еще другим людям) это надо поддерживать и развивать, то только ООП.
Самые большие затраты при разработке софта - это его поддержка(а не первоначальная разработка, о чем обычно идёт речь в спорах наподобие ОП)
Писать говно по принципу написал один раз и пошел дальше можно на чём угодно(на фп языках это естественно быстрее), разницы нет. Но вот если тебе(а зачастую не только тебе, а еще другим людям) это надо поддерживать и развивать, то только ООП.
Самые большие затраты при разработке софта - это его поддержка(а не первоначальная разработка, о чем обычно идёт речь в спорах наподобие ОП)
>>610689
Машина Тьюринга и лямбда исчисление эквивалентны с точки зрения вычислимости. Доказано еще в 30-х. Иди нахуй даун.
Машина Тьюринга и лямбда исчисление эквивалентны с точки зрения вычислимости. Доказано еще в 30-х. Иди нахуй даун.
>>612039
Ну вот как тебе сказать...
https://github.com/AlexKent3141/meta-tictactoe
>А чем это джавовые дженерики неполноценные
Ну вот как тебе сказать...
https://github.com/AlexKent3141/meta-tictactoe
7 Кб, 242x208>>614620
ПРОВЕРКУ МОЖНО ВЫПОЛНИТЬ БУКВАЛЬНО ДВУМЯ С ПОЛОВИНОЙ ПРОЦЕДУРАМИ НА ГОРИЗОНТАЛЬ И ДИАГОНАЛЬ
@
ЕБАН БУКВАЛЬНО ХАРДКОДИТ БУКВАЛЬНО КАЖДЫЙ КЕЙС ВРУЧНУЮ
@
ПРОВЕРКУ МОЖНО ВЫПОЛНИТЬ БУКВАЛЬНО ДВУМЯ С ПОЛОВИНОЙ ПРОЦЕДУРАМИ НА ГОРИЗОНТАЛЬ И ДИАГОНАЛЬ
@
ЕБАН БУКВАЛЬНО ХАРДКОДИТ БУКВАЛЬНО КАЖДЫЙ КЕЙС ВРУЧНУЮ
@
>ЖЕНЕРИКИ КАКОЕТО ГОВНО
>>608094
так и называется - структура
> Поэтому ты расскажи как бы ты в процедурном стиле описал новый тип данных?
так и называется - структура
>>610119
В OpenGL последних версий (и в Вулкане, вроде, тоже), например ввели куколд-ООП.
Суть в том что саму структуру в руки тебе не выдают.
Тебе выдают в руки ID, и процедуры типа геттеров-сеттеров в которые ты это id можешь передавать и которое резольвится внутри драйвера в какой-то реальный стейт.
>Вот тут возникает первая проблема. Данные внутри структуры должны быть согласованны, не может быть в сутках 27:83:132.
В OpenGL последних версий (и в Вулкане, вроде, тоже), например ввели куколд-ООП.
Суть в том что саму структуру в руки тебе не выдают.
Тебе выдают в руки ID, и процедуры типа геттеров-сеттеров в которые ты это id можешь передавать и которое резольвится внутри драйвера в какой-то реальный стейт.
>>614616
Он обратного не утверждал, долбоящер.
Что-то я не наблюдаю очереди желающих программировать машины тьюринга.
>эквивалентны с точки зрения вычислимости
Он обратного не утверждал, долбоящер.
Что-то я не наблюдаю очереди желающих программировать машины тьюринга.
>>613443
Термин ООП изначально был придуман для Smalltalk.
Нет.
https://en.wikipedia.org/wiki/Alan_Kay
Термин ООП изначально был придуман для Smalltalk.
>гуманитарная хуйня
Нет.
https://en.wikipedia.org/wiki/Alan_Kay
>>615004
Два объекта этому.
Два объекта этому.
Дайте что-то почитать по ООП что бы я начал писать нормально, а то пришел на проект, а тут кругом говно и оно только накапливается
>>607925 (OP)
Ты сейчас ооп в js описал
Ты сейчас ооп в js описал
>>607925 (OP)
В игорах особенно в массовых онлайн дрочильнях используется другая отличная от ооп концепция - ECS
Все объекты/сущьности размазываются по многим таблицам/спискам. Ты можешь сразу обработать координаты 100500 мобов, а не вызывать monster->move(0, 0) для каждого моба. Считается что полиморфизм дорого стоит. Пусть меня поправит кто в теме
В игорах особенно в массовых онлайн дрочильнях используется другая отличная от ооп концепция - ECS
Все объекты/сущьности размазываются по многим таблицам/спискам. Ты можешь сразу обработать координаты 100500 мобов, а не вызывать monster->move(0, 0) для каждого моба. Считается что полиморфизм дорого стоит. Пусть меня поправит кто в теме
Ооп ему не нравится. А может ты еще за украинцев?
>>611615
Obj.func1().func2()
Obj.func1().func2()
>>615202
Не столько из-за самого полиморфизма (в ООП, конечно, есть косвенный вызов через vtable, но он вроде и в ECS никуда не исчезнет), сколько из-за сложности изменений в ООП, например геймдизайнер поменял тип юнита со среднего танка на тяжелый, тебе придется лезть в разные файлы, менять что от чего наследуется и не наебаться
Не столько из-за самого полиморфизма (в ООП, конечно, есть косвенный вызов через vtable, но он вроде и в ECS никуда не исчезнет), сколько из-за сложности изменений в ООП, например геймдизайнер поменял тип юнита со среднего танка на тяжелый, тебе придется лезть в разные файлы, менять что от чего наследуется и не наебаться
>>612877
Знаешь там погрешность порядка двух диаметров солнц максимум, так что.
>центра масс солнечной системы, не всегда находящегося внутри гелиосферы
Знаешь там погрешность порядка двух диаметров солнц максимум, так что.
>>611552
Мань, под ООП всегда подразумевалась отправка сообщений объекту, да, вызов метода это тоже отправка сообщения.
Фабричный метод, который возвращает каждый раз новый объект, смеется тебе в лицо.
Короче, никто не виноват что ты говнокодер и свой опыт проецируешь на остальных.
> Под ООП всегда подразумевалось, подразумевается и будет подразумеваться как бы вы не старались, маньки мутабельные структы со связанным неймспейсом, в котором определены процедуры-методы, меняющие поля структа.
Мань, под ООП всегда подразумевалась отправка сообщений объекту, да, вызов метода это тоже отправка сообщения.
>процедуры-методы, меняющие поля структа.
Фабричный метод, который возвращает каждый раз новый объект, смеется тебе в лицо.
Короче, никто не виноват что ты говнокодер и свой опыт проецируешь на остальных.
>>610689
Эмоциональное слово, не несущее какого-либо объективного определения в данном контексте.
Из машины Тьюринга можно построить любую вычислительную систему. Личералли. Это то что позволяет строить полноценные компьютеры в майнкрафте, к примеру.
Один из самых первых примеров машины Тьюринга - это когда ячейки хранят буквы, которые интерпретируются. Так что да, машина Тьюринга позволяет строить свой язык программирования и работать уже на нем.
Математика - лженаука, она изучает несуществующий предмет, покажи мне отдельно существующее число в природе. Их нет.
Состояние это добро, все благое происходит из-за него.
> гибкости
Эмоциональное слово, не несущее какого-либо объективного определения в данном контексте.
>позволяют из маленького ядра построить любую вычислительную систему
Из машины Тьюринга можно построить любую вычислительную систему. Личералли. Это то что позволяет строить полноценные компьютеры в майнкрафте, к примеру.
>Грубо говоря, они позволяют строить свой язык программирования.
Один из самых первых примеров машины Тьюринга - это когда ячейки хранят буквы, которые интерпретируются. Так что да, машина Тьюринга позволяет строить свой язык программирования и работать уже на нем.
>математике
Математика - лженаука, она изучает несуществующий предмет, покажи мне отдельно существующее число в природе. Их нет.
>Состояние это зло, все ошибки происходят из-за него.
Состояние это добро, все благое происходит из-за него.
>>615263
Температура - это абстракция. Термодинамика тоже лженаука? Количество - это абстракция, но вполне имеет отношение к реальному миру. Ты же не можешь предположить что у тебя батя вдруг не один, а скажем полтора бати, даже если ты уверен что твоя мамка шлюха.
>покажи мне отдельно существующее число в природе
Температура - это абстракция. Термодинамика тоже лженаука? Количество - это абстракция, но вполне имеет отношение к реальному миру. Ты же не можешь предположить что у тебя батя вдруг не один, а скажем полтора бати, даже если ты уверен что твоя мамка шлюха.
>>615272
Крикнул
> Ты же не можешь предположить что у тебя батя вдруг не один, а скажем полтора бати, даже если ты уверен что твоя мамка шлюха.
Крикнул
>>615272
Ты мне показал батю, а ты мне отдельно число в природе покажи, вумник.
Ты мне показал батю, а ты мне отдельно число в природе покажи, вумник.
>>607925 (OP)
А как твои списки генерируют СОБЫТИЯ ?
>Почему пользоваться классами и объектами, а не допустим списками? Ведь суть одна и та же.
А как твои списки генерируют СОБЫТИЯ ?
0E2C190E2E2D0E2E2E0E2E2D0E1B2C140E2E2D0E2E1E140E2E1A0E2F1C0E2E1D0E2F2C14
0E2F1B0E2E1E0E2F190E2E2F0E2E210E2E2B0E2E2E0E2E220E1B2C140E2E2F0E2F190E2E2
10E2F1A0E2E2E0E2E1E0E2E1D0E2E210E2E2D0E2F2F0E2E220E2F1A0E2F2F140E2E2A140E
2F190E2E1E0E2E200E2E1E0E2F190E2E1B0E2E190E2F1F0E2E210E2E21140E2E1D0E2E1B0
E2E190E2F200E2E1E0E2F190E2E2E0E2E1B0E1B2C140E2E2C0E2E2E0E2F200E2E19140E2F
1A0E2E2E0E2E1B0E2F1A0E2E1E0E2E2C140E2E190E2F1E0E2F1C0E2E1E0E2E2B0E2E190E1
B2C140E2E2D0E2E19140E2F1A0E2E2E0E2F1A0E2E190E2F200E2E1E140E2E2C0E2E2E0E2F
200E2E1E0E2F190E2E190E2F1B0E2E2E0E2F190E2F2B140E2F1A0E2E2B0E2E210E2E1B0E2
E190E2F2E0E2F1B145259140E2E190E2E2D0E2E2E0E2E2D0E2E2E0E2E1B140E2F1A0E2E1B
0E2E2E0E2E210E2E2C140E2E1D0E2F190E2F1C0E2E1F0E2E2A0E2E190E2E2C140E2E210E2
E2B0E2E21140E2E2F0E2F190E2E2E0E2F1A0E2F1B0E2E2E140E2F190E2E190E2E1D0E2E21
140E2E2B0E2F1C0E2E2B0E2E200E2E2E0E2E1B0E1B2C140E2F210E2E2A0E2E2E0E2E2B0E2
F2C0E2E2D0E2E210E2E2A0E2E21140E2E1B0E2F2B0E2F1B0E2E210E2F190E2E190E2F2E0E
2F1B140E2E2E0E2E1A140E2F1B0E2E1E0E2E1A0E2F2F140E2E2D0E2E2E0E2E1C0E2E210E1
B2C140E2E2F0E2E190E2F190E2E190E2F210E2E19140E2E1B140E2F1F0E2E1E0E2E2B0E2E
2E0E2E2C140E2E2F0E2E210E2E190E2F190E2E210E2F1B0E2F1A0E2F2F140E2E2D0E2E191
40E2E2F0E2E2B0E2E2E0E2F220E2E190E2E1D0E2E2A0E2E190E2F1E140E2E1D0E2E2B0E2F
2F140E2E2D0E2E2E0E2F190E2E2C0E2E210E2F1A0E2E2E0E2E1B170E2C1B0E2E2E0E2F1B1
40E2E2C0E2E1E0E2F1A0E2F1B0E2E2E140E2E1C0E2E1D0E2E1E140E2F1B0E2F2B140E2E2F
0E2E2E0E2F200E2F1C0E2E1B0E2F1A0E2F1B0E2E1B0E2F1C0E2E1E0E2F210E2F2C140E2F1
A0E2E1E0E2E1A0E2F2F140E2E1B140E2F1C0E2F2E0E2F1B0E2E1E0E1B2C140E2E2C0E2E1E
0E2F1A0E2F1B0E2E2E140E2E1C0E2E1D0E2E1E140E2E2D0E2E1E0E2F1B140E2E2C0E2E2E0
E2F200E2E21140E2E2E0E2F1B140E2F1A0E2E2B0E2E2E0E2E1B0E2E19140E2F1A0E2E2E0E
2E1B0E2F1A0E2E1E0E2E2C0E1B2C140E2E2C0E2E1E0E2F1A0E2F1B0E2E2E140E2E1C0E2E1
D0E2E1E140E2E1E0E2F1A0E2F1B0E2F2C140E2E200E2E1E0E2F190E2E2A0E2E190E2E2B0E
2E2E140E2F1B0E2E2E0E2F190E1B2C140E2E19140E2E1D0E2E190E2E1F0E2E1E140E2E1E0
E2F1A0E2E2B0E2E21140E2F1B0E2F2B140E2E2F0E2E2E0E2F1A0E2F1B0E2E210E2F210E2F
2C140E2F1A140E2E2A0E2E2B0E2E210E2F190E2E191416140E2F1A0E2E210E2F1A0E2F1B0
E2E1E0E2E2C0E2E19140E2F210E2E210E2F1D0E2F190E2E2E0E2E1B0E2E190E2E2D0E2E21
0E2F2F140E2E2D0E2E1E140E2E2F0E2E2E0E2E2A0E2E190E2E1F0E2E1E0E2F1B140E2E190
E2E1D0E2E2C0E2E210E2E2D0E2E210E2F1A0E2F1B0E2F190E2E190E2F1F0E2E210E2E2114
0E2F1B0E2E1B0E2E2E0E2E1E0E2E1C0E2E2E14525917140E2C1D0E2E2E0E2E1A0E2F190E2
E2E140E2E2F0E2E2E0E2E1F0E2E190E2E2B0E2E2E0E2E1B0E2E190E2F1B0E2F2C140E2E2D
0E2E19140E2F190E2E1E0E2E200E2E1E0E2F190E2E1B0E2E190E2F2014515D5D595C0E1C2
A0E1B2F0E1B2F555855524F5861174C4C0E1B2F5C580E1B2F
0E2F1B0E2E1E0E2F190E2E2F0E2E210E2E2B0E2E2E0E2E220E1B2C140E2E2F0E2F190E2E2
10E2F1A0E2E2E0E2E1E0E2E1D0E2E210E2E2D0E2F2F0E2E220E2F1A0E2F2F140E2E2A140E
2F190E2E1E0E2E200E2E1E0E2F190E2E1B0E2E190E2F1F0E2E210E2E21140E2E1D0E2E1B0
E2E190E2F200E2E1E0E2F190E2E2E0E2E1B0E1B2C140E2E2C0E2E2E0E2F200E2E19140E2F
1A0E2E2E0E2E1B0E2F1A0E2E1E0E2E2C140E2E190E2F1E0E2F1C0E2E1E0E2E2B0E2E190E1
B2C140E2E2D0E2E19140E2F1A0E2E2E0E2F1A0E2E190E2F200E2E1E140E2E2C0E2E2E0E2F
200E2E1E0E2F190E2E190E2F1B0E2E2E0E2F190E2F2B140E2F1A0E2E2B0E2E210E2E1B0E2
E190E2F2E0E2F1B145259140E2E190E2E2D0E2E2E0E2E2D0E2E2E0E2E1B140E2F1A0E2E1B
0E2E2E0E2E210E2E2C140E2E1D0E2F190E2F1C0E2E1F0E2E2A0E2E190E2E2C140E2E210E2
E2B0E2E21140E2E2F0E2F190E2E2E0E2F1A0E2F1B0E2E2E140E2F190E2E190E2E1D0E2E21
140E2E2B0E2F1C0E2E2B0E2E200E2E2E0E2E1B0E1B2C140E2F210E2E2A0E2E2E0E2E2B0E2
F2C0E2E2D0E2E210E2E2A0E2E21140E2E1B0E2F2B0E2F1B0E2E210E2F190E2E190E2F2E0E
2F1B140E2E2E0E2E1A140E2F1B0E2E1E0E2E1A0E2F2F140E2E2D0E2E2E0E2E1C0E2E210E1
B2C140E2E2F0E2E190E2F190E2E190E2F210E2E19140E2E1B140E2F1F0E2E1E0E2E2B0E2E
2E0E2E2C140E2E2F0E2E210E2E190E2F190E2E210E2F1B0E2F1A0E2F2F140E2E2D0E2E191
40E2E2F0E2E2B0E2E2E0E2F220E2E190E2E1D0E2E2A0E2E190E2F1E140E2E1D0E2E2B0E2F
2F140E2E2D0E2E2E0E2F190E2E2C0E2E210E2F1A0E2E2E0E2E1B170E2C1B0E2E2E0E2F1B1
40E2E2C0E2E1E0E2F1A0E2F1B0E2E2E140E2E1C0E2E1D0E2E1E140E2F1B0E2F2B140E2E2F
0E2E2E0E2F200E2F1C0E2E1B0E2F1A0E2F1B0E2E1B0E2F1C0E2E1E0E2F210E2F2C140E2F1
A0E2E1E0E2E1A0E2F2F140E2E1B140E2F1C0E2F2E0E2F1B0E2E1E0E1B2C140E2E2C0E2E1E
0E2F1A0E2F1B0E2E2E140E2E1C0E2E1D0E2E1E140E2E2D0E2E1E0E2F1B140E2E2C0E2E2E0
E2F200E2E21140E2E2E0E2F1B140E2F1A0E2E2B0E2E2E0E2E1B0E2E19140E2F1A0E2E2E0E
2E1B0E2F1A0E2E1E0E2E2C0E1B2C140E2E2C0E2E1E0E2F1A0E2F1B0E2E2E140E2E1C0E2E1
D0E2E1E140E2E1E0E2F1A0E2F1B0E2F2C140E2E200E2E1E0E2F190E2E2A0E2E190E2E2B0E
2E2E140E2F1B0E2E2E0E2F190E1B2C140E2E19140E2E1D0E2E190E2E1F0E2E1E140E2E1E0
E2F1A0E2E2B0E2E21140E2F1B0E2F2B140E2E2F0E2E2E0E2F1A0E2F1B0E2E210E2F210E2F
2C140E2F1A140E2E2A0E2E2B0E2E210E2F190E2E191416140E2F1A0E2E210E2F1A0E2F1B0
E2E1E0E2E2C0E2E19140E2F210E2E210E2F1D0E2F190E2E2E0E2E1B0E2E190E2E2D0E2E21
0E2F2F140E2E2D0E2E1E140E2E2F0E2E2E0E2E2A0E2E190E2E1F0E2E1E0E2F1B140E2E190
E2E1D0E2E2C0E2E210E2E2D0E2E210E2F1A0E2F1B0E2F190E2E190E2F1F0E2E210E2E2114
0E2F1B0E2E1B0E2E2E0E2E1E0E2E1C0E2E2E14525917140E2C1D0E2E2E0E2E1A0E2F190E2
E2E140E2E2F0E2E2E0E2E1F0E2E190E2E2B0E2E2E0E2E1B0E2E190E2F1B0E2F2C140E2E2D
0E2E19140E2F190E2E1E0E2E200E2E1E0E2F190E2E1B0E2E190E2F2014515D5D595C0E1C2
A0E1B2F0E1B2F555855524F5861174C4C0E1B2F5C580E1B2F
0E2C190E2E2D0E2E2E0E2E2D0E1B2C140E2E2D0E2E1E140E2E1A0E2F1C0E2E1D0E2F2C14
0E2F1B0E2E1E0E2F190E2E2F0E2E210E2E2B0E2E2E0E2E220E1B2C140E2E2F0E2F190E2E2
10E2F1A0E2E2E0E2E1E0E2E1D0E2E210E2E2D0E2F2F0E2E220E2F1A0E2F2F140E2E2A140E
2F190E2E1E0E2E200E2E1E0E2F190E2E1B0E2E190E2F1F0E2E210E2E21140E2E1D0E2E1B0
E2E190E2F200E2E1E0E2F190E2E2E0E2E1B0E1B2C140E2E2C0E2E2E0E2F200E2E19140E2F
1A0E2E2E0E2E1B0E2F1A0E2E1E0E2E2C140E2E190E2F1E0E2F1C0E2E1E0E2E2B0E2E190E1
B2C140E2E2D0E2E19140E2F1A0E2E2E0E2F1A0E2E190E2F200E2E1E140E2E2C0E2E2E0E2F
200E2E1E0E2F190E2E190E2F1B0E2E2E0E2F190E2F2B140E2F1A0E2E2B0E2E210E2E1B0E2
E190E2F2E0E2F1B145259140E2E190E2E2D0E2E2E0E2E2D0E2E2E0E2E1B140E2F1A0E2E1B
0E2E2E0E2E210E2E2C140E2E1D0E2F190E2F1C0E2E1F0E2E2A0E2E190E2E2C140E2E210E2
E2B0E2E21140E2E2F0E2F190E2E2E0E2F1A0E2F1B0E2E2E140E2F190E2E190E2E1D0E2E21
140E2E2B0E2F1C0E2E2B0E2E200E2E2E0E2E1B0E1B2C140E2F210E2E2A0E2E2E0E2E2B0E2
F2C0E2E2D0E2E210E2E2A0E2E21140E2E1B0E2F2B0E2F1B0E2E210E2F190E2E190E2F2E0E
2F1B140E2E2E0E2E1A140E2F1B0E2E1E0E2E1A0E2F2F140E2E2D0E2E2E0E2E1C0E2E210E1
B2C140E2E2F0E2E190E2F190E2E190E2F210E2E19140E2E1B140E2F1F0E2E1E0E2E2B0E2E
2E0E2E2C140E2E2F0E2E210E2E190E2F190E2E210E2F1B0E2F1A0E2F2F140E2E2D0E2E191
40E2E2F0E2E2B0E2E2E0E2F220E2E190E2E1D0E2E2A0E2E190E2F1E140E2E1D0E2E2B0E2F
2F140E2E2D0E2E2E0E2F190E2E2C0E2E210E2F1A0E2E2E0E2E1B170E2C1B0E2E2E0E2F1B1
40E2E2C0E2E1E0E2F1A0E2F1B0E2E2E140E2E1C0E2E1D0E2E1E140E2F1B0E2F2B140E2E2F
0E2E2E0E2F200E2F1C0E2E1B0E2F1A0E2F1B0E2E1B0E2F1C0E2E1E0E2F210E2F2C140E2F1
A0E2E1E0E2E1A0E2F2F140E2E1B140E2F1C0E2F2E0E2F1B0E2E1E0E1B2C140E2E2C0E2E1E
0E2F1A0E2F1B0E2E2E140E2E1C0E2E1D0E2E1E140E2E2D0E2E1E0E2F1B140E2E2C0E2E2E0
E2F200E2E21140E2E2E0E2F1B140E2F1A0E2E2B0E2E2E0E2E1B0E2E19140E2F1A0E2E2E0E
2E1B0E2F1A0E2E1E0E2E2C0E1B2C140E2E2C0E2E1E0E2F1A0E2F1B0E2E2E140E2E1C0E2E1
D0E2E1E140E2E1E0E2F1A0E2F1B0E2F2C140E2E200E2E1E0E2F190E2E2A0E2E190E2E2B0E
2E2E140E2F1B0E2E2E0E2F190E1B2C140E2E19140E2E1D0E2E190E2E1F0E2E1E140E2E1E0
E2F1A0E2E2B0E2E21140E2F1B0E2F2B140E2E2F0E2E2E0E2F1A0E2F1B0E2E210E2F210E2F
2C140E2F1A140E2E2A0E2E2B0E2E210E2F190E2E191416140E2F1A0E2E210E2F1A0E2F1B0
E2E1E0E2E2C0E2E19140E2F210E2E210E2F1D0E2F190E2E2E0E2E1B0E2E190E2E2D0E2E21
0E2F2F140E2E2D0E2E1E140E2E2F0E2E2E0E2E2A0E2E190E2E1F0E2E1E0E2F1B140E2E190
E2E1D0E2E2C0E2E210E2E2D0E2E210E2F1A0E2F1B0E2F190E2E190E2F1F0E2E210E2E2114
0E2F1B0E2E1B0E2E2E0E2E1E0E2E1C0E2E2E14525917140E2C1D0E2E2E0E2E1A0E2F190E2
E2E140E2E2F0E2E2E0E2E1F0E2E190E2E2B0E2E2E0E2E1B0E2E190E2F1B0E2F2C140E2E2D
0E2E19140E2F190E2E1E0E2E200E2E1E0E2F190E2E1B0E2E190E2F2014515D5D595C0E1C2
A0E1B2F0E1B2F555855524F5861174C4C0E1B2F5C580E1B2F
0E2F1B0E2E1E0E2F190E2E2F0E2E210E2E2B0E2E2E0E2E220E1B2C140E2E2F0E2F190E2E2
10E2F1A0E2E2E0E2E1E0E2E1D0E2E210E2E2D0E2F2F0E2E220E2F1A0E2F2F140E2E2A140E
2F190E2E1E0E2E200E2E1E0E2F190E2E1B0E2E190E2F1F0E2E210E2E21140E2E1D0E2E1B0
E2E190E2F200E2E1E0E2F190E2E2E0E2E1B0E1B2C140E2E2C0E2E2E0E2F200E2E19140E2F
1A0E2E2E0E2E1B0E2F1A0E2E1E0E2E2C140E2E190E2F1E0E2F1C0E2E1E0E2E2B0E2E190E1
B2C140E2E2D0E2E19140E2F1A0E2E2E0E2F1A0E2E190E2F200E2E1E140E2E2C0E2E2E0E2F
200E2E1E0E2F190E2E190E2F1B0E2E2E0E2F190E2F2B140E2F1A0E2E2B0E2E210E2E1B0E2
E190E2F2E0E2F1B145259140E2E190E2E2D0E2E2E0E2E2D0E2E2E0E2E1B140E2F1A0E2E1B
0E2E2E0E2E210E2E2C140E2E1D0E2F190E2F1C0E2E1F0E2E2A0E2E190E2E2C140E2E210E2
E2B0E2E21140E2E2F0E2F190E2E2E0E2F1A0E2F1B0E2E2E140E2F190E2E190E2E1D0E2E21
140E2E2B0E2F1C0E2E2B0E2E200E2E2E0E2E1B0E1B2C140E2F210E2E2A0E2E2E0E2E2B0E2
F2C0E2E2D0E2E210E2E2A0E2E21140E2E1B0E2F2B0E2F1B0E2E210E2F190E2E190E2F2E0E
2F1B140E2E2E0E2E1A140E2F1B0E2E1E0E2E1A0E2F2F140E2E2D0E2E2E0E2E1C0E2E210E1
B2C140E2E2F0E2E190E2F190E2E190E2F210E2E19140E2E1B140E2F1F0E2E1E0E2E2B0E2E
2E0E2E2C140E2E2F0E2E210E2E190E2F190E2E210E2F1B0E2F1A0E2F2F140E2E2D0E2E191
40E2E2F0E2E2B0E2E2E0E2F220E2E190E2E1D0E2E2A0E2E190E2F1E140E2E1D0E2E2B0E2F
2F140E2E2D0E2E2E0E2F190E2E2C0E2E210E2F1A0E2E2E0E2E1B170E2C1B0E2E2E0E2F1B1
40E2E2C0E2E1E0E2F1A0E2F1B0E2E2E140E2E1C0E2E1D0E2E1E140E2F1B0E2F2B140E2E2F
0E2E2E0E2F200E2F1C0E2E1B0E2F1A0E2F1B0E2E1B0E2F1C0E2E1E0E2F210E2F2C140E2F1
A0E2E1E0E2E1A0E2F2F140E2E1B140E2F1C0E2F2E0E2F1B0E2E1E0E1B2C140E2E2C0E2E1E
0E2F1A0E2F1B0E2E2E140E2E1C0E2E1D0E2E1E140E2E2D0E2E1E0E2F1B140E2E2C0E2E2E0
E2F200E2E21140E2E2E0E2F1B140E2F1A0E2E2B0E2E2E0E2E1B0E2E19140E2F1A0E2E2E0E
2E1B0E2F1A0E2E1E0E2E2C0E1B2C140E2E2C0E2E1E0E2F1A0E2F1B0E2E2E140E2E1C0E2E1
D0E2E1E140E2E1E0E2F1A0E2F1B0E2F2C140E2E200E2E1E0E2F190E2E2A0E2E190E2E2B0E
2E2E140E2F1B0E2E2E0E2F190E1B2C140E2E19140E2E1D0E2E190E2E1F0E2E1E140E2E1E0
E2F1A0E2E2B0E2E21140E2F1B0E2F2B140E2E2F0E2E2E0E2F1A0E2F1B0E2E210E2F210E2F
2C140E2F1A140E2E2A0E2E2B0E2E210E2F190E2E191416140E2F1A0E2E210E2F1A0E2F1B0
E2E1E0E2E2C0E2E19140E2F210E2E210E2F1D0E2F190E2E2E0E2E1B0E2E190E2E2D0E2E21
0E2F2F140E2E2D0E2E1E140E2E2F0E2E2E0E2E2A0E2E190E2E1F0E2E1E0E2F1B140E2E190
E2E1D0E2E2C0E2E210E2E2D0E2E210E2F1A0E2F1B0E2F190E2E190E2F1F0E2E210E2E2114
0E2F1B0E2E1B0E2E2E0E2E1E0E2E1C0E2E2E14525917140E2C1D0E2E2E0E2E1A0E2F190E2
E2E140E2E2F0E2E2E0E2E1F0E2E190E2E2B0E2E2E0E2E1B0E2E190E2F1B0E2F2C140E2E2D
0E2E19140E2F190E2E1E0E2E200E2E1E0E2F190E2E1B0E2E190E2F2014515D5D595C0E1C2
A0E1B2F0E1B2F555855524F5861174C4C0E1B2F5C580E1B2F
>>615248
Так что? А теперь раздели диаметр земной орбиты на два диаметра Солнца и посмотри какое большущее число получится.
>Знаешь там погрешность порядка двух диаметров солнц максимум, так что
Так что? А теперь раздели диаметр земной орбиты на два диаметра Солнца и посмотри какое большущее число получится.
>>615347
МОЧЕРАТОР!!1 ТУТ ЦП!1
МОЧЕРАТОР!!1 ТУТ ЦП!1
>>615263
И? Как из утверждения "на машине тьюринга можно реализовать что-то более выразительное" следует утверждение "машина тьюринга сама столь же выразительна".
Если тебя выразительность машины тьюринга устраивает, то открывай брейнфак и пиши там, никаких функций, объектов, замыканий чтоб я не видел в твоём коде.
>Из машины Тьюринга можно построить любую вычислительную систему.
И? Как из утверждения "на машине тьюринга можно реализовать что-то более выразительное" следует утверждение "машина тьюринга сама столь же выразительна".
Если тебя выразительность машины тьюринга устраивает, то открывай брейнфак и пиши там, никаких функций, объектов, замыканий чтоб я не видел в твоём коде.
>>615263
Вот два пальца, вот три пальца, посчитай вместе будет пять пальцев.
Вот один человек, вот четыре человека, посчитай вместе будет пять человек.
Вот человек говорит с тобой, спрашивает сколько человек в том здании, ты говоришь ему "пять", он представляет себе пять человек.
Охуенно блядь несуществующий.
Из этого не следует, что концепция числа ничего не значит, т.к. всякое число является отображением реальности, как я только что показал на примере пальцев и людей.
Ну насчёт мнимых чисел разве что точно не скажу, а всякое действительное число это совершенно точно способно описывать реальный мир с пальцами, людьми и килограммами.
>Математика - лженаука, она изучает несуществующий предмет
Вот два пальца, вот три пальца, посчитай вместе будет пять пальцев.
Вот один человек, вот четыре человека, посчитай вместе будет пять человек.
Вот человек говорит с тобой, спрашивает сколько человек в том здании, ты говоришь ему "пять", он представляет себе пять человек.
Охуенно блядь несуществующий.
>покажи мне отдельно существующее число в природе. Их нет.
Из этого не следует, что концепция числа ничего не значит, т.к. всякое число является отображением реальности, как я только что показал на примере пальцев и людей.
Ну насчёт мнимых чисел разве что точно не скажу, а всякое действительное число это совершенно точно способно описывать реальный мир с пальцами, людьми и килограммами.
19 Кб, 374x252>>615436
Так то же самое касается лямбдакалькулюса, который ты противопостовлял Тьюрингу. Вот уж от кого смешно слышать претензии к похожести на брейнфак.
Так то же самое касается лямбдакалькулюса, который ты противопостовлял Тьюрингу. Вот уж от кого смешно слышать претензии к похожести на брейнфак.
>>615445
Это пальцы.
Это человеки.
Числа мне покажи, джениус. Числа в природе.
>Вот два пальца, вот три пальца
Это пальцы.
>Вот один человек, вот четыре человека
Это человеки.
Числа мне покажи, джениус. Числа в природе.
113 Кб, 883x704>>615449
Так что это у нас тут? Пациент не способен к простым обобщениям. Из анамнеза: легкая степень олигофрении.
Так что это у нас тут? Пациент не способен к простым обобщениям. Из анамнеза: легкая степень олигофрении.
>>615458
https://www.youtube.com/watch?v=kzo45hWXRWU
Звук слышно мозгом. Так же, как и числа, которые воспринимаются им же
>Звук слышно ушами.
https://www.youtube.com/watch?v=kzo45hWXRWU
Звук слышно мозгом. Так же, как и числа, которые воспринимаются им же
>>615458
Мозгом, как и пальцы со звуками.
Для этого правда нужно абстрактное мышление, но судя по тому что ты способен выучить и понимать человеческий язык, что ты нам тут и продемонстрировал, оно у тебя имеется.
Если ты считаешь что способность воспринимать обобщения это для петухов и нинужно, то сразу после того как прочтёшь этот пост тебе следует перестать пользоваться языком, ибо язык это тоже обобщение, ведь в мире не существует слова "яблоко", в мире есть только яблоки, а слова ты уже мозгом воспринимаешь.
>Каким органом чувств воспринимаются числа?
Мозгом, как и пальцы со звуками.
Для этого правда нужно абстрактное мышление, но судя по тому что ты способен выучить и понимать человеческий язык, что ты нам тут и продемонстрировал, оно у тебя имеется.
Если ты считаешь что способность воспринимать обобщения это для петухов и нинужно, то сразу после того как прочтёшь этот пост тебе следует перестать пользоваться языком, ибо язык это тоже обобщение, ведь в мире не существует слова "яблоко", в мире есть только яблоки, а слова ты уже мозгом воспринимаешь.
>>615497
А сказать-то что хотел?
А сказать-то что хотел?
>>615483
Блядь, какой же ты долбоеб. Теперь из-за тебя он оигнорит мой пост, который его разъебывает, доебавшись до какой-то хуйни в твоем моем посте.
Блядь, какой же ты долбоеб. Теперь из-за тебя он оигнорит мой пост, который его разъебывает, доебавшись до какой-то хуйни в твоем моем посте.
>>615483
Верно. Вот и чисел не существует в природе, только несколько яблок.
>ведь в мире не существует слова "яблоко", в мире есть только яблоки
Верно. Вот и чисел не существует в природе, только несколько яблок.
>>615497
Двачую, большая часть того чем так гордятся гении является по факту бредом.
Двачую, большая часть того чем так гордятся гении является по факту бредом.
>>615510
Ну не корона и то уже хорошо.
Ну не корона и то уже хорошо.
>>615463
Ну не. Там наверное про восприятие частоты. Так то я даже с таким знаком https://ru.wikipedia.org/wiki/Зонная_теория_музыкального_слуха
Но сам звук то воспринимается ухом физически. Улитки, барабанны перепонки, наковаленки с молоточками и стремечками, вот это все.
Ну не. Там наверное про восприятие частоты. Так то я даже с таким знаком https://ru.wikipedia.org/wiki/Зонная_теория_музыкального_слуха
Но сам звук то воспринимается ухом физически. Улитки, барабанны перепонки, наковаленки с молоточками и стремечками, вот это все.
>>615447
При желании запутанно можно писать на чём угодно, тот анон речь вёл о том, что функциональная нотация ближе и понятнее человеческому существу, чем распутывание цепочек из goto
При желании запутанно можно писать на чём угодно, тот анон речь вёл о том, что функциональная нотация ближе и понятнее человеческому существу, чем распутывание цепочек из goto
>>615507
Правильно сделал. Ведь чтение - это абстракция, а абстракции нинужны, только реальность, только счёт на палочках.
Правильно сделал. Ведь чтение - это абстракция, а абстракции нинужны, только реальность, только счёт на палочках.
>>615521
Там про то что один и тот же звук воспринимается по-разному в зависимости от видеоряда. А единственное место, где сигналы от уха и глаз пересекаются - это мозг.
>Ну не. Там наверное про восприятие частоты.
Там про то что один и тот же звук воспринимается по-разному в зависимости от видеоряда. А единственное место, где сигналы от уха и глаз пересекаются - это мозг.
>>615508
Давай-ка разберём по порядку.
Допустим ты начал разговор, искренне желая помочь избавиться от заблуждений оппоненту, тогда как оппонент заблуждется опять же совершенно искренне (а не толсто тралирует).
Дальше ты видишь, что твой оппонент показывает себя демагогом, реагируя на пост другого человека соответствующим образом.
Теперь ты понимаешь, что твой оппонент - демагог. Можешь ли ты расстроиться из-за того, что не смог разубедить демагога? Нет. Демагога разубедить невозможно, т.к. он не за истиной в дискуссию приходит.
Но ты расстраиваешься. Почему? Ответ прост - потому что ты на самом деле тоже демагог, преследующий цель посоревноваться в ментальной гимнастике. Истина тебе побоку, тебе надо просигналить свой ум и подвешенный язык.
А теперь вопрос - почему меня должно ебать, что я разломал дискуссию двум демагогам? Да сосите хуй, ёпт, меня это только радует.
Давай-ка разберём по порядку.
Допустим ты начал разговор, искренне желая помочь избавиться от заблуждений оппоненту, тогда как оппонент заблуждется опять же совершенно искренне (а не толсто тралирует).
Дальше ты видишь, что твой оппонент показывает себя демагогом, реагируя на пост другого человека соответствующим образом.
Теперь ты понимаешь, что твой оппонент - демагог. Можешь ли ты расстроиться из-за того, что не смог разубедить демагога? Нет. Демагога разубедить невозможно, т.к. он не за истиной в дискуссию приходит.
Но ты расстраиваешься. Почему? Ответ прост - потому что ты на самом деле тоже демагог, преследующий цель посоревноваться в ментальной гимнастике. Истина тебе побоку, тебе надо просигналить свой ум и подвешенный язык.
А теперь вопрос - почему меня должно ебать, что я разломал дискуссию двум демагогам? Да сосите хуй, ёпт, меня это только радует.
>>615581
Потому что этот демагог - ты, лол. Вот твои посты.
>>615581>>615483>>615445
Я прошел мимо и захотел помочь твоей точке зрения (хотя всю твою ФП-шизу и 0 новых мыслей за последние годы я в рот ебал, ты один из самых скучных долбоебов на борде). Ты спиздил у меня аргумент (потому что сам лучше не придумать не можешь), но при этом полил (как обычно) кучей графоманского дерьма, полного самолюбования. Твой оппонент доебался до этого самолюбования, и ты, как собачка, побежал за ним, в вашем демагогическом самоотсосе.
>А теперь вопрос - почему меня должно ебать, что я разломал дискуссию двум демагогам?
Потому что этот демагог - ты, лол. Вот твои посты.
>>615581>>615483>>615445
Я прошел мимо и захотел помочь твоей точке зрения (хотя всю твою ФП-шизу и 0 новых мыслей за последние годы я в рот ебал, ты один из самых скучных долбоебов на борде). Ты спиздил у меня аргумент (потому что сам лучше не придумать не можешь), но при этом полил (как обычно) кучей графоманского дерьма, полного самолюбования. Твой оппонент доебался до этого самолюбования, и ты, как собачка, побежал за ним, в вашем демагогическом самоотсосе.
>>615447
А что непонятно-то? Вот объявления функций, вот тела функций, вот вызовы функций.
Никаких перещёлкиваний регистриков при этом не происходит, машина никем не командует, в отличие от императивщины, где машина приказывает программисту помнить где там чё в ней хранится. Функциональный и объектный подход - это сила, это путь наверх, императивные портянки это обсасыванье байтов всемогущей машине, это путь во времена рабства.
>кидает понятную нотацию
>пытается высмеять, напирая на непонятность
А что непонятно-то? Вот объявления функций, вот тела функций, вот вызовы функций.
Никаких перещёлкиваний регистриков при этом не происходит, машина никем не командует, в отличие от императивщины, где машина приказывает программисту помнить где там чё в ней хранится. Функциональный и объектный подход - это сила, это путь наверх, императивные портянки это обсасыванье байтов всемогущей машине, это путь во времена рабства.
>>615602
А я и не утверждал будто я не демагог, лул. Что не отменяет того, что вы двое - демагоги.
Подожди, в приведённых тобой постах нет ничего про ФП.
Я наткнулся на пост >>615263 и решил позабавиться над очевидной хуйнёй
Не путай меня со своими протыкателями, которые уже миллион лет тебя тралируют тут (сочувствую кстати, если так), я лично и в фп-тред не заходил, если он тут вообще есть.
А я и не утверждал будто я не демагог, лул. Что не отменяет того, что вы двое - демагоги.
>всю твою ФП-шизу
Подожди, в приведённых тобой постах нет ничего про ФП.
Я наткнулся на пост >>615263 и решил позабавиться над очевидной хуйнёй
>Математика - лженаука, она изучает несуществующий предмет, покажи мне отдельно существующее число в природе.
Не путай меня со своими протыкателями, которые уже миллион лет тебя тралируют тут (сочувствую кстати, если так), я лично и в фп-тред не заходил, если он тут вообще есть.
>>615582
Человеку естественна запись алгоритма, а не функций. Ну кроме полутора савантов.
Человеку естественна запись алгоритма, а не функций. Ну кроме полутора савантов.
>>615603
У тебя в голове походу что то щелкает
>кидает понятную нотацию
>брейнфак ym.yn.ym.yn.ym.yn ЗАТО РЕГИСТРЫ НЕ ЩЕЛКАЮТ
У тебя в голове походу что то щелкает
>>615631
Хм, с одной стороны верно, но с другой вспомни школу:
"корень из икс это такое число, которое в квадрате даёт икс"
Чисто декларативное описание ведь. А про метод Ньютона никто в школе и не вспоминает. Значит не только алгоритмами нам свойственно мыслить.
Хм, с одной стороны верно, но с другой вспомни школу:
"корень из икс это такое число, которое в квадрате даёт икс"
Чисто декларативное описание ведь. А про метод Ньютона никто в школе и не вспоминает. Значит не только алгоритмами нам свойственно мыслить.
>>615602
А, пробежал по треду и понял, что тут произошло.
Вот этот чел - >>610689 , который пишет зачем-то с большой буквы термины - не я.
Потом пришёл я и встал на его сторону.
Потом пришёл ты и встал на мою сторону.
Потом ты решил, что раз мы защищаем с тем аноном один тезис, следовательно мы - один человек.
Что-ж, ты ошибся.
А, пробежал по треду и понял, что тут произошло.
Вот этот чел - >>610689 , который пишет зачем-то с большой буквы термины - не я.
Потом пришёл я и встал на его сторону.
Потом пришёл ты и встал на мою сторону.
Потом ты решил, что раз мы защищаем с тем аноном один тезис, следовательно мы - один человек.
Что-ж, ты ошибся.
>>615634
Походу у тебя в реале фак с твоим брейном произошёл.
>функция принимает такие-то аргументы и возвращает такие-то значения
>брейнфак
Походу у тебя в реале фак с твоим брейном произошёл.
>>615638
А где-то подписывался, что буду число в природе показывать? Я сказал
Число - отображение реальности, её модель, а не сама реальность.
Мы можем с такой моделью ракеты в космос запускать. С такой моделью мы можем спроектировать протоколы для обмена сообщениями на сосаче, значит нам обоим есть выгода от этой модели. Вот и обоснование нужности математики. А шифрование с открытым ключом это вообще на 99.9% "ненужная и реально в природе не существующая" математика.
>но число в природе так показать и не смог
А где-то подписывался, что буду число в природе показывать? Я сказал
>>покажи мне отдельно существующее число в природе. Их нет.
>Из этого не следует, что концепция числа ничего не значит, т.к. всякое число является отображением реальности, как я только что показал на примере пальцев и людей.
Число - отображение реальности, её модель, а не сама реальность.
Мы можем с такой моделью ракеты в космос запускать. С такой моделью мы можем спроектировать протоколы для обмена сообщениями на сосаче, значит нам обоим есть выгода от этой модели. Вот и обоснование нужности математики. А шифрование с открытым ключом это вообще на 99.9% "ненужная и реально в природе не существующая" математика.
>>615685
>А где-то подписывался, что буду Бога в природе показывать? >Бог - отображение реальности, её модель, а не сама реальность.
>Мы можем с такой моделью ракеты в космос запускать. С такой моделью мы можем спроектировать протоколы для обмена сообщениями на сосаче, значит нам обоим есть выгода от этой модели. Вот и обоснование нужности Бога. А шифрование с открытым ключом это вообще на 99.9% "ненужный и реально в природе не существующий" Бог
>>615666
Но нам-то, простым людям, без волшебной инъекции как быть?
>в программе, записанной совокупностью чётких инструкций перехода, разобраться может разве что мыщьх, которому в детстве хлористого кальция укололи, потому что только аутизм способен заставить человека добровольно становиться рабом машины, следящего за состоянием каждого регистрика
Но нам-то, простым людям, без волшебной инъекции как быть?
>>615702
Бред. Бог в представлении верующих это именно что сама реальность и есть. Мда, ни в науке ты не силён, ни в богословии, ни в демагогии.
>Бог - отображение реальности, её модель, а не сама реальность.
Бред. Бог в представлении верующих это именно что сама реальность и есть. Мда, ни в науке ты не силён, ни в богословии, ни в демагогии.
>>615712
Макарошки могу, а положения планет посчитать - нет, слишком заёбисто.
Макарошки могу, а положения планет посчитать - нет, слишком заёбисто.
>>615718
Ты с каким нибудь буддизмом перепутал.
>Бог в представлении верующих это именно что сама реальность
Ты с каким нибудь буддизмом перепутал.
>>615736
Ну если бог это не сама реальность, а мужик на небе, то не мне доказывать его существование.
А доказать математику - запросто. Вот я зашифровал сообщение открытым ключом, вот ты его не можешь за обозримое время расшифровать, через день сдаёшься я тебе даю закрытый ключ и ты расшифровываешь Потом я описываю, как мне это удалось - с помощью несуществующих в природе чисел, и ты такой "ой бля, ну ладно, не существуют и хуй с ними, раз мои задачи решают значит так и быть". Либо ты отказываешься от шифрования, а значит немедленно выходишь с двача, потому что тут https, который не работает, потому что спроектирован с помощью неработающей лженауки.
Ну если бог это не сама реальность, а мужик на небе, то не мне доказывать его существование.
А доказать математику - запросто. Вот я зашифровал сообщение открытым ключом, вот ты его не можешь за обозримое время расшифровать, через день сдаёшься я тебе даю закрытый ключ и ты расшифровываешь Потом я описываю, как мне это удалось - с помощью несуществующих в природе чисел, и ты такой "ой бля, ну ладно, не существуют и хуй с ними, раз мои задачи решают значит так и быть". Либо ты отказываешься от шифрования, а значит немедленно выходишь с двача, потому что тут https, который не работает, потому что спроектирован с помощью неработающей лженауки.
>>615770
Ок.
>Ну короче боженька там чет делает с ключами и у тебя двач работает. А показать числа в природе не смогу
Ок.
>>615777
В этом и разница: в одном случае тебя просят, умоляют доказать, но ты ничего не можешь доказать, потому что не можешь, а в другом тебе говорят "я могу это доказать, садись и слушай", но ты осознанно отказываешься слушать доказательство. ССЗБ.
В этом и разница: в одном случае тебя просят, умоляют доказать, но ты ничего не можешь доказать, потому что не можешь, а в другом тебе говорят "я могу это доказать, садись и слушай", но ты осознанно отказываешься слушать доказательство. ССЗБ.
>>615777
>у меня пять человек в команде
>отправляемся в поход на неделю
>сколько суточных пайков ложить в мешок?
>хмм, пять умножить на семь?
>не, нихуя, числа сами по себе ничего не означают, а умножить людей на дни и получить пайки я не могу, это бред
>поэтому будет методом проб и ошибок устанавливать нужное число пайков
>точнее не число, а прям вот сами пайки в реальности, а то чисел ведь нет
>если на каннибализм не перейдут, и лишних пайков не останется, значит взяли ровно столько существующих в реальности пайков, сколько нужно
>зато об абстракции не зашкварились
>подожди, а как ты понимаешь такие слова как союзы и предлоги, если они ничего в релаьности не означают?
>заткнись сука
>>615799
А где-то подписывался, что буду число в природе показывать? Я сказал
Число - отображение реальности, её модель, а не сама реальность.
Мы можем с такой моделью ракеты в космос запускать. С такой моделью мы можем спроектировать протоколы для обмена сообщениями на сосаче, значит нам обоим есть выгода от этой модели. Вот и обоснование нужности математики. А шифрование с открытым ключом это вообще на 99.9% "ненужная и реально в природе не существующая" математика.
А где-то подписывался, что буду число в природе показывать? Я сказал
>>покажи мне отдельно существующее число в природе. Их нет.
>Из этого не следует, что концепция числа ничего не значит, т.к. всякое число является отображением реальности, как я только что показал на примере пальцев и людей.
Число - отображение реальности, её модель, а не сама реальность.
Мы можем с такой моделью ракеты в космос запускать. С такой моделью мы можем спроектировать протоколы для обмена сообщениями на сосаче, значит нам обоим есть выгода от этой модели. Вот и обоснование нужности математики. А шифрование с открытым ключом это вообще на 99.9% "ненужная и реально в природе не существующая" математика.
>>615357
"Поллинг" и "Событие" - разные вещи.
Где есть возможность применить второе вместо первого, следует использовать именно событие.
Так как поллинг при частом опросе пожирает процессорное время, а если экономить, то между опросами появляется интервал не реагирования, то есть при поллинге возникает одно из двух зол - или затратность при большой скорости реагирования или задержка реагирования при экономии ресурсов.
"Событие" действует иначе :
Никаких судорожных движений код не совершает, при этом временной интервал между наступлением события и реакцией на него - предельно минимален.
Класс имеет встроенный механизм для проектирования событий.
По правде говоря, событийно-управляемое приложение можно написать и без использования классов. Однако списком или структурой такое приложение не ограничится. Это будет, не менее сложный код, чем код, основанный на применении класса и даже тогда возможностей класса он иметь не будет :
Тут ведь в чём "волшебство" ? - из класса можно штамповать любое количество "экземпляров класса"(объекты), всего одной строкой кода.
На самом деле, и тут можно обойтись без применения класса, написав код, между прочим, мало чем, принципиально, отличающийся от класса. И это похвально ибо не секрет, что код, хотя бы на один уровень абстракции ниже, чем более высокоуровневый, имеет возможность оказаться, по сравнению с ним, оптимальным.
Хотя более простым и читабельным - он точно не окажется.
Читабельность наших изваяний может быть востребована в определённом случае : когда у твоего кода много поклонников и критиков.
Но если ты склонен писать только не доступные уразумению бездарных толп, шедевры - то тогда, конечно, не надо гоняться за простотой. Но и о здравом смысле забывать негоже :
А то ведь, была такая передача про Японию, однажды, в телевизоре, дак там один невьебенный Мастер удочек - бамбуковую удочку тридцать лет делал ! - и сделал.
А другой сделал рубанок - дак тот рубанок с доски срезал стружку толщиной восемь микрон, прозрачная !
Надлежит ли нам уподобится этим экспертам ? - скажу честно "хрен его знат".
>Поллинг.
"Поллинг" и "Событие" - разные вещи.
Где есть возможность применить второе вместо первого, следует использовать именно событие.
Так как поллинг при частом опросе пожирает процессорное время, а если экономить, то между опросами появляется интервал не реагирования, то есть при поллинге возникает одно из двух зол - или затратность при большой скорости реагирования или задержка реагирования при экономии ресурсов.
"Событие" действует иначе :
Никаких судорожных движений код не совершает, при этом временной интервал между наступлением события и реакцией на него - предельно минимален.
Класс имеет встроенный механизм для проектирования событий.
По правде говоря, событийно-управляемое приложение можно написать и без использования классов. Однако списком или структурой такое приложение не ограничится. Это будет, не менее сложный код, чем код, основанный на применении класса и даже тогда возможностей класса он иметь не будет :
Тут ведь в чём "волшебство" ? - из класса можно штамповать любое количество "экземпляров класса"(объекты), всего одной строкой кода.
На самом деле, и тут можно обойтись без применения класса, написав код, между прочим, мало чем, принципиально, отличающийся от класса. И это похвально ибо не секрет, что код, хотя бы на один уровень абстракции ниже, чем более высокоуровневый, имеет возможность оказаться, по сравнению с ним, оптимальным.
Хотя более простым и читабельным - он точно не окажется.
Читабельность наших изваяний может быть востребована в определённом случае : когда у твоего кода много поклонников и критиков.
Но если ты склонен писать только не доступные уразумению бездарных толп, шедевры - то тогда, конечно, не надо гоняться за простотой. Но и о здравом смысле забывать негоже :
А то ведь, была такая передача про Японию, однажды, в телевизоре, дак там один невьебенный Мастер удочек - бамбуковую удочку тридцать лет делал ! - и сделал.
А другой сделал рубанок - дак тот рубанок с доски срезал стружку толщиной восемь микрон, прозрачная !
Надлежит ли нам уподобится этим экспертам ? - скажу честно "хрен его знат".
>>615357
"Поллинг" и "Событие" - разные вещи.
Где есть возможность применить второе вместо первого, следует использовать именно событие.
Так как поллинг при частом опросе пожирает процессорное время, а если экономить, то между опросами появляется интервал не реагирования, то есть при поллинге возникает одно из двух зол - или затратность при большой скорости реагирования или задержка реагирования при экономии ресурсов.
"Событие" действует иначе :
Никаких судорожных движений код не совершает, при этом временной интервал между наступлением события и реакцией на него - предельно минимален.
Класс имеет встроенный механизм для проектирования событий.
По правде говоря, событийно-управляемое приложение можно написать и без использования классов. Однако списком или структурой такое приложение не ограничится. Это будет, не менее сложный код, чем код, основанный на применении класса и даже тогда возможностей класса он иметь не будет :
Тут ведь в чём "волшебство" ? - из класса можно штамповать любое количество "экземпляров класса"(объекты), всего одной строкой кода.
На самом деле, и тут можно обойтись без применения класса, написав код, между прочим, мало чем, принципиально, отличающийся от класса. И это похвально ибо не секрет, что код, хотя бы на один уровень абстракции ниже, чем более высокоуровневый, имеет возможность оказаться, по сравнению с ним, оптимальным.
Хотя более простым и читабельным - он точно не окажется.
Читабельность наших изваяний может быть востребована в определённом случае : когда у твоего кода много поклонников и критиков.
Но если ты склонен писать только не доступные уразумению бездарных толп, шедевры - то тогда, конечно, не надо гоняться за простотой. Но и о здравом смысле забывать негоже :
А то ведь, была такая передача про Японию, однажды, в телевизоре, дак там один невьебенный Мастер удочек - бамбуковую удочку тридцать лет делал ! - и сделал.
А другой сделал рубанок - дак тот рубанок с доски срезал стружку толщиной восемь микрон, прозрачная !
Надлежит ли нам уподобится этим экспертам ? - скажу честно "хрен его знат".
>Поллинг.
"Поллинг" и "Событие" - разные вещи.
Где есть возможность применить второе вместо первого, следует использовать именно событие.
Так как поллинг при частом опросе пожирает процессорное время, а если экономить, то между опросами появляется интервал не реагирования, то есть при поллинге возникает одно из двух зол - или затратность при большой скорости реагирования или задержка реагирования при экономии ресурсов.
"Событие" действует иначе :
Никаких судорожных движений код не совершает, при этом временной интервал между наступлением события и реакцией на него - предельно минимален.
Класс имеет встроенный механизм для проектирования событий.
По правде говоря, событийно-управляемое приложение можно написать и без использования классов. Однако списком или структурой такое приложение не ограничится. Это будет, не менее сложный код, чем код, основанный на применении класса и даже тогда возможностей класса он иметь не будет :
Тут ведь в чём "волшебство" ? - из класса можно штамповать любое количество "экземпляров класса"(объекты), всего одной строкой кода.
На самом деле, и тут можно обойтись без применения класса, написав код, между прочим, мало чем, принципиально, отличающийся от класса. И это похвально ибо не секрет, что код, хотя бы на один уровень абстракции ниже, чем более высокоуровневый, имеет возможность оказаться, по сравнению с ним, оптимальным.
Хотя более простым и читабельным - он точно не окажется.
Читабельность наших изваяний может быть востребована в определённом случае : когда у твоего кода много поклонников и критиков.
Но если ты склонен писать только не доступные уразумению бездарных толп, шедевры - то тогда, конечно, не надо гоняться за простотой. Но и о здравом смысле забывать негоже :
А то ведь, была такая передача про Японию, однажды, в телевизоре, дак там один невьебенный Мастер удочек - бамбуковую удочку тридцать лет делал ! - и сделал.
А другой сделал рубанок - дак тот рубанок с доски срезал стружку толщиной восемь микрон, прозрачная !
Надлежит ли нам уподобится этим экспертам ? - скажу честно "хрен его знат".
>>615880
То ли я нихуя не смыслю, то ли ты.
Вот как мне известно: события в компьютерах организуются одним из двух способов: либо event loop, что означает "я дрочу процессор каждые n секунд и мне похуй на быстродействие" (что кстати объясняет почему в некоторых игрушках типа скайрима всё рушится если фпс отклоняется от строго заданного числа - там event loop привязан к частоте кадров), либо аппаратные прерывания (вот тут действительно производительность не страдает, ибо обработчик прерываний запускается не постоянно).
Но как именно в плане быстродействия держать ивент луп может быть быстрее, чем опрашивать объект? Чего я не вижу?
>"Событие" действует иначе :
>Никаких судорожных движений код не совершает, при этом временной интервал между наступлением события и реакцией на него - предельно минимален.
>Класс имеет встроенный механизм для проектирования событий.
То ли я нихуя не смыслю, то ли ты.
Вот как мне известно: события в компьютерах организуются одним из двух способов: либо event loop, что означает "я дрочу процессор каждые n секунд и мне похуй на быстродействие" (что кстати объясняет почему в некоторых игрушках типа скайрима всё рушится если фпс отклоняется от строго заданного числа - там event loop привязан к частоте кадров), либо аппаратные прерывания (вот тут действительно производительность не страдает, ибо обработчик прерываний запускается не постоянно).
Но как именно в плане быстродействия держать ивент луп может быть быстрее, чем опрашивать объект? Чего я не вижу?
>>607925 (OP)
Ух, теоретики как раскукарекались-то.
Ух, теоретики как раскукарекались-то.
>>615880
Чисто интуитивно, мне кажется, что под капотом, на уровне ОС или фреймворка там все равно поллинг. Ну, не считая конечно некоторых аппаратных прерываний процессора. Но думаю их можно исключить из рассмотрения, потому что они там где-то на уровне ядра, драйверов. Да и даже прерывание не бесплатное, не помню сколько, но несколько тактов уйдет на сохранение всех регистров. А дальше мы имеем что-то вроде circular buffer, который постоянно должны проверять в некоем event-loop, по расписанию шедулера, или просто всегда когда можем, когда дойдет выполнение. А наполняется этот буфер уже событиями из других потоков. Так что ИМХО все события это просто синтаксический сахар, и никаких особых трудностией их использовать без классов и объектов никогда не было. А насчет читабельности - ну там просто такой switch с пачкой событий, вполне себе красиво выглядящий.
Чисто интуитивно, мне кажется, что под капотом, на уровне ОС или фреймворка там все равно поллинг. Ну, не считая конечно некоторых аппаратных прерываний процессора. Но думаю их можно исключить из рассмотрения, потому что они там где-то на уровне ядра, драйверов. Да и даже прерывание не бесплатное, не помню сколько, но несколько тактов уйдет на сохранение всех регистров. А дальше мы имеем что-то вроде circular buffer, который постоянно должны проверять в некоем event-loop, по расписанию шедулера, или просто всегда когда можем, когда дойдет выполнение. А наполняется этот буфер уже событиями из других потоков. Так что ИМХО все события это просто синтаксический сахар, и никаких особых трудностией их использовать без классов и объектов никогда не было. А насчет читабельности - ну там просто такой switch с пачкой событий, вполне себе красиво выглядящий.
>>615913
Может быть он имел в виду, что опрашиваются все объекты постоянно? Хз. Хотя с другой стороны, а ведь они все равно опрашиваются постоянно. К примеру, событие mouseOver. В любом случае где-то под капотом будет цикл foreach(r in rect) if m.x>=r.x && m.x<=r.x+r.w и т.д.
>Но как именно в плане быстродействия держать ивент луп может быть быстрее, чем опрашивать объект?
Может быть он имел в виду, что опрашиваются все объекты постоянно? Хз. Хотя с другой стороны, а ведь они все равно опрашиваются постоянно. К примеру, событие mouseOver. В любом случае где-то под капотом будет цикл foreach(r in rect) if m.x>=r.x && m.x<=r.x+r.w и т.д.
>>615922
Мало ли что там "всё равно".
В конечном итоге там всё равно несколько регистров, каждый из которых является всего лишь аналогом числовой переменной - но это не значит, что если написать, например, полный аналог Ассемблерного кода на высокоуровневом языке(а это вполне возможно), то будет хорошо.
Если бы цикл Loop на высокоуровневом языке оборачивался с частотой несколько сотен мегагерц... то почему бы и нет ?
Можно было бы тогда даже многозадачные приложения писать, аналогично тому, как пишется многозадачное приложение для микроконтроллера и не нужны никакие "события".
Вернее, "события" делались бы простыми проверками тех или иных условий в беспрерывно работающем цикле. На контроллерах так и делается.
Да и процессор, наверняка, так же, принципиально, работает.
Но вот не крутится цикл Loop в приложении, которое само работает в порядке очереди, притом, не самой приоритетной очереди, в порядке других задач. Этот цикл может оказаться, на самом деле, я не знаю, циклом десятого уровня вложенности, если отсчитывать от цикла работы процессора.
Поэтому стиль программирования для низкоуровневого не стоит применять(хотя работать будет) по отношению к высокоуровневому коду.
>Чисто интуитивно, мне кажется, что под капотом, на уровне ОС или фреймворка там все равно поллинг.
Мало ли что там "всё равно".
В конечном итоге там всё равно несколько регистров, каждый из которых является всего лишь аналогом числовой переменной - но это не значит, что если написать, например, полный аналог Ассемблерного кода на высокоуровневом языке(а это вполне возможно), то будет хорошо.
Если бы цикл Loop на высокоуровневом языке оборачивался с частотой несколько сотен мегагерц... то почему бы и нет ?
Можно было бы тогда даже многозадачные приложения писать, аналогично тому, как пишется многозадачное приложение для микроконтроллера и не нужны никакие "события".
Вернее, "события" делались бы простыми проверками тех или иных условий в беспрерывно работающем цикле. На контроллерах так и делается.
Да и процессор, наверняка, так же, принципиально, работает.
Но вот не крутится цикл Loop в приложении, которое само работает в порядке очереди, притом, не самой приоритетной очереди, в порядке других задач. Этот цикл может оказаться, на самом деле, я не знаю, циклом десятого уровня вложенности, если отсчитывать от цикла работы процессора.
Поэтому стиль программирования для низкоуровневого не стоит применять(хотя работать будет) по отношению к высокоуровневому коду.
>>616006
Да это все понятно, но никак ты не избавишься от этого евент лупа, сколько не закапывай его под ковер. Как не избавишься от foreach, пиша map/reduce. Ну если тебя так смущает event loop, напиши его где-нибудь в файлике main один раз и спрячь с глаз, а погоди, твой фреймворк с событиями ровно так и поступает.
Да это все понятно, но никак ты не избавишься от этого евент лупа, сколько не закапывай его под ковер. Как не избавишься от foreach, пиша map/reduce. Ну если тебя так смущает event loop, напиши его где-нибудь в файлике main один раз и спрячь с глаз, а погоди, твой фреймворк с событиями ровно так и поступает.
>>616010
А я и не собирался "избавляться" от евент лупа. Он никуда деться не может.
Просто если мы его будем сами писать в своём коде, он будет выполняться с одной скоростью,
Но если мы "оставим его под ковром", то там он выполняется совсем с другой скоростью, не достижимой для кода, который мы пишем.
Именно поэтому не надо его из под ковра вытаскивать.
Вот аналогия :
Есть внутренняя функция языка "InStrB()", она скрыта от глаз "под капотом" и наверняка написана на машинных инструкциях.
Недавно я попробовал написать её аналог на самом языке - скорость выполнения написанного мною аналога оказалась в тридцать раз медленнее ! - что бы мы не вытаскивали из под капота в код высокоуровневой программы, окажется медленнее, чем вызов интерфейсного метода или оператора или внутренней функции языка.
Там, под ковром(или за методом WinAPI), может и вращается цикл, но он, по любому гораздо подвижнее цикла, который мы можем написать в своём коде.
>но никак ты не избавишься от этого евент лупа, сколько не закапывай его под ковер.
А я и не собирался "избавляться" от евент лупа. Он никуда деться не может.
Просто если мы его будем сами писать в своём коде, он будет выполняться с одной скоростью,
Но если мы "оставим его под ковром", то там он выполняется совсем с другой скоростью, не достижимой для кода, который мы пишем.
Именно поэтому не надо его из под ковра вытаскивать.
Вот аналогия :
Есть внутренняя функция языка "InStrB()", она скрыта от глаз "под капотом" и наверняка написана на машинных инструкциях.
Недавно я попробовал написать её аналог на самом языке - скорость выполнения написанного мною аналога оказалась в тридцать раз медленнее ! - что бы мы не вытаскивали из под капота в код высокоуровневой программы, окажется медленнее, чем вызов интерфейсного метода или оператора или внутренней функции языка.
Там, под ковром(или за методом WinAPI), может и вращается цикл, но он, по любому гораздо подвижнее цикла, который мы можем написать в своём коде.
>>616034
Что следует из?
>Просто если мы его будем сами писать в своём коде, он будет выполняться с одной скоростью,
>Но если мы "оставим его под ковром", то там он выполняется совсем с другой скоростью, не достижимой для кода, который мы пишем.
Что следует из?
>>616034
На нормальном языке c++ такой проблемы не возникнет.
>Недавно я попробовал написать её аналог на самом языке - скорость выполнения написанного мною аналога оказалась в тридцать раз медленнее
На нормальном языке c++ такой проблемы не возникнет.
>>616108
Пишутся, конечно. Но названия понятий не относятся к именам собственным.
https://ru.wikipedia.org/wiki/Имя_собственное
Пишутся, конечно. Но названия понятий не относятся к именам собственным.
https://ru.wikipedia.org/wiki/Имя_собственное
>>616049
Дак я же привёл пример "вытащенной из под капота" функции.
Но ты можешь и сам попробовать ловить "событие" путём опроса значения какой либо переменной с помошью зацикленного условия, с одной стороны.
И использовать системную функцию "MsgWaitForMultipleObjects", с другой.
Протестируй результативность двух вариантов кода :
1. Посмотри чо показывает счётчик загрузки процессора.
2. Измерь интервал, между ожидаемым событием и реакцией на него.
Здесь : http://www.firststeps.ru/mfc/msdn/r.php?85 список ожидающих функций
>Что следует из?
Дак я же привёл пример "вытащенной из под капота" функции.
Но ты можешь и сам попробовать ловить "событие" путём опроса значения какой либо переменной с помошью зацикленного условия, с одной стороны.
И использовать системную функцию "MsgWaitForMultipleObjects", с другой.
Протестируй результативность двух вариантов кода :
1. Посмотри чо показывает счётчик загрузки процессора.
2. Измерь интервал, между ожидаемым событием и реакцией на него.
Здесь : http://www.firststeps.ru/mfc/msdn/r.php?85 список ожидающих функций
>>615263
В природе есть понятие количества. Цифры это абстрактные величины, которые обозначают количества, меры, объемы, единицы измерения. Математика это та наука, которая абстрактное делает явным, пригодным к изучению. Чтобы рассуждать о явлениях, необходим язык, который будет описывать эти явления. Математика дает такие языки. Арифметика это не более чем формальная система, язык описания некоторых явлений.
Одна из самых простых формальных систем - логика высказываний. На ее основе строятся более сложные. В твоих словах есть противоречия логике высказываний. Например, что математика не наука только потому, что в живой природе нет чисел - это наглая ложь. Я уже доказал, что числа всего лишь язык описания количества. Самое явление количества совершенно естественно, оно присутствует в природе, оно незыблемо. Далее не вижу смысла опровергать твои слова, хотя это не сложно сделать. Просто если у тебя в логике высказываний противоречия, то что будет если говорить о более сложных вещах.
В природе есть понятие количества. Цифры это абстрактные величины, которые обозначают количества, меры, объемы, единицы измерения. Математика это та наука, которая абстрактное делает явным, пригодным к изучению. Чтобы рассуждать о явлениях, необходим язык, который будет описывать эти явления. Математика дает такие языки. Арифметика это не более чем формальная система, язык описания некоторых явлений.
Одна из самых простых формальных систем - логика высказываний. На ее основе строятся более сложные. В твоих словах есть противоречия логике высказываний. Например, что математика не наука только потому, что в живой природе нет чисел - это наглая ложь. Я уже доказал, что числа всего лишь язык описания количества. Самое явление количества совершенно естественно, оно присутствует в природе, оно незыблемо. Далее не вижу смысла опровергать твои слова, хотя это не сложно сделать. Просто если у тебя в логике высказываний противоречия, то что будет если говорить о более сложных вещах.
>>616134
Да я жопой прочитал, сорь
Да я жопой прочитал, сорь
>>615447
Если тебе непонятны эти символы, это не означает, что это что-то сложное, убогое, невыразительное. Вот эти несколько строк кода могут выполнять столько же, сколько сотня строк для Машины Тьюринга. Выходит, что лямбда-асбтракции более выразительны, более лаконичны. Что собственно и требовалось доказать.
Если тебе непонятны эти символы, это не означает, что это что-то сложное, убогое, невыразительное. Вот эти несколько строк кода могут выполнять столько же, сколько сотня строк для Машины Тьюринга. Выходит, что лямбда-асбтракции более выразительны, более лаконичны. Что собственно и требовалось доказать.
>>616151
Если тебе непонятны goto в машине тьюринга, это не означает что это что-то сложное, убогое, невыразительное. Вот эти несколько goto могут выполнять столько же, сколько сотня строк лямбда калькулуса. Выходит, что машина Тьюринга более выразительна, более лаконична.
Что собственно и требовалось доказать.
Если тебе непонятны goto в машине тьюринга, это не означает что это что-то сложное, убогое, невыразительное. Вот эти несколько goto могут выполнять столько же, сколько сотня строк лямбда калькулуса. Выходит, что машина Тьюринга более выразительна, более лаконична.
Что собственно и требовалось доказать.
>>616142
Дурака включил? Сколько у детей родителей? Двое. Сколько у человека рук? Две. Сколько носов, ртов, голов? По одному (ой).
Дурака включил? Сколько у детей родителей? Двое. Сколько у человека рук? Две. Сколько носов, ртов, голов? По одному (ой).
>>616157
Дети есть. Руки есть. Носы, рты, головы есть. Чисел как не было и нет. Твои оправдания?
Дети есть. Руки есть. Носы, рты, головы есть. Чисел как не было и нет. Твои оправдания?
>>616155
Еще как означает. Из десятка комбинаторов можно сложить сколько угодно мощный язык программирования. И это займет крошечный объем текста. Потому что высокая выразительность, лаконичность. Высокий уровень абстракции. Машина Тьюринга обладает низкой выразительность, лаконичностью, крайне низким уровнем абстракции. Поэтому нельзя на ней сделать тоже самое как с помощью десятка комбинаторов, не написав тысячи строк кода, который к тому же будет еще и дурно пахнуть, будет неподдерживаемым.
>Если тебе непонятны goto в машине тьюринга, это не означает что это что-то сложное, убогое, невыразительное. Вот эти несколько goto могут выполнять столько же, сколько сотня строк лямбда калькулуса. Выходит, что машина Тьюринга более выразительна, более лаконична.
Еще как означает. Из десятка комбинаторов можно сложить сколько угодно мощный язык программирования. И это займет крошечный объем текста. Потому что высокая выразительность, лаконичность. Высокий уровень абстракции. Машина Тьюринга обладает низкой выразительность, лаконичностью, крайне низким уровнем абстракции. Поэтому нельзя на ней сделать тоже самое как с помощью десятка комбинаторов, не написав тысячи строк кода, который к тому же будет еще и дурно пахнуть, будет неподдерживаемым.
>>607925 (OP)
Один долбоеб, думающий, что понимает ООП, пытается что-то доказать другому такому же долбоебу.
Один долбоеб, думающий, что понимает ООП, пытается что-то доказать другому такому же долбоебу.
>>616119
Дак InStrB это как раз и есть внутренняя функция языка VB6
Просто я сделал то, что не должен был делать :
Я описал функцию с помощью набора других.
Внутренние функции и операторы выполняются быстро, но если вместо того, чтобы просто вызвать функцию или оператор, вызвать набор других, к тому же в сдвоенном цикле - получается "В Сочи через Магочи", на каком бы сверхбыстром языке, это не делалось, даже если сильно верить в обратное.
>На нормальном языке c++ такой проблемы не возникнет.
Дак InStrB это как раз и есть внутренняя функция языка VB6
Просто я сделал то, что не должен был делать :
Я описал функцию с помощью набора других.
Внутренние функции и операторы выполняются быстро, но если вместо того, чтобы просто вызвать функцию или оператор, вызвать набор других, к тому же в сдвоенном цикле - получается "В Сочи через Магочи", на каком бы сверхбыстром языке, это не делалось, даже если сильно верить в обратное.
>>616140
Это не название географического места и не имя человека (и не один из ещё кучи случаев которые мне лень перечислять).
Потому что в противном случае у нас будут Физика, Химия, Теорема Котельникова, Электронно-лучевая трубка, Электромагнитное излучение и прочие перлы.
Это не название географического места и не имя человека (и не один из ещё кучи случаев которые мне лень перечислять).
Потому что в противном случае у нас будут Физика, Химия, Теорема Котельникова, Электронно-лучевая трубка, Электромагнитное излучение и прочие перлы.
>>616161
Чисел вообще не нужно. Есть понятие количества, которое незыблемо на планете Земля. Можно описывать его как угодно, хоть с помощью палочек, как это делали в старину. Можно с натяжкой сказать, что чисел нет, но если человек отрицает существования количественных явлений вообще, то это попахивает умственной отсталостью.
Чисел вообще не нужно. Есть понятие количества, которое незыблемо на планете Земля. Можно описывать его как угодно, хоть с помощью палочек, как это делали в старину. Можно с натяжкой сказать, что чисел нет, но если человек отрицает существования количественных явлений вообще, то это попахивает умственной отсталостью.
>>616155
В том то и дело, что не могут. Доказывай.
Выйдет, как только будет доказан пункт 1.
Ишь какой, а собственно доказать для начала ты не пробовал?
>Вот эти несколько goto могут выполнять столько же, сколько сотня строк лямбда калькулуса.
В том то и дело, что не могут. Доказывай.
>Выходит, что лямбда-асбтракции более выразительны, более лаконичны
Выйдет, как только будет доказан пункт 1.
>Что собственно и требовалось доказать.
Ишь какой, а собственно доказать для начала ты не пробовал?
>>616181
Аппелирую к Авторитетам, которые все это уже сделали лет 80 назад.
Аппелирую к Авторитетам, которые все это уже сделали лет 80 назад.
>>616170
Имя собственное (калька с лат. nomen proprium, которое в свою очередь является калькой с греч. ὄνομα κύριον)[1], собственное имя[2] — имя существительное, обозначающее слово или словосочетание, предназначенное для именования конкретного, вполне определённого предмета или явления, выделяющее этот предмет или явление из ряда однотипных предметов или явлений.
http://gramota.ru/biblio/magazines/gramota/onomastics/28_126
У тебя плохие примеры. Электронно-лучевая трубка собирательное название. Теоремы различные и так принято писать с большой буквы. Насчет физики, химии, и прочего, тут надо смотреть контекст.
Имя собственное (калька с лат. nomen proprium, которое в свою очередь является калькой с греч. ὄνομα κύριον)[1], собственное имя[2] — имя существительное, обозначающее слово или словосочетание, предназначенное для именования конкретного, вполне определённого предмета или явления, выделяющее этот предмет или явление из ряда однотипных предметов или явлений.
http://gramota.ru/biblio/magazines/gramota/onomastics/28_126
У тебя плохие примеры. Электронно-лучевая трубка собирательное название. Теоремы различные и так принято писать с большой буквы. Насчет физики, химии, и прочего, тут надо смотреть контекст.
>>616182
Я третий долбоеб, не участвующий в тупых терминологических срачах, а решающий прикладные задачи. И похуй, как это называется: ООП, ФП, АОП, СОП, ХУЙП, НЕБОП, АЛЛАХП.
Я третий долбоеб, не участвующий в тупых терминологических срачах, а решающий прикладные задачи. И похуй, как это называется: ООП, ФП, АОП, СОП, ХУЙП, НЕБОП, АЛЛАХП.
>>616172
Естественно у природы никакого понятия количества нет. Как и вещества. Это просто вибрации на закольцованых струнах в 27-мерном пространстве.
Естественно у природы никакого понятия количества нет. Как и вещества. Это просто вибрации на закольцованых струнах в 27-мерном пространстве.
>>616186
Вот эту часть не учёл. То есть должно существовать некоторое множество обязательно конкретных предметов или явлений, из которого ты выделяешься названием.
Множество людей, множество рек, множество сайтов в интернете, множество компьютерных игр, множество ураганов (все ураганы как ураганы, а ты - "Катрина").
А лямбда-исчисление это из множества чего? Из множества формальных систем? Так формальные системы не конкретны, нельзя подойти, пальцем показать и сказать - "во, смотри, формальная система!"
Не-а. "Я доказал теорему Пифагора" а не "Я доказал Теорему Пифагора".
>имя существительное, обозначающее слово или словосочетание, предназначенное для именования конкретного, вполне определённого предмета или явления, выделяющее этот предмет или явление из ряда однотипных предметов или явлений[/B]
Вот эту часть не учёл. То есть должно существовать некоторое множество обязательно конкретных предметов или явлений, из которого ты выделяешься названием.
Множество людей, множество рек, множество сайтов в интернете, множество компьютерных игр, множество ураганов (все ураганы как ураганы, а ты - "Катрина").
А лямбда-исчисление это из множества чего? Из множества формальных систем? Так формальные системы не конкретны, нельзя подойти, пальцем показать и сказать - "во, смотри, формальная система!"
>Теоремы различные и так принято писать с большой буквы
Не-а. "Я доказал теорему Пифагора" а не "Я доказал Теорему Пифагора".
>>616188
Какое забавное противопоставление. А одно другому мешает?
Я решаю прикладные задачи так, как мне нравится, и в срачах слушаю аргументы тех, кто делает не так, мотаю на ус и модернизирую свои навыки. Диалектика в действии.
>не участвующий в тупых терминологических срачах, а решающий прикладные задачи
Какое забавное противопоставление. А одно другому мешает?
Я решаю прикладные задачи так, как мне нравится, и в срачах слушаю аргументы тех, кто делает не так, мотаю на ус и модернизирую свои навыки. Диалектика в действии.
>>616203
Так она написана в 80-х.
Так она написана в 80-х.
>>616191
В природе это есть. Есть озера большие и есть маленькие. Разница в КОЛИЧЕСТВЕ воды. Есть двуногие и четвероногие живые существа. Ты так неумело троллишь или у тебя действительно сдвиг по фазе? Просто если ты не ощущаешь вокруг себя количественные явления, то это умственная отсталость. И вряд ли с таким IQ тебя бы взяли в крутой универ на научную или инженерную специальность.
>Естественно у природы никакого понятия количества нет.
В природе это есть. Есть озера большие и есть маленькие. Разница в КОЛИЧЕСТВЕ воды. Есть двуногие и четвероногие живые существа. Ты так неумело троллишь или у тебя действительно сдвиг по фазе? Просто если ты не ощущаешь вокруг себя количественные явления, то это умственная отсталость. И вряд ли с таким IQ тебя бы взяли в крутой универ на научную или инженерную специальность.
>>616235
Взял самому себе за щёку, чекну.
Взял самому себе за щёку, чекну.
>>616223
Анон, ну я же, мать его, инженер. Какой от меня прок если я буду брать на заметку всё подряд без критической оценки?
Если ты мне продаёшь бронежилет, я сначала выстрелю в тебя, а потом куплю, если останется у кого покупать. Тезис должен столкнуться со старательно выкованным мной антитезисом, и лишь то, что останется на этом пожарище, будет истиной. Которую стоит брать на заметку.
>Бог любит нас и на всё Его воля
>Интересно, возьму на заметку.
Анон, ну я же, мать его, инженер. Какой от меня прок если я буду брать на заметку всё подряд без критической оценки?
Если ты мне продаёшь бронежилет, я сначала выстрелю в тебя, а потом куплю, если останется у кого покупать. Тезис должен столкнуться со старательно выкованным мной антитезисом, и лишь то, что останется на этом пожарище, будет истиной. Которую стоит брать на заметку.
>>616371
А им похуй было, есть что-то в природе или нет, они прикладную задачу решали, лол.
А им похуй было, есть что-то в природе или нет, они прикладную задачу решали, лол.
>>616238
Если твоё количество дискретно, то натуральные числа есть. Если оно непрерывно, то ты попадаешь на апории зенона и прочие парадоксы бесконечного деления пространства.
Мамкины нигилисты, у которых вообще ничего нет - скучные уебки, которым не дают тянки
Если твоё количество дискретно, то натуральные числа есть. Если оно непрерывно, то ты попадаешь на апории зенона и прочие парадоксы бесконечного деления пространства.
Мамкины нигилисты, у которых вообще ничего нет - скучные уебки, которым не дают тянки
>>614873
struct в тех же плюсах вроде. Тот же объект, только без методов. Питоновский named tuple. Словарь из того же питона.
struct в тех же плюсах вроде. Тот же объект, только без методов. Питоновский named tuple. Словарь из того же питона.
>>608094
Не в процедурном, а в функциональном. Очень просто. С помощью функций. Также как в СИКП реализуют рациональные числа и арифметику над ними.
>Поэтому ты расскажи как бы ты в процедурном стиле описал новый тип данных? У тебя есть стандартные типы - целое, число с плавающей точкой, символ, булеан. А тебе нужен, например такой тип как время в формате hh:mm:ss.
Не в процедурном, а в функциональном. Очень просто. С помощью функций. Также как в СИКП реализуют рациональные числа и арифметику над ними.
>>616375
И наверное для этой прикладной задачи пришлось дохуя всякой хуйни посчитать, да?
И наверное для этой прикладной задачи пришлось дохуя всякой хуйни посчитать, да?
>>616411
Нахуя тебе спрашивать тянок, если ты живешь в рабовладельческом строе?
Нахуя тебе спрашивать тянок, если ты живешь в рабовладельческом строе?
>>616169
Могу только повторить - если бы ты писал на c++ или asm такой проблемы бы не было.
Могу только повторить - если бы ты писал на c++ или asm такой проблемы бы не было.
>>616411
Приходит Зенон к тянке, а та усмехается - чтобы присунуть на шишечку, надо сначала на пол шишечки. А чтобы на полшишечки, надо сначала на четверть. Зенон обиделся и вышел.
Приходит Зенон к тянке, а та усмехается - чтобы присунуть на шишечку, надо сначала на пол шишечки. А чтобы на полшишечки, надо сначала на четверть. Зенон обиделся и вышел.
>>616579
Странно, вот не могу сказать что "в голосину проиграл" с этой шутки, но в то же время мне она кажется весьма остроумной.
Странно, вот не могу сказать что "в голосину проиграл" с этой шутки, но в то же время мне она кажется весьма остроумной.
>>616576
Касаемо Ассемблера - в нём нет внутренних функций, помимо элементарных операторов.
А в чём заключается "проблема", о которой ты говоришь ?
Никакая внутренняя функция языка, описанная с помощью других внутренних же функций этого языка не может работать медленнее, чем её костыляторная имитация. Вернее, может конечно. Только вряд ли разработчик языка мог написать такую.
Но ты мог бы посоревноваться с ним сам. Потому что лично я не питаю подобных тщеславных надежд.
>если бы ты писал на c++ или asm такой проблемы бы не было.
Касаемо Ассемблера - в нём нет внутренних функций, помимо элементарных операторов.
А в чём заключается "проблема", о которой ты говоришь ?
Никакая внутренняя функция языка, описанная с помощью других внутренних же функций этого языка не может работать медленнее, чем её костыляторная имитация. Вернее, может конечно. Только вряд ли разработчик языка мог написать такую.
Но ты мог бы посоревноваться с ним сам. Потому что лично я не питаю подобных тщеславных надежд.
>>613848
Можно. По моему, в стандартном апи пистона так часто делают. Попробуй листалку на urllib написать, например.
Можно. По моему, в стандартном апи пистона так часто делают. Попробуй листалку на urllib написать, например.
>>613847
Я только классы умею.
Я только классы умею.
>>618139
Завтра знакомому интеллектуалу расскажу, обязательно ПРООРЁТ.
Завтра знакомому интеллектуалу расскажу, обязательно ПРООРЁТ.
>>607925 (OP)
Простое переиспользование кода. Объекты можно рассматривать как модули. К тому же, ООП решает проблемы древних байтоебских типов.
Никто не использует НЕ ДОЛЖЕН использовать ООП в чистом виде. Но частичное его применение позволит правильно организовать данные программы.
Простое переиспользование кода. Объекты можно рассматривать как модули. К тому же, ООП решает проблемы древних байтоебских типов.
Никто не использует НЕ ДОЛЖЕН использовать ООП в чистом виде. Но частичное его применение позволит правильно организовать данные программы.
>>618442
Не стоит впутывать философию в программирование. Это не даст ничего практически полезного. Концепции(такие как ООП) нужны, но не стоит их накладывать на ИРЛ.
Не стоит впутывать философию в программирование. Это не даст ничего практически полезного. Концепции(такие как ООП) нужны, но не стоит их накладывать на ИРЛ.
>>618447
Ну тут я бы поспорил, если ты вебмакака-кодер то возможно, а вообще говоря сама сущность объекта, принципы как их выделять из окружающего мира, принципы наименования, долго можно продолжать. Можно еще вспомнить про этическую сторону (не делать программы убивающие людей, отнимающие работу, и т.д.)
Ну тут я бы поспорил, если ты вебмакака-кодер то возможно, а вообще говоря сама сущность объекта, принципы как их выделять из окружающего мира, принципы наименования, долго можно продолжать. Можно еще вспомнить про этическую сторону (не делать программы убивающие людей, отнимающие работу, и т.д.)
>>618447
Поэтому и не разобраться в вашем коде
Поэтому и не разобраться в вашем коде
>>657583
Выполнять утверждения. Ряд утверждений, решающих задачу, называется функцией.
Примитив объекта излишен для решения задач.
Выполнять утверждения. Ряд утверждений, решающих задачу, называется функцией.
Примитив объекта излишен для решения задач.
>>620228
Ага, а автомобиль - то же колесо.
Ага, а автомобиль - то же колесо.
>>660010
У борщехлёбов что ни возьми - функция. Типы - функция, значения - функция, пробелы - фугкция, небо - функция, аллах - функция.
У борщехлёбов что ни возьми - функция. Типы - функция, значения - функция, пробелы - фугкция, небо - функция, аллах - функция.
>>612292
недооценный пост.
Помню, студентом вообще не понимал нахуя они все это придумали. Реальный смысл раскрывается только в командной работе с кучей долбоебов.
Один то ты сможешь договориться сам с собой, а для других долбоебов нужны формальные правила игры.
недооценный пост.
Помню, студентом вообще не понимал нахуя они все это придумали. Реальный смысл раскрывается только в командной работе с кучей долбоебов.
Один то ты сможешь договориться сам с собой, а для других долбоебов нужны формальные правила игры.
>>607925 (OP)
Для удешевления труда программистишек, чтобы знали свое место и не задирали носы.
Позволяет писать сложные проекты горсткой дешевых, легко заменяемых индусов. Java, C#, это вот все.
>Для чего нужно ООП?
Для удешевления труда программистишек, чтобы знали свое место и не задирали носы.
>Какие проблемы и задачи оно решает?
Позволяет писать сложные проекты горсткой дешевых, легко заменяемых индусов. Java, C#, это вот все.
ооп - один из возможных подходов к композиции структур данных и алгоритмов, обрабатывающих эти данные
вассерман:
главный принцип программирования очевиден: сколь угодно сложную задачу можно разбить на кусочки, настолько простые, что с ними справится кто угодно. С тех пор ничего не изменилось. И этот принцип работает не только в программировании.
объектно-ориентированное программирование, когда программу собирают из структур, содержащих и данные, и методы их обработки.
Вспоминается официальное сообщение о языке Алгол-68: «всякое действие, описанное в настоящем сообщении, может быть заменено любым иным действием, дающим такой же внешний эффект». Эта фундаментальная концепция, на мой взгляд, ещё довольно долго останется одной из ключевых в программировании. Так же, как до того ключевой была идея структурного программирования, то есть той самой декомпозиции сложной задачи на элементарные компоненты, но только в применении, прежде всего, к методам обработки, а уж затем к структурам данных.
главный принцип программирования очевиден: сколь угодно сложную задачу можно разбить на кусочки, настолько простые, что с ними справится кто угодно. С тех пор ничего не изменилось. И этот принцип работает не только в программировании.
объектно-ориентированное программирование, когда программу собирают из структур, содержащих и данные, и методы их обработки.
Вспоминается официальное сообщение о языке Алгол-68: «всякое действие, описанное в настоящем сообщении, может быть заменено любым иным действием, дающим такой же внешний эффект». Эта фундаментальная концепция, на мой взгляд, ещё довольно долго останется одной из ключевых в программировании. Так же, как до того ключевой была идея структурного программирования, то есть той самой декомпозиции сложной задачи на элементарные компоненты, но только в применении, прежде всего, к методам обработки, а уж затем к структурам данных.
>>660109
Ты о чем бля?
Посмотри определение объекта, все на свете является объектами, поэтому процедурно и функционально ОП является ООП.
Ты о чем бля?
Посмотри определение объекта, все на свете является объектами, поэтому процедурно и функционально ОП является ООП.
>>660109
Алсо языки не делятся на интерпретируемые и нет, это вопрос реализации. На виртуалках у тебя даже машкод интерпретируется, а виртуальные драйвера были уже в 95 винде.
Алсо языки не делятся на интерпретируемые и нет, это вопрос реализации. На виртуалках у тебя даже машкод интерпретируется, а виртуальные драйвера были уже в 95 винде.
>>660233
Это полная хуйня. Так же можно сказать что всё на свете это процесс, или что всё на свете это энергия, или что всё на свете это Аллах.
Объект это слишком абстрактное понятие. Математические объекты и объекты из ООПе - и то и то как бы объекты, но объекты разного толка.
Это полная хуйня. Так же можно сказать что всё на свете это процесс, или что всё на свете это энергия, или что всё на свете это Аллах.
Объект это слишком абстрактное понятие. Математические объекты и объекты из ООПе - и то и то как бы объекты, но объекты разного толка.
>>607925 (OP)
Процитирую классика.
современое ООП:
толпы быдла долбятся головами об стену невидя двери - для них выпиливают люк.
/thread
Процитирую классика.
современое ООП:
толпы быдла долбятся головами об стену невидя двери - для них выпиливают люк.
/thread
>>660254
Да бля, процесс, энергия, Аллах - это объекты, просто потому что так быстрее и удобнее программировать, с опытом узнаешь.
Да бля, процесс, энергия, Аллах - это объекты, просто потому что так быстрее и удобнее программировать, с опытом узнаешь.
>>660398
Ололо, ООП-макака кого-то поучать ещё будет.
Ололо, ООП-макака кого-то поучать ещё будет.
>>660398
Вот у меня в эрланге процессы представлены функциями, и программировать многозадачные приложения на нём в разы удобнее и быстрее, чем на какой-нибудь джяве.
Вот у меня в эрланге процессы представлены функциями, и программировать многозадачные приложения на нём в разы удобнее и быстрее, чем на какой-нибудь джяве.
>>660398
Это как если бы глагол являлся существительным - мозг выносит
>Да бля, процесс, энергия - это объект
Это как если бы глагол являлся существительным - мозг выносит
>>613847
Interface Pussycat {
Kingdom: Animalia;
Phylum: Chordata;
BioClass: Mammalia;
Order: Carnivora;
Suborder: Feliformia;
Family: Felidae;
Subfamily: Felinae;
Genus: Felis;
Species: FelisCatus;
}
Наличие всех этих интерфейсов, естественно, подразумевается. У нас же тру-ООП.
Interface Pussycat {
Kingdom: Animalia;
Phylum: Chordata;
BioClass: Mammalia;
Order: Carnivora;
Suborder: Feliformia;
Family: Felidae;
Subfamily: Felinae;
Genus: Felis;
Species: FelisCatus;
}
Наличие всех этих интерфейсов, естественно, подразумевается. У нас же тру-ООП.
>>607925 (OP)
Двачую, ООП это полный дебилизм
Зачем делать
МояЖопа = новая Жопа(); НовоеГовно = новое Говно(); если(МояЖопа.Говно) МояЖопа.Срать(); иначе МояЖопа.ЗалитьГовна(НовоеГовно);
когда можно просто Срать(Говно)?
Двачую, ООП это полный дебилизм
Зачем делать
МояЖопа = новая Жопа(); НовоеГовно = новое Говно(); если(МояЖопа.Говно) МояЖопа.Срать(); иначе МояЖопа.ЗалитьГовна(НовоеГовно);
когда можно просто Срать(Говно)?
>>678472
Изобрести(процедурное_программирование, заново);
Изобрести(процедурное_программирование, заново);
>>678472
Полиморфизм. Как ты сделаешь dependency injection в процедурном языке? Структура с указателями на функции? По сути ты переизобретаешь ОПП, где все это решается программированием от интерфейсов.
Полиморфизм. Как ты сделаешь dependency injection в процедурном языке? Структура с указателями на функции? По сути ты переизобретаешь ОПП, где все это решается программированием от интерфейсов.
>>678472
Это 1С?
Это 1С?
>>678481
Для этого достаточно первоклассных модулей, реализующих одинаковый интерфейс. В принципе именно из модулы ООП логически произрастало, пока всякие пидары не сделали из него хуй пойми что.
Для этого достаточно первоклассных модулей, реализующих одинаковый интерфейс. В принципе именно из модулы ООП логически произрастало, пока всякие пидары не сделали из него хуй пойми что.
Инкапсуляция - даёт возможность использовать одинаковые названия для переменных и не бояться, что код наебнется. Служит инструментом для изоляции кода, который будет независим от внешнего кода и будет зависеть от кода в который инкапсулирован, т. е. обязан выполнять определенную политику, которая гарантирует работу кода о котором этот код не знает. Есть у тебя класс с методом, который принимает классы реализующие определенный интерфейс - тебе не нужно знать, что этот метод делает внутри, тебе достаточно реализовать этот интерфейс у своего класса.
Полиморфизм - создал один раз и это работает для многих классов и их наследников, чтобы расширить функционал, тебе не надо лезть в уже существующий код, ты просто наследуешь класс или интерфейс.
Наследование - весь одинаковый функционал, всё общее помещаешь в абстрактные классы, интерфейсы и классы, а конкретное в классы которые их наследуют и реализуют. Всё получается коомпактно и без дублирования.
Полиморфизм - создал один раз и это работает для многих классов и их наследников, чтобы расширить функционал, тебе не надо лезть в уже существующий код, ты просто наследуешь класс или интерфейс.
Наследование - весь одинаковый функционал, всё общее помещаешь в абстрактные классы, интерфейсы и классы, а конкретное в классы которые их наследуют и реализуют. Всё получается коомпактно и без дублирования.
>>678490
Это ООП и есть, лол. Только данные и код можно хранить вместе, и не надо каждый раз передавать структуры в функции, как в процедурном программировании.
Если ты про наследование, то оно нахуй не нужно. А если про SOLID, то это лишь способ организации кода, к понятию ООП это ничего принципиально нового не добавляет.
мимо
> Для этого достаточно первоклассных модулей, реализующих одинаковый интерфейс.
Это ООП и есть, лол. Только данные и код можно хранить вместе, и не надо каждый раз передавать структуры в функции, как в процедурном программировании.
> пока всякие пидары не сделали из него хуй пойми что
Если ты про наследование, то оно нахуй не нужно. А если про SOLID, то это лишь способ организации кода, к понятию ООП это ничего принципиально нового не добавляет.
мимо
>>678492
Этого можно добиться неймспейсами, модулями и замыканиями.
Как-будто это какая-то эксклюзивная фича ООП. Протоколы/бихейверы/тайпклассы/интерфейсы модулей, и т.д. дают то же самое.
Ага, уже представляю этот горизонтальный шум, если каждая хуитка вынесена в отдельный класс, и потом весь этот ворох говна наследуется где-то в классе на три строчки, который непонятно что делает, пока не просмотришь каждый родительский класс и глаза не вытекут нахуй. За все эти развесистые деревья наследования уже начиная со второй половины нулевых стали заслуженно давать по ебалу; современное ООП это вообще не про наследование, наоборот стараются всё делать максимально плоским, насколько возможно, потому что помнят как с наследованием говна поели в 90х-00х. Абстракция через наследование - самая хрупкая абстракция евер, все эти заманчивые книжные примеры для нубов Cow extends Anymal в реальной жизни превращаются в абсолютно убёщное неподдерживаемое говно, такое что потом никакой SOLID, с препроцессором на аннотациях не спасает.
>Инкапсуляция - даёт возможность использовать одинаковые названия для переменных и не бояться, что код наебнется. Служит инструментом для изоляции кода, который будет независим от внешнего кода и будет зависеть от кода в который инкапсулирован, т. е. обязан выполнять определенную политику, которая гарантирует работу кода о котором этот код не знает.
Этого можно добиться неймспейсами, модулями и замыканиями.
> Есть у тебя класс с методом, который принимает классы реализующие определенный интерфейс - тебе не нужно знать, что этот метод делает внутри, тебе достаточно реализовать этот интерфейс у своего класса.
Как-будто это какая-то эксклюзивная фича ООП. Протоколы/бихейверы/тайпклассы/интерфейсы модулей, и т.д. дают то же самое.
> чтобы расширить функционал ты просто наследуешь класс
Ага, уже представляю этот горизонтальный шум, если каждая хуитка вынесена в отдельный класс, и потом весь этот ворох говна наследуется где-то в классе на три строчки, который непонятно что делает, пока не просмотришь каждый родительский класс и глаза не вытекут нахуй. За все эти развесистые деревья наследования уже начиная со второй половины нулевых стали заслуженно давать по ебалу; современное ООП это вообще не про наследование, наоборот стараются всё делать максимально плоским, насколько возможно, потому что помнят как с наследованием говна поели в 90х-00х. Абстракция через наследование - самая хрупкая абстракция евер, все эти заманчивые книжные примеры для нубов Cow extends Anymal в реальной жизни превращаются в абсолютно убёщное неподдерживаемое говно, такое что потом никакой SOLID, с препроцессором на аннотациях не спасает.
>>678524
Этого недостаточно, всё тобой перечисленное всего лишь крупнозернистый ООП и не более. Классы, интерфейсы дополняют этот ООП, превращая его в мелкозернистый и обогащая функционал, возможности, облегчая работу для программистов.
Что-то ты совсем тупенький. ООП как раз и создан для реализации протоколов и поведений. Как ты их без ООП реализовать собрался? Типа "давайте просто на бумажечке запишем, что вот так вот делать будем, а потом каждый будет смотреть на бумажечку, перед тем как код писать"? Вот ООП как раз и избавляет тебя от написания бумажечек, ООП автоматизирует ту часть, которую раньше необходимо было поддерживать вручную. ООП следит за тем чтобы протоколы не нарушались а поведение не становилось непредсказуемым.
Ну давайте теперь бензопилами не пользоваться, потому что какой-то васян уронил её на себя и отхуячил половину руки. Чего ты сказать то хотел? Да, нужно учить принципы SOLID, понимать их, для того чтобы строить адекватные ООП архитектуры без раздувания кода. Но это вопрос квалификации пользователя инструмента, который никак не влияет на пользу от использования этого инструмента квалифицированными людьми.
>Этого можно добиться неймспейсами, модулями и замыканиями.
Этого недостаточно, всё тобой перечисленное всего лишь крупнозернистый ООП и не более. Классы, интерфейсы дополняют этот ООП, превращая его в мелкозернистый и обогащая функционал, возможности, облегчая работу для программистов.
>Протоколы/бихейверы/тайпклассы/интерфейсы модулей, и т.д. дают то же самое.
Что-то ты совсем тупенький. ООП как раз и создан для реализации протоколов и поведений. Как ты их без ООП реализовать собрался? Типа "давайте просто на бумажечке запишем, что вот так вот делать будем, а потом каждый будет смотреть на бумажечку, перед тем как код писать"? Вот ООП как раз и избавляет тебя от написания бумажечек, ООП автоматизирует ту часть, которую раньше необходимо было поддерживать вручную. ООП следит за тем чтобы протоколы не нарушались а поведение не становилось непредсказуемым.
>Ага, уже представляю этот горизонтальный шум, если каждая хуитка вынесена в отдельный класс
Ну давайте теперь бензопилами не пользоваться, потому что какой-то васян уронил её на себя и отхуячил половину руки. Чего ты сказать то хотел? Да, нужно учить принципы SOLID, понимать их, для того чтобы строить адекватные ООП архитектуры без раздувания кода. Но это вопрос квалификации пользователя инструмента, который никак не влияет на пользу от использования этого инструмента квалифицированными людьми.
>>678926
Чего не достаточно, сектант? Ты вообще читаешь на что ты отвечаешь? Ты пишешь что тебе нужен скоупинг, всё выше перечисленное даёт скоупинг и большинстве случаев инкапсуляцию.
Пиздос. Ну не знаю, откуда тогда в Erlang/Elixir/Clojure есть бихейверы и протоколы, может сейчас окажется что это ООП всё языки. Я уже молчу про ML-семейство с их системой модулей или хаскельские тайпклассы, которые позволяют добиться этого же и даже больше.
Дальше читать твой пост не вижу смысла. Судя по всему ты какой-то нуб, который нихуя в своей жизни кроме процедурщины и ООП не видел, но берёшься размышлять о полиморфизме и инкапсуляции. Убогий полиморфизм на сабтайпинге и инкапсуляция уровня public/protected/private это лишь один из многих вариантов, причём не самый удачный, получивший широкое распространение по исторической случайности.
>Этого недостаточно
Чего не достаточно, сектант? Ты вообще читаешь на что ты отвечаешь? Ты пишешь что тебе нужен скоупинг, всё выше перечисленное даёт скоупинг и большинстве случаев инкапсуляцию.
>Что-то ты совсем тупенький. ООП как раз и создан для реализации протоколов и поведений. Как ты их без ООП реализовать собрался?
Пиздос. Ну не знаю, откуда тогда в Erlang/Elixir/Clojure есть бихейверы и протоколы, может сейчас окажется что это ООП всё языки. Я уже молчу про ML-семейство с их системой модулей или хаскельские тайпклассы, которые позволяют добиться этого же и даже больше.
Дальше читать твой пост не вижу смысла. Судя по всему ты какой-то нуб, который нихуя в своей жизни кроме процедурщины и ООП не видел, но берёшься размышлять о полиморфизме и инкапсуляции. Убогий полиморфизм на сабтайпинге и инкапсуляция уровня public/protected/private это лишь один из многих вариантов, причём не самый удачный, получивший широкое распространение по исторической случайности.
>>678490
Видел такое в окамле. Чем-то напомнило шаблоны из крестов, ведь это тоже самое compile time polymorphism. Классная штука сама по себе, но не очень гибкая, но это может я просто не видел других реализаций? Проблема возникла когда я пытался одновременно замокать Lwt и Lwt_io и делал это с помощью модулей. Мой модуль использовал два модуля которые использовали друг друга, и мне пришлось городить вложенные модули как здесь https://sketch.sh/s/jj2oZ5xAsjBRms5Z2DMTt4/ . Если представить, что таких модулей у меня пять и более, то там вложенность будет просто ебучая. Я не фанат ООП, но тут признаю, что интерфейсы удобнее и гибче.
Видел такое в окамле. Чем-то напомнило шаблоны из крестов, ведь это тоже самое compile time polymorphism. Классная штука сама по себе, но не очень гибкая, но это может я просто не видел других реализаций? Проблема возникла когда я пытался одновременно замокать Lwt и Lwt_io и делал это с помощью модулей. Мой модуль использовал два модуля которые использовали друг друга, и мне пришлось городить вложенные модули как здесь https://sketch.sh/s/jj2oZ5xAsjBRms5Z2DMTt4/ . Если представить, что таких модулей у меня пять и более, то там вложенность будет просто ебучая. Я не фанат ООП, но тут признаю, что интерфейсы удобнее и гибче.
>>679016
Что то из живых языков будет или ограничишься мёртвыми языками на которых кроме "любительская хуета от сектанта #21" ничего нет?
> Erlang/Elixir/Clojure
Что то из живых языков будет или ограничишься мёртвыми языками на которых кроме "любительская хуета от сектанта #21" ничего нет?
>>679162
Ну хуй знает, я на эликсире уже лет 5 пишу, вакансии регулярно прилетают, как то не заметил его смерти.
Но вообще забавно как ты, обосравшись, решил сменить тему. Мань, речь шла о том, что есть масса не ОО-языков, в которых есть всё о чём ты пишешь. Причём я привёл пару продакшн-ЯП, которые используются на практике, а не какую-то обскурную экзотику.
Просто, как и я сказал выше, ты зашореная чмоха, которая нихуя кроме ОО-параши в жизни не видела. Само по себе это не порок конечно, люди идут программировать на жабе/похапе не от хорошей жизни, да и на языки и с программированием им насрать по большому счёту, но вот с умным видом что-то пояснять про полиморфизм/икапсуляцию с таким ограниченным кругозором это пиздец позорище.
Ну хуй знает, я на эликсире уже лет 5 пишу, вакансии регулярно прилетают, как то не заметил его смерти.
Но вообще забавно как ты, обосравшись, решил сменить тему. Мань, речь шла о том, что есть масса не ОО-языков, в которых есть всё о чём ты пишешь. Причём я привёл пару продакшн-ЯП, которые используются на практике, а не какую-то обскурную экзотику.
Просто, как и я сказал выше, ты зашореная чмоха, которая нихуя кроме ОО-параши в жизни не видела. Само по себе это не порок конечно, люди идут программировать на жабе/похапе не от хорошей жизни, да и на языки и с программированием им насрать по большому счёту, но вот с умным видом что-то пояснять про полиморфизм/икапсуляцию с таким ограниченным кругозором это пиздец позорище.
>>679454
Ты забываешь уточнять, что это только твоё мнение, которое ничем кроме твоего манямирка не подкреплено.
На С без всякого ООП целые операционные системы писали, представь себе. Вот только каким хуем это наделяет С всем тем, что есть у ООП и каким хуем оно отменяет те возможности, которые ООП предоставляет, одному тебе, долбоебу, известно.
У тебя на всё один аргумент - ЭТО ЕСТЬ И В ФУНКЦИОНАЛЬНОМ ПАГРАМИРАВАНИИ!!! Хотя сама суть разделения на ООП и ФП это отрицает. Т. е. ты с голой жопой идёшь против всего мира, а потом еще и возмущаешься, когда тебя никто всерьез не воспринимает.
>что есть масса не ОО-языков, в которых есть всё о чём ты пишешь.
Ты забываешь уточнять, что это только твоё мнение, которое ничем кроме твоего манямирка не подкреплено.
>Причём я привёл пару продакшн-ЯП, которые используются на практике
На С без всякого ООП целые операционные системы писали, представь себе. Вот только каким хуем это наделяет С всем тем, что есть у ООП и каким хуем оно отменяет те возможности, которые ООП предоставляет, одному тебе, долбоебу, известно.
У тебя на всё один аргумент - ЭТО ЕСТЬ И В ФУНКЦИОНАЛЬНОМ ПАГРАМИРАВАНИИ!!! Хотя сама суть разделения на ООП и ФП это отрицает. Т. е. ты с голой жопой идёшь против всего мира, а потом еще и возмущаешься, когда тебя никто всерьез не воспринимает.
>>678472
С памятью меньше возни, все деструкторы (освободители памяти) не разбросаны по куче функций. Не нужны никакие флаги а-ля когда память размечена, когда не размечена (у меня такие есть где-то).
С памятью меньше возни, все деструкторы (освободители памяти) не разбросаны по куче функций. Не нужны никакие флаги а-ля когда память размечена, когда не размечена (у меня такие есть где-то).
>>679460
Что вы несёте, сударь?
Функциональщина (фундаментальная операция - редукция выражения), противопоставляется императивщине (фундаментальная операция - присвоение, т.е. запись блядских нулей и единиц в блядскую ячейку памяти).
ООП это частный случай императивщины, это даже не парадигма, и никаким боком не противопоставление ФП, именно поэтому "ЭТО ЕСТЬ И В ФУНКЦИОНАЛЬНОМ ПАГРАМИРАВАНИИ!!!" - чистейшая правда. Да, оно (классы и объекты) там действительно есть. Чего там нет - так это присвоения.
Что вы несёте, сударь?
Функциональщина (фундаментальная операция - редукция выражения), противопоставляется императивщине (фундаментальная операция - присвоение, т.е. запись блядских нулей и единиц в блядскую ячейку памяти).
ООП это частный случай императивщины, это даже не парадигма, и никаким боком не противопоставление ФП, именно поэтому "ЭТО ЕСТЬ И В ФУНКЦИОНАЛЬНОМ ПАГРАМИРАВАНИИ!!!" - чистейшая правда. Да, оно (классы и объекты) там действительно есть. Чего там нет - так это присвоения.
>>681651
Нет, это декларативщина противопоставляется императивщине, И она бывает не только функциональной, но и логической, например, Prolog. inb4: Prolog - это функциональщина, и ООП функциональщина, и ассемблер функциональщина, и небо и аллах функциональщина
> Функциональщина (фундаментальная операция - редукция выражения), противопоставляется императивщине
Нет, это декларативщина противопоставляется императивщине, И она бывает не только функциональной, но и логической, например, Prolog. inb4: Prolog - это функциональщина, и ООП функциональщина, и ассемблер функциональщина, и небо и аллах функциональщина
>>682173
Нет.
Противопоставления всего два. Первое - "вычислить vs исполнить". Это функциональщина со своими вычислениями против императивщины со своими записями в память (ты будто вообще не читал мой пост). Можно редуцировать это понятие вплоть до лямбда-исчисление против машины Тьюринга.
Второе - "механизм vs декларация", где механизм - "вот конкретная последовательность действий чтобы превратить выражение в результат", а "декларация" - это когда ты описываешь задачу в терминах конечного результата ("я даю тебе значения, ты мне дай предикат который им удовлетворяет"), а программа даёт результат не с помощью чёткого алгоритма, а с помощью перебора.
Ты смешал понятия "ебаться с памятью" и "алгоритм". Алгоритм может быть и без ебли с памятью, как ебля с памятью может быть алгоритма.
Таким образом, "вычисление + декларативность" это логическое программирование, "вычисление + механизм" это как раз-таки функциональщина, а "выполнение + механизм" это императивщина.
А "выполнение + декларативность" - такого не существует. Это по сути своей кнопка "сделать пиздато", которая без ИИ невозможна.
Ещё раз, если непонятно изложил:
"Вычислить" - значит редуцировать некое выражение до примитива, т.е. фундаментальная операция в такой системе - редукция.
"Выполнить" - значит записать некое значение на ленту, т.е. фундаментальная операция - присвоение (на самом деле не только присвоение, а обращение, т.к. мы в ячейки можем как писать, так и читать)
Ебсти память и действовать по алгоритму это разные вещи.
Поэтому пролог это не "логическая декларативщина", а "логическое программирование" это "вычислительная декларативщина", в противовес ФП которое суть "вычислительная алгоритмщина", а со стороны на их противоречие смотрит ассемблер, который суть "исполнительная алгоритмщина"
Нет.
Противопоставления всего два. Первое - "вычислить vs исполнить". Это функциональщина со своими вычислениями против императивщины со своими записями в память (ты будто вообще не читал мой пост). Можно редуцировать это понятие вплоть до лямбда-исчисление против машины Тьюринга.
Второе - "механизм vs декларация", где механизм - "вот конкретная последовательность действий чтобы превратить выражение в результат", а "декларация" - это когда ты описываешь задачу в терминах конечного результата ("я даю тебе значения, ты мне дай предикат который им удовлетворяет"), а программа даёт результат не с помощью чёткого алгоритма, а с помощью перебора.
Ты смешал понятия "ебаться с памятью" и "алгоритм". Алгоритм может быть и без ебли с памятью, как ебля с памятью может быть алгоритма.
Таким образом, "вычисление + декларативность" это логическое программирование, "вычисление + механизм" это как раз-таки функциональщина, а "выполнение + механизм" это императивщина.
А "выполнение + декларативность" - такого не существует. Это по сути своей кнопка "сделать пиздато", которая без ИИ невозможна.
Ещё раз, если непонятно изложил:
"Вычислить" - значит редуцировать некое выражение до примитива, т.е. фундаментальная операция в такой системе - редукция.
"Выполнить" - значит записать некое значение на ленту, т.е. фундаментальная операция - присвоение (на самом деле не только присвоение, а обращение, т.к. мы в ячейки можем как писать, так и читать)
Ебсти память и действовать по алгоритму это разные вещи.
Поэтому пролог это не "логическая декларативщина", а "логическое программирование" это "вычислительная декларативщина", в противовес ФП которое суть "вычислительная алгоритмщина", а со стороны на их противоречие смотрит ассемблер, который суть "исполнительная алгоритмщина"
>>682166
Нет признаков парадигмы. Признак парадигмы это наличие критерия по которому существовало бы что-то противоположное данной парадигме. Что является противоположностью ООП? То же самое, что является противоположностью языку си: декларативное и вычислительное, в противовес алгоритмической и исполнительной, скажем, джаве.
Просто в понятие "императивность" слито два разных понятия - операция с памятью и действие по алгоритму, которые не обязаны идти рука об руку.
Нет признаков парадигмы. Признак парадигмы это наличие критерия по которому существовало бы что-то противоположное данной парадигме. Что является противоположностью ООП? То же самое, что является противоположностью языку си: декларативное и вычислительное, в противовес алгоритмической и исполнительной, скажем, джаве.
Просто в понятие "императивность" слито два разных понятия - операция с памятью и действие по алгоритму, которые не обязаны идти рука об руку.
>>682675
О, крутяк, можете мне пояснить один вопрос: как в принципе можно вообще обходится без присвоения?
Для решения задач вычисления - оно понятно, хотя меня всегда немного смущало, что желательно реализовывать итерации через хвостовую рекурсию, которая исполняется подобно циклу, которых в функциональном подходе нет. Как-то это странно, сначала исключать цикл, а потом пытаться его повторить другим способом, ну да ладно, сейчас не об этом.
А вот если мне нужно не вычислить значение, а скажем получить сообщение по сети? Или построить хэш таблицу? Что в таком случае делается? Или ограничение на присвоение не строгое?
О, крутяк, можете мне пояснить один вопрос: как в принципе можно вообще обходится без присвоения?
Для решения задач вычисления - оно понятно, хотя меня всегда немного смущало, что желательно реализовывать итерации через хвостовую рекурсию, которая исполняется подобно циклу, которых в функциональном подходе нет. Как-то это странно, сначала исключать цикл, а потом пытаться его повторить другим способом, ну да ладно, сейчас не об этом.
А вот если мне нужно не вычислить значение, а скажем получить сообщение по сети? Или построить хэш таблицу? Что в таком случае делается? Или ограничение на присвоение не строгое?
>>682855
Я тут не помогу, к сожалению.
У меня есть понимание того, чем по сути своей является функциональщина, но я не знаком с языками дрочащими на ФП (именно дрочащими, а не содержащими, хаскель к примеру), и как следствие не знаком с "лучшими практиками" в них.
Как делаю лично я? Пишу функционально всё что могу, а что не могу пишу императивно. Клиент-сервер это как раз классический случай когда без стейта не обойтись. А в общем случае без стейта нельзя обойтись тогда и только тогда, когда у тебя величины могут меняться во времени, например функция, возвращающая рандомное число или сервер, который сидит на потоке и СЛУШАЕТ его, т.е. должен вести себя по разному в зависимости от того, какое сейчас время.
Я тут не помогу, к сожалению.
У меня есть понимание того, чем по сути своей является функциональщина, но я не знаком с языками дрочащими на ФП (именно дрочащими, а не содержащими, хаскель к примеру), и как следствие не знаком с "лучшими практиками" в них.
Как делаю лично я? Пишу функционально всё что могу, а что не могу пишу императивно. Клиент-сервер это как раз классический случай когда без стейта не обойтись. А в общем случае без стейта нельзя обойтись тогда и только тогда, когда у тебя величины могут меняться во времени, например функция, возвращающая рандомное число или сервер, который сидит на потоке и СЛУШАЕТ его, т.е. должен вести себя по разному в зависимости от того, какое сейчас время.
Алсо рекомендую к прочтению третью главу SICP — там неплохо разъяснено про эти тонкости.
>>683271
Спасибо! Почитаю
Спасибо! Почитаю
>>682166
Напомни-ка мне, из чего состоит объект? Наверное из СОСТОЯНИЯ и методов, да? А что такое СОСТОЯНИЕ, не подскажешь? Наверное такая штука, которая может во времени изменяться, да? Ну прям как переменная, да? Объекты без состояния антипаттерном в ООП являются? Так точно.
Какой из этого вывод? ООП = императивщина. Всё, где есть сайд-эффекты, является императивщиной.
Даже если ты смоллтокоёб с иммутабельными объектами, энивей у тебя что-то помещается в память (пусть даже не ты сам руками помещаешь, а обращаешься через ссылку, но суть та же), это что-то можно оттуда прочесть, а потом сборщик мусора сотрёт.
>>ООП
>>это даже не парадигма
>Ясно
Напомни-ка мне, из чего состоит объект? Наверное из СОСТОЯНИЯ и методов, да? А что такое СОСТОЯНИЕ, не подскажешь? Наверное такая штука, которая может во времени изменяться, да? Ну прям как переменная, да? Объекты без состояния антипаттерном в ООП являются? Так точно.
Какой из этого вывод? ООП = императивщина. Всё, где есть сайд-эффекты, является императивщиной.
Даже если ты смоллтокоёб с иммутабельными объектами, энивей у тебя что-то помещается в память (пусть даже не ты сам руками помещаешь, а обращаешься через ссылку, но суть та же), это что-то можно оттуда прочесть, а потом сборщик мусора сотрёт.
>>690752
И только в волшебном хачкиле это не так. У него, видать, под капотом всё само делается магией, а не железом.
> энивей у тебя что-то помещается в память
И только в волшебном хачкиле это не так. У него, видать, под капотом всё само делается магией, а не железом.
>>690864
Причём тут вообще хачкель?
Причём тут вообще хачкель?
Или это был очередной дебильный намёк, что дескать "ну ахахах смарите раз на уровне ассемблера императивщина значит всё императивщина", нет дорогой мой, парадигма это понятие языковое, если в языке это есть значит это есть, а чё там в компиляторе происходит — его собачье дело. Да в общем-то в тех же лисп-машинах никакого ассемблера нет, шах и мат на самом деле шах и мат был в прошлом предложении поставлен.
>>679460
На самом деле - со всяким ооп.
https://www.kernel.org/doc/html/v4.13/driver-api/index.html
>На С без всякого ООП целые операционные системы писали, представь себе.
На самом деле - со всяким ооп.
https://www.kernel.org/doc/html/v4.13/driver-api/index.html
>>695966
ебать ты хакир, небось сидишь ещё в реверс треде
ебать ты хакир, небось сидишь ещё в реверс треде
В js есть только объекты. Больше ничего.
Есть еще примитивы, но их можно тоже рассматривать в качестве синглтон объектов, потому как они боксятся, а сделаны разумеется для производительности. (тем более что сейчас ничего не мешает у примитивных добавить в цепочку прототипов прокси объект, отлавливащий сообщения, типа присваивания, и реалиховать поведение прототипов как полноценных объектов, но это ни к чему. проще воспринимать их как синглтоны. когда надо, любой примитив можно обернуть в полноценный независимый объект).
Так. Короче только объекты.
Все объекты делятся на callable и non-callable. Callable это функции, в понимании большинства. Но по факту это все те же объекты, со всеми свойствами что и у других.
Все объекты могут принимать всего несколько типов сообщений - get, set и call. При чем call может принимать только callable объект. при попытке послать call сообщение не-callable объекту будет исключение.
Сообщение get содержит один параметр, сообщение set два. Сообщение call параметром содержит кортеж аргументов, а так контекст this.
Если в объекте (а так же в цепочке прототипов) не назначены слушатели для get и set с определенными параметрами, ищутся слоты с такими именами в объекте и по цепочке. Если находится возвращается то, что в них лежит. Если в них лежит callable объект и ему посылают сообщние call сразу как получили его из слота, то у него будет перегружен контекст (this) на объект из чьего слота его получили. Если только этот объект не был сконструирован стрелочным синтаксисом, иначе контекст перегрузить нельзя. Если после получение callable объекта из слота его сразу не вызвать, а например положить ссылку на него в переменную, то контекст будет сброшен на тот, который был установлен у него в момент его создания (и это не обязательно будет тот же объект из чьего слота его получили).
У callable объектов есть scope (область видимости) и контекст (this) в момент посылки им сообщения call (вызова). scope средствами языка перегрузить нельзя, но некоторые окружения позволяют (например в ноде есть модеуль vm), this перегружается у callable объектов сконструированных не-стрелочным синтаксисом
Классов нет. Есть конструкторы. Любой конструктор принимает новый созданный объект, которому выставлен определенный прототип (другой объект). Оператор instanceof (someObject instanceof SomeClassName) проверяет лишь есть ли в цепочке прототипов у someObject объект который лежит у SomeClassConstructor в слоте с именем prototype. На сам конструктор ему поебать. Чтобы сменить класс, достаточно сменить цепочку прототипов. Даже если объект был сконструированным определенным конструктором.
Так же у объектов есть параметр ограничения доступа, контролирующие его расширяемость или изменяемость (sealed, extensible, frozen). У слотов объекта есть параметры configurable, enumerable, writable. Параметры слотов объекта не влияют на объекты, что в них лежат. Они лишь контролируют доступ к самим слотам.
Все. Никаких классов. Никаких интерфейсов. Как отдельных сущностей. По факту все есть объект и все строит из них.
наследование реализуется выстраиванием цепочки прототипов. Инкапсуляция только на уровне scope'в (читай замыканий).
В остальном все меняется и все динамично, если только специально все не зафризить в момент конструирования. Но обычно этим никто не заморачивается по причине оверхеда и бессмысленности. Разве только фанатики по иммутабельности, н это все из разряда те, кому надо чтобы им по рукам бил компилятор\рантайм\дядя петя. Все "привычные" понятия тянуться в язык для еще более простого вкатывания тех, кто приходит из других языков. Так уж сложилось, что есть куча литературы по привычному, статически классовому ООП, но очень мало по мессадж-пассинг\прототайп-базед\мета-программинг. Все эти притянутые понятия выливают в синтаксический сахар, который не делает ничего полезного, а даже наоборот, еще больше вносит путаницы и от того непонимамания многих вещей в языке. При этом часто этот синтаксический сахар дэже урезан и вспомнинают об этом лишь после (как например проебались с полями в конструкции class и тянут ее теперь только в proposol'ах будущих версий).
JS истинно объектный язык. В современный язык притащили много вкусных вещей для метапрограммирования. Нову примитивную сущность Symbol, и Proxy-объекты. С помощью которых можно еще больше и сильнее перегружать и менять поведение в динамике.
Другое дело, что почти никто не умеет этим пользоваться и не понимает, что такое объектное программирование на самом деле.
Им нужно не объектное, а статически типизированное. А какие именно структуры будут скрываться за этими типами, не собо важно. Важно что это просто структуры и функции, строго привязанные к ним, или иногда менее строго. То, что в Java\C++ это больше структурное программирование, нежели объектное. Объектное программирование не может существовать без динамической среды. Это противоречит самому понятию объекта. А динамическое программирование это слишком сложна и непанятна. И как бы не старались с пеной у рта фанатики кричать про низкий порог входа - низкий он именно что для входа, а не для всего остального. Модификация программ в рантайме всегда было уделом креативно мыслящих людей. Для большинства это слишком сложный уровень высокой абстракции.
Есть еще примитивы, но их можно тоже рассматривать в качестве синглтон объектов, потому как они боксятся, а сделаны разумеется для производительности. (тем более что сейчас ничего не мешает у примитивных добавить в цепочку прототипов прокси объект, отлавливащий сообщения, типа присваивания, и реалиховать поведение прототипов как полноценных объектов, но это ни к чему. проще воспринимать их как синглтоны. когда надо, любой примитив можно обернуть в полноценный независимый объект).
Так. Короче только объекты.
Все объекты делятся на callable и non-callable. Callable это функции, в понимании большинства. Но по факту это все те же объекты, со всеми свойствами что и у других.
Все объекты могут принимать всего несколько типов сообщений - get, set и call. При чем call может принимать только callable объект. при попытке послать call сообщение не-callable объекту будет исключение.
Сообщение get содержит один параметр, сообщение set два. Сообщение call параметром содержит кортеж аргументов, а так контекст this.
Если в объекте (а так же в цепочке прототипов) не назначены слушатели для get и set с определенными параметрами, ищутся слоты с такими именами в объекте и по цепочке. Если находится возвращается то, что в них лежит. Если в них лежит callable объект и ему посылают сообщние call сразу как получили его из слота, то у него будет перегружен контекст (this) на объект из чьего слота его получили. Если только этот объект не был сконструирован стрелочным синтаксисом, иначе контекст перегрузить нельзя. Если после получение callable объекта из слота его сразу не вызвать, а например положить ссылку на него в переменную, то контекст будет сброшен на тот, который был установлен у него в момент его создания (и это не обязательно будет тот же объект из чьего слота его получили).
У callable объектов есть scope (область видимости) и контекст (this) в момент посылки им сообщения call (вызова). scope средствами языка перегрузить нельзя, но некоторые окружения позволяют (например в ноде есть модеуль vm), this перегружается у callable объектов сконструированных не-стрелочным синтаксисом
Классов нет. Есть конструкторы. Любой конструктор принимает новый созданный объект, которому выставлен определенный прототип (другой объект). Оператор instanceof (someObject instanceof SomeClassName) проверяет лишь есть ли в цепочке прототипов у someObject объект который лежит у SomeClassConstructor в слоте с именем prototype. На сам конструктор ему поебать. Чтобы сменить класс, достаточно сменить цепочку прототипов. Даже если объект был сконструированным определенным конструктором.
Так же у объектов есть параметр ограничения доступа, контролирующие его расширяемость или изменяемость (sealed, extensible, frozen). У слотов объекта есть параметры configurable, enumerable, writable. Параметры слотов объекта не влияют на объекты, что в них лежат. Они лишь контролируют доступ к самим слотам.
Все. Никаких классов. Никаких интерфейсов. Как отдельных сущностей. По факту все есть объект и все строит из них.
наследование реализуется выстраиванием цепочки прототипов. Инкапсуляция только на уровне scope'в (читай замыканий).
В остальном все меняется и все динамично, если только специально все не зафризить в момент конструирования. Но обычно этим никто не заморачивается по причине оверхеда и бессмысленности. Разве только фанатики по иммутабельности, н это все из разряда те, кому надо чтобы им по рукам бил компилятор\рантайм\дядя петя. Все "привычные" понятия тянуться в язык для еще более простого вкатывания тех, кто приходит из других языков. Так уж сложилось, что есть куча литературы по привычному, статически классовому ООП, но очень мало по мессадж-пассинг\прототайп-базед\мета-программинг. Все эти притянутые понятия выливают в синтаксический сахар, который не делает ничего полезного, а даже наоборот, еще больше вносит путаницы и от того непонимамания многих вещей в языке. При этом часто этот синтаксический сахар дэже урезан и вспомнинают об этом лишь после (как например проебались с полями в конструкции class и тянут ее теперь только в proposol'ах будущих версий).
JS истинно объектный язык. В современный язык притащили много вкусных вещей для метапрограммирования. Нову примитивную сущность Symbol, и Proxy-объекты. С помощью которых можно еще больше и сильнее перегружать и менять поведение в динамике.
Другое дело, что почти никто не умеет этим пользоваться и не понимает, что такое объектное программирование на самом деле.
Им нужно не объектное, а статически типизированное. А какие именно структуры будут скрываться за этими типами, не собо важно. Важно что это просто структуры и функции, строго привязанные к ним, или иногда менее строго. То, что в Java\C++ это больше структурное программирование, нежели объектное. Объектное программирование не может существовать без динамической среды. Это противоречит самому понятию объекта. А динамическое программирование это слишком сложна и непанятна. И как бы не старались с пеной у рта фанатики кричать про низкий порог входа - низкий он именно что для входа, а не для всего остального. Модификация программ в рантайме всегда было уделом креативно мыслящих людей. Для большинства это слишком сложный уровень высокой абстракции.
В js есть только объекты. Больше ничего.
Есть еще примитивы, но их можно тоже рассматривать в качестве синглтон объектов, потому как они боксятся, а сделаны разумеется для производительности. (тем более что сейчас ничего не мешает у примитивных добавить в цепочку прототипов прокси объект, отлавливащий сообщения, типа присваивания, и реалиховать поведение прототипов как полноценных объектов, но это ни к чему. проще воспринимать их как синглтоны. когда надо, любой примитив можно обернуть в полноценный независимый объект).
Так. Короче только объекты.
Все объекты делятся на callable и non-callable. Callable это функции, в понимании большинства. Но по факту это все те же объекты, со всеми свойствами что и у других.
Все объекты могут принимать всего несколько типов сообщений - get, set и call. При чем call может принимать только callable объект. при попытке послать call сообщение не-callable объекту будет исключение.
Сообщение get содержит один параметр, сообщение set два. Сообщение call параметром содержит кортеж аргументов, а так контекст this.
Если в объекте (а так же в цепочке прототипов) не назначены слушатели для get и set с определенными параметрами, ищутся слоты с такими именами в объекте и по цепочке. Если находится возвращается то, что в них лежит. Если в них лежит callable объект и ему посылают сообщние call сразу как получили его из слота, то у него будет перегружен контекст (this) на объект из чьего слота его получили. Если только этот объект не был сконструирован стрелочным синтаксисом, иначе контекст перегрузить нельзя. Если после получение callable объекта из слота его сразу не вызвать, а например положить ссылку на него в переменную, то контекст будет сброшен на тот, который был установлен у него в момент его создания (и это не обязательно будет тот же объект из чьего слота его получили).
У callable объектов есть scope (область видимости) и контекст (this) в момент посылки им сообщения call (вызова). scope средствами языка перегрузить нельзя, но некоторые окружения позволяют (например в ноде есть модеуль vm), this перегружается у callable объектов сконструированных не-стрелочным синтаксисом
Классов нет. Есть конструкторы. Любой конструктор принимает новый созданный объект, которому выставлен определенный прототип (другой объект). Оператор instanceof (someObject instanceof SomeClassName) проверяет лишь есть ли в цепочке прототипов у someObject объект который лежит у SomeClassConstructor в слоте с именем prototype. На сам конструктор ему поебать. Чтобы сменить класс, достаточно сменить цепочку прототипов. Даже если объект был сконструированным определенным конструктором.
Так же у объектов есть параметр ограничения доступа, контролирующие его расширяемость или изменяемость (sealed, extensible, frozen). У слотов объекта есть параметры configurable, enumerable, writable. Параметры слотов объекта не влияют на объекты, что в них лежат. Они лишь контролируют доступ к самим слотам.
Все. Никаких классов. Никаких интерфейсов. Как отдельных сущностей. По факту все есть объект и все строит из них.
наследование реализуется выстраиванием цепочки прототипов. Инкапсуляция только на уровне scope'в (читай замыканий).
В остальном все меняется и все динамично, если только специально все не зафризить в момент конструирования. Но обычно этим никто не заморачивается по причине оверхеда и бессмысленности. Разве только фанатики по иммутабельности, н это все из разряда те, кому надо чтобы им по рукам бил компилятор\рантайм\дядя петя. Все "привычные" понятия тянуться в язык для еще более простого вкатывания тех, кто приходит из других языков. Так уж сложилось, что есть куча литературы по привычному, статически классовому ООП, но очень мало по мессадж-пассинг\прототайп-базед\мета-программинг. Все эти притянутые понятия выливают в синтаксический сахар, который не делает ничего полезного, а даже наоборот, еще больше вносит путаницы и от того непонимамания многих вещей в языке. При этом часто этот синтаксический сахар дэже урезан и вспомнинают об этом лишь после (как например проебались с полями в конструкции class и тянут ее теперь только в proposol'ах будущих версий).
JS истинно объектный язык. В современный язык притащили много вкусных вещей для метапрограммирования. Нову примитивную сущность Symbol, и Proxy-объекты. С помощью которых можно еще больше и сильнее перегружать и менять поведение в динамике.
Другое дело, что почти никто не умеет этим пользоваться и не понимает, что такое объектное программирование на самом деле.
Им нужно не объектное, а статически типизированное. А какие именно структуры будут скрываться за этими типами, не собо важно. Важно что это просто структуры и функции, строго привязанные к ним, или иногда менее строго. То, что в Java\C++ это больше структурное программирование, нежели объектное. Объектное программирование не может существовать без динамической среды. Это противоречит самому понятию объекта. А динамическое программирование это слишком сложна и непанятна. И как бы не старались с пеной у рта фанатики кричать про низкий порог входа - низкий он именно что для входа, а не для всего остального. Модификация программ в рантайме всегда было уделом креативно мыслящих людей. Для большинства это слишком сложный уровень высокой абстракции.
Есть еще примитивы, но их можно тоже рассматривать в качестве синглтон объектов, потому как они боксятся, а сделаны разумеется для производительности. (тем более что сейчас ничего не мешает у примитивных добавить в цепочку прототипов прокси объект, отлавливащий сообщения, типа присваивания, и реалиховать поведение прототипов как полноценных объектов, но это ни к чему. проще воспринимать их как синглтоны. когда надо, любой примитив можно обернуть в полноценный независимый объект).
Так. Короче только объекты.
Все объекты делятся на callable и non-callable. Callable это функции, в понимании большинства. Но по факту это все те же объекты, со всеми свойствами что и у других.
Все объекты могут принимать всего несколько типов сообщений - get, set и call. При чем call может принимать только callable объект. при попытке послать call сообщение не-callable объекту будет исключение.
Сообщение get содержит один параметр, сообщение set два. Сообщение call параметром содержит кортеж аргументов, а так контекст this.
Если в объекте (а так же в цепочке прототипов) не назначены слушатели для get и set с определенными параметрами, ищутся слоты с такими именами в объекте и по цепочке. Если находится возвращается то, что в них лежит. Если в них лежит callable объект и ему посылают сообщние call сразу как получили его из слота, то у него будет перегружен контекст (this) на объект из чьего слота его получили. Если только этот объект не был сконструирован стрелочным синтаксисом, иначе контекст перегрузить нельзя. Если после получение callable объекта из слота его сразу не вызвать, а например положить ссылку на него в переменную, то контекст будет сброшен на тот, который был установлен у него в момент его создания (и это не обязательно будет тот же объект из чьего слота его получили).
У callable объектов есть scope (область видимости) и контекст (this) в момент посылки им сообщения call (вызова). scope средствами языка перегрузить нельзя, но некоторые окружения позволяют (например в ноде есть модеуль vm), this перегружается у callable объектов сконструированных не-стрелочным синтаксисом
Классов нет. Есть конструкторы. Любой конструктор принимает новый созданный объект, которому выставлен определенный прототип (другой объект). Оператор instanceof (someObject instanceof SomeClassName) проверяет лишь есть ли в цепочке прототипов у someObject объект который лежит у SomeClassConstructor в слоте с именем prototype. На сам конструктор ему поебать. Чтобы сменить класс, достаточно сменить цепочку прототипов. Даже если объект был сконструированным определенным конструктором.
Так же у объектов есть параметр ограничения доступа, контролирующие его расширяемость или изменяемость (sealed, extensible, frozen). У слотов объекта есть параметры configurable, enumerable, writable. Параметры слотов объекта не влияют на объекты, что в них лежат. Они лишь контролируют доступ к самим слотам.
Все. Никаких классов. Никаких интерфейсов. Как отдельных сущностей. По факту все есть объект и все строит из них.
наследование реализуется выстраиванием цепочки прототипов. Инкапсуляция только на уровне scope'в (читай замыканий).
В остальном все меняется и все динамично, если только специально все не зафризить в момент конструирования. Но обычно этим никто не заморачивается по причине оверхеда и бессмысленности. Разве только фанатики по иммутабельности, н это все из разряда те, кому надо чтобы им по рукам бил компилятор\рантайм\дядя петя. Все "привычные" понятия тянуться в язык для еще более простого вкатывания тех, кто приходит из других языков. Так уж сложилось, что есть куча литературы по привычному, статически классовому ООП, но очень мало по мессадж-пассинг\прототайп-базед\мета-программинг. Все эти притянутые понятия выливают в синтаксический сахар, который не делает ничего полезного, а даже наоборот, еще больше вносит путаницы и от того непонимамания многих вещей в языке. При этом часто этот синтаксический сахар дэже урезан и вспомнинают об этом лишь после (как например проебались с полями в конструкции class и тянут ее теперь только в proposol'ах будущих версий).
JS истинно объектный язык. В современный язык притащили много вкусных вещей для метапрограммирования. Нову примитивную сущность Symbol, и Proxy-объекты. С помощью которых можно еще больше и сильнее перегружать и менять поведение в динамике.
Другое дело, что почти никто не умеет этим пользоваться и не понимает, что такое объектное программирование на самом деле.
Им нужно не объектное, а статически типизированное. А какие именно структуры будут скрываться за этими типами, не собо важно. Важно что это просто структуры и функции, строго привязанные к ним, или иногда менее строго. То, что в Java\C++ это больше структурное программирование, нежели объектное. Объектное программирование не может существовать без динамической среды. Это противоречит самому понятию объекта. А динамическое программирование это слишком сложна и непанятна. И как бы не старались с пеной у рта фанатики кричать про низкий порог входа - низкий он именно что для входа, а не для всего остального. Модификация программ в рантайме всегда было уделом креативно мыслящих людей. Для большинства это слишком сложный уровень высокой абстракции.
>>609551
Вы заебали со своими котятами и фигурами. Реальные примеры из прода будут?
> Далее. У тебя есть кошечка. Она родила котят. Все котята имеют хаост, усы, по два уха. Это наследование.
Вы заебали со своими котятами и фигурами. Реальные примеры из прода будут?
>>718646
css
css
>>718646
на проде наследование ненужно, только интерфейсы.
на проде наследование ненужно, только интерфейсы.
>>718646
Окей, допустим ты биолог, ты создаёшь класс Фрукт и наследуешь от него Яблоко...
Окей, допустим ты биолог, ты создаёшь класс Фрукт и наследуешь от него Яблоко...
>>607925 (OP)
Нахуй не нужно на самом деле. Рыночек порешал что на рынке ООП не нужно.
Популярные языки отказываются от ООП. Тот же Javascript, Python, C++ в принципе не заставляют тебя использовать его, а какой-нибудь Go так вообще решил дать пососать.
>Для чего нужно ООП?
Нахуй не нужно на самом деле. Рыночек порешал что на рынке ООП не нужно.
Популярные языки отказываются от ООП. Тот же Javascript, Python, C++ в принципе не заставляют тебя использовать его, а какой-нибудь Go так вообще решил дать пососать.
>>719192
А много ли языков "заставляет"? Таких только джава да шарфик, и всё. В остальных как были функции, так и есть.
А много ли языков "заставляет"? Таких только джава да шарфик, и всё. В остальных как были функции, так и есть.
>>719192
Ну вот популярные языки не заставляют тебя использовать функциональщину. Это значит, что они от неё отказываются? По такой логике мультипарадигменные языки отказываются вообще от всего просто в силу того, что не заставляют тебя использовать что-то конкретное.
Больше половины стандартных библиотек написана с помощью ООП, и для их использования приходится его юзать. Не заставляют, да?
Это тот, к которому недавно прикрутили джаваподобные классы?
С каких пор под ООП понимается то, как сделано в джавашарпах? Smalltalk, видать, не ООП был.
> Не заставляют => Отказываются
Ну вот популярные языки не заставляют тебя использовать функциональщину. Это значит, что они от неё отказываются? По такой логике мультипарадигменные языки отказываются вообще от всего просто в силу того, что не заставляют тебя использовать что-то конкретное.
> Python, C++
Больше половины стандартных библиотек написана с помощью ООП, и для их использования приходится его юзать. Не заставляют, да?
> Javascript
Это тот, к которому недавно прикрутили джаваподобные классы?
> Go
С каких пор под ООП понимается то, как сделано в джавашарпах? Smalltalk, видать, не ООП был.
>>719242
В чем прикол юзать гринтекст приписывая какие-то собственные фантазии оппоненту?
В чем прикол юзать гринтекст приписывая какие-то собственные фантазии оппоненту?
>>719242
Так в том-то и дело что Smalltalk это был именно что ООП. То что Алан Кэй придумал, который был прекрасный математик, джазовый исполнитель и вообще хороший человек. Но вот в промышленной, рыночной разработке вроде никогда не участвовал.
А вот всякие Python и C++ нормальный, тот самый, ООП не использует. Его рыночек порешал в пользу той каши, которая щас называется "Мультипарадигмальные языки общего назначения".
Ну да, и от функциональщины тоже. В угоду "практичного, васянского кода который все и пишут.
>С каких пор под ООП понимается то, как сделано в джавашарпах? Smalltalk, видать, не ООП был.
Так в том-то и дело что Smalltalk это был именно что ООП. То что Алан Кэй придумал, который был прекрасный математик, джазовый исполнитель и вообще хороший человек. Но вот в промышленной, рыночной разработке вроде никогда не участвовал.
А вот всякие Python и C++ нормальный, тот самый, ООП не использует. Его рыночек порешал в пользу той каши, которая щас называется "Мультипарадигмальные языки общего назначения".
> Ну вот популярные языки не заставляют тебя использовать функциональщину. Это значит, что они от неё отказываются?
Ну да, и от функциональщины тоже. В угоду "практичного, васянского кода который все и пишут.
>>719256
И правильно. Бизнес-задачи на них решаются намного эффективнее, а на сомнительных парадигмах кодеры пусть в свободное время пишут.
Да.
> Его рыночек порешал в пользу той каши, которая щас называется "Мультипарадигмальные языки общего назначения".
И правильно. Бизнес-задачи на них решаются намного эффективнее, а на сомнительных парадигмах кодеры пусть в свободное время пишут.
> Ну да, и от функциональщины тоже. В угоду "практичного, васянского кода который все и пишут.
Да.
>>719249
Успехи ООП объясняются только успехами GUI в 90-х. Когда у тебя одни языки без ГЦ, то иерархичная структура объектов-овнеров, события и прочее идеально ложились на ООП. Больше оно никуда не ложилось, данные в реляционных базах лежали, игори вообще на стейтмашине opengl себя нормально чувствовали. Но по инерции люди почему-то подумали, что внедрять ооп - офигенная идея. Но это было именно что по инерции.
С переходом GUI в веб ООП умерло окончательно, потому что в вебе эти подходы не работают совсем.
Успехи ООП объясняются только успехами GUI в 90-х. Когда у тебя одни языки без ГЦ, то иерархичная структура объектов-овнеров, события и прочее идеально ложились на ООП. Больше оно никуда не ложилось, данные в реляционных базах лежали, игори вообще на стейтмашине opengl себя нормально чувствовали. Но по инерции люди почему-то подумали, что внедрять ооп - офигенная идея. Но это было именно что по инерции.
С переходом GUI в веб ООП умерло окончательно, потому что в вебе эти подходы не работают совсем.
33 Кб, 608x511>>719265
Ну так я ж за это и топлю. Когда я говорю "ФП/ООП никто не использует", я подразумеваю что никто не придерживается тех маняфантазий, которые себе профессора понавыдумывали. Вообще, наука она должна быть описательной, а не предписательной. Когда компьютерные учёные начинают крупным корпорациям пояснять как им писать свой код - это уже за рамки выходит.
Понятно, что современный код это смесь трёх парадигм(СП, ФП, ООП), из них берутся какие-то лучшие моменты, а другие просто рыночком отбрасываются.
>>719271
Ну чел, там ж на гитхубе их как говна...
Ну так я ж за это и топлю. Когда я говорю "ФП/ООП никто не использует", я подразумеваю что никто не придерживается тех маняфантазий, которые себе профессора понавыдумывали. Вообще, наука она должна быть описательной, а не предписательной. Когда компьютерные учёные начинают крупным корпорациям пояснять как им писать свой код - это уже за рамки выходит.
Понятно, что современный код это смесь трёх парадигм(СП, ФП, ООП), из них берутся какие-то лучшие моменты, а другие просто рыночком отбрасываются.
>>719271
Ну чел, там ж на гитхубе их как говна...
>>719272
И как долго в этой куче говна надо рыться, чтобы найти эталонную ооп реализацию?
>Ну чел, там ж на гитхубе их как говна...
И как долго в этой куче говна надо рыться, чтобы найти эталонную ооп реализацию?
>>719268
Сморя чё щитать ООП. Вот laravel эт ООП?
Сморя чё щитать ООП. Вот laravel эт ООП?
>>719272
Просто понятия эволюционируют, и сейчас под ними понимают не то, что было изначально. Впрочем, под ООП сейчас что только не понимают.
Просто понятия эволюционируют, и сейчас под ними понимают не то, что было изначально. Впрочем, под ООП сейчас что только не понимают.
>>719287
Так на том самом, настоящем ООП вообще никогда не писали. Это не то что всё поменялось
Так на том самом, настоящем ООП вообще никогда не писали. Это не то что всё поменялось
>>719268
В вебе иерархическая структура так и осталась. И дело не в управлении памятью, а тупо в том, что одни элементы гуя состоят из других элементов поменьше. Даже компоненты в реакте - это тоже одно из видений ООП.
Ну а сейчас изобрели монгу, чтобы хранить объекты.
Километровые процедурные портянки, в которых почти никто не мог разобраться. Но геймдев вообще особняком стоит, и парадигмы так свои, уникальные: Data-Driven Design, Entity-Component System (тоже своего рода ООП) и прочее, больше нигде не применимое.
В вебе иерархическая структура так и осталась. И дело не в управлении памятью, а тупо в том, что одни элементы гуя состоят из других элементов поменьше. Даже компоненты в реакте - это тоже одно из видений ООП.
> данные в реляционных базах лежали
Ну а сейчас изобрели монгу, чтобы хранить объекты.
> игори вообще на стейтмашине opengl себя нормально чувствовали
Километровые процедурные портянки, в которых почти никто не мог разобраться. Но геймдев вообще особняком стоит, и парадигмы так свои, уникальные: Data-Driven Design, Entity-Component System (тоже своего рода ООП) и прочее, больше нигде не применимое.
42 Кб, 1267x625>>719293
Иерархическая структура есть в любом продукте человеческой мысли из-за особенностей этой мысли. Если называть это ООП, то тогда и ракету Союз можно назвать ООП. Она же из ОБЪЕКТОВ состоит.
Но это все не так, ООП это более конкретная вещь.
Я, например, не считаю, что энтити в геймдеве это ООП, так же, как и то, что хранится в монге, и уж тем более это не про компоненты в реакте. То есть ты сначала дай определение ООП, а потом решим, сдохло оно, или нет. В общепринятом смысле сдохло, см. пикрелейтед.
А то может по твоему определению в хаскеле ООП, а мы тут спорим.
Иерархическая структура есть в любом продукте человеческой мысли из-за особенностей этой мысли. Если называть это ООП, то тогда и ракету Союз можно назвать ООП. Она же из ОБЪЕКТОВ состоит.
Но это все не так, ООП это более конкретная вещь.
Я, например, не считаю, что энтити в геймдеве это ООП, так же, как и то, что хранится в монге, и уж тем более это не про компоненты в реакте. То есть ты сначала дай определение ООП, а потом решим, сдохло оно, или нет. В общепринятом смысле сдохло, см. пикрелейтед.
А то может по твоему определению в хаскеле ООП, а мы тут спорим.
80 Кб, 1163x531>>719302
Да, в этом и смысл ООП. Ты подразделяешь все данные на некоторые осмысленные сущности, строишь их иерархию и делаешь так, чтобы они обменивались инфой друг с другом. Всё.
Да, как раз потому, что ООП лучше всего описывает объекты реального мира.
Я тогда продолжу твой пикрелейтед и скажу, если ООП сдохло, то остальное и не оживало никогда.
> Иерархическая структура есть в любом продукте человеческой мысли из-за особенностей этой мысли.
Да, в этом и смысл ООП. Ты подразделяешь все данные на некоторые осмысленные сущности, строишь их иерархию и делаешь так, чтобы они обменивались инфой друг с другом. Всё.
> Если называть это ООП, то тогда и ракету Союз можно назвать ООП. Она же из ОБЪЕКТОВ состоит.
Да, как раз потому, что ООП лучше всего описывает объекты реального мира.
> пикрелейтед
Я тогда продолжу твой пикрелейтед и скажу, если ООП сдохло, то остальное и не оживало никогда.
>>719302
Классы, интерфейсы, инкапсуляция, полиморфизм, наследование, паттерны.
>ты сначала дай определение ООП
Классы, интерфейсы, инкапсуляция, полиморфизм, наследование, паттерны.
>>719318
Что конкретно понимается под абстракцией. По-моему она и в остальных парадигмах есть.
Что конкретно понимается под абстракцией. По-моему она и в остальных парадигмах есть.
>>719327
https://ru.wikipedia.org/wiki/Абстракция_данных
Судя по определению, это когда ты описываешь некую сущность и оставляешь только самые важные поля, а не пытаешься перечислить вообще все возможные характеристики, какие есть на самом деле.
https://ru.wikipedia.org/wiki/Абстракция_данных
Судя по определению, это когда ты описываешь некую сущность и оставляешь только самые важные поля, а не пытаешься перечислить вообще все возможные характеристики, какие есть на самом деле.
>>719313
Это смысл любой инженерной деятельности, включая программирование в данном случае. Назови подход, который не подразумевает иерархию.
Объекты реального мира лучше всего описывают дифференциальные уравнения, уж в таком мире мы живем
Тренды важнее абсолютных значений
>Да, в этом и смысл ООП
Это смысл любой инженерной деятельности, включая программирование в данном случае. Назови подход, который не подразумевает иерархию.
>Да, как раз потому, что ООП лучше всего описывает объекты реального мира.
Объекты реального мира лучше всего описывают дифференциальные уравнения, уж в таком мире мы живем
>Я тогда продолжу твой пикрелейтед и скажу, если ООП сдохло, то остальное и не оживало никогда.
Тренды важнее абсолютных значений
>>719334
Ну так я и говорю, это не отличительная черта ООП, она вообще при любом моделировании используется.
Ну так я и говорю, это не отличительная черта ООП, она вообще при любом моделировании используется.
>>719347
А по какому определению раст с хаскелем не ооп?
А по какому определению раст с хаскелем не ооп?
>>719341
Нет такого. Потому что остальные подходы - всего лишь подвид ООП.
Они описывают не сами объекты, а их изменение. Сами объекты - это их свойства. Ничего не говорится о том, как эти свойства изменяются и обрабатываются.
Конечно. ООП упало до своей асимптоты, ФП доросло до своей асимптоты. Так и останутся. Тренды - это не обязательно линейные функции, иначе гипербола (убывающая экспонента, etc) пересекала бы асимптоту и устремлялась в бесконечность
> Назови подход, который не подразумевает иерархию.
Нет такого. Потому что остальные подходы - всего лишь подвид ООП.
> Объекты реального мира лучше всего описывают дифференциальные уравнения
Они описывают не сами объекты, а их изменение. Сами объекты - это их свойства. Ничего не говорится о том, как эти свойства изменяются и обрабатываются.
> Тренды важнее абсолютных значений
Конечно. ООП упало до своей асимптоты, ФП доросло до своей асимптоты. Так и останутся. Тренды - это не обязательно линейные функции, иначе гипербола (убывающая экспонента, etc) пересекала бы асимптоту и устремлялась в бесконечность
>>719386
Есть, способ изменения состояния. ООП - это расширение СП, и есть присваивание. В ФП же ты должен заново создавать объект с другим состоянием и передавать его в рекурсивную функцию.
Есть, способ изменения состояния. ООП - это расширение СП, и есть присваивание. В ФП же ты должен заново создавать объект с другим состоянием и передавать его в рекурсивную функцию.
>>719402
Ничто не запретит мне даже в чистой Сишке возвращать новые данные, вместо мутации имеющихся. Сишка стала ФП?
так не работает, ребятки, все эти иммутабельности, композиции функция и т.д. прекрасно _могут_ быть использованы по надобности в 9 языках из 10.
Ничто не запретит мне даже в чистой Сишке возвращать новые данные, вместо мутации имеющихся. Сишка стала ФП?
так не работает, ребятки, все эти иммутабельности, композиции функция и т.д. прекрасно _могут_ быть использованы по надобности в 9 языках из 10.
>>719419
Да, почему нет? То, что язык не приписывает себе какую-то парадигму, ещё не значит, что на нём невозможно так писать.
> Сишка стала ФП?
Да, почему нет? То, что язык не приписывает себе какую-то парадигму, ещё не значит, что на нём невозможно так писать.
>>719419
Чтобы программировать в стиле ФП на сишке придется придерживаться неких правил, за нарушение которых компилятор тебя даже не предупредит.
Чтобы программировать в стиле ФП на сишке придется придерживаться неких правил, за нарушение которых компилятор тебя даже не предупредит.
>>719429
Отлично. В таком случае все эти ФП/ООП -- свойство конкретного проекта или даже модуля (ибо ничито не помешает мне вставить мутабельный под капотом модуль в иммутабельную обёртку).
А все эти срачи про языки идут лесом. Алсо, процедурная парадигма, как прямо индифферентная к мутабельности -- имеет ввиду и тех и других.
Отлично. В таком случае все эти ФП/ООП -- свойство конкретного проекта или даже модуля (ибо ничито не помешает мне вставить мутабельный под капотом модуль в иммутабельную обёртку).
А все эти срачи про языки идут лесом. Алсо, процедурная парадигма, как прямо индифферентная к мутабельности -- имеет ввиду и тех и других.
>>719435
Это уже вопрос к уровню проверок компилятор/линтера. Хаскелл тебя тоже об unsafe под капотом не предупредит.
Это уже вопрос к уровню проверок компилятор/линтера. Хаскелл тебя тоже об unsafe под капотом не предупредит.
>>719463
Да, всё так.
Да, всё так.
>>719382
Ну то есть твое определение не означает ничего. Хуевое определение, возникают сомнения в твоем интеллектуальном уровне, если ты таким пользуешься
>Нет такого. Потому что остальные подходы - всего лишь подвид ООП.
Ну то есть твое определение не означает ничего. Хуевое определение, возникают сомнения в твоем интеллектуальном уровне, если ты таким пользуешься
>>720104
ООП не подразумевает иерархию.
ООП не подразумевает иерархию.
Любой язык - ООП. JS - ООП. C - ООП. Хаскелль - ООП. Ассемблер - ООП.
>>682855
Ну вот видишь, почему не нужно слушать двачеэкспертов. Всегда удивляюсь, как тут люди красиво пиздят с умным видом, а потом просто на ровном месте обсираются. Как недавно например с O(2n).
Так вот как сделано присваивание в хаскеле. А сделано оно так: вместо
a = readFile(); print(a);
пишется что то типа (псевдокод):
main = bind(readfile, (a) => print(a))
bind это одна из операций определенных над монадой.
В итоге вся программа представляет собой выражение, которое возвращает монаду IO. Вот эта монада по сути и есть алгоритм. Хаскель знает как ее "запустить на вычисление", что он и делает, и тогда программа начинает выполняться.
Ну вот видишь, почему не нужно слушать двачеэкспертов. Всегда удивляюсь, как тут люди красиво пиздят с умным видом, а потом просто на ровном месте обсираются. Как недавно например с O(2n).
Так вот как сделано присваивание в хаскеле. А сделано оно так: вместо
a = readFile(); print(a);
пишется что то типа (псевдокод):
main = bind(readfile, (a) => print(a))
bind это одна из операций определенных над монадой.
В итоге вся программа представляет собой выражение, которое возвращает монаду IO. Вот эта монада по сути и есть алгоритм. Хаскель знает как ее "запустить на вычисление", что он и делает, и тогда программа начинает выполняться.
Главный недостаток ООП заключается в следующем: процессы и данные существуют отдельно друг от друга (как в модели деятельности организации, так и в модели программной системы), причем проектирование ведется от процессов к данным. Таким образом, помимо функциональной декомпозиции, существует также структура данных, находящаяся на втором плане.
>>610748
Немного не в тему, но все равно скажу. Это же заебись что статические методы принадлежат одному классу FileUtills. Все хранятся в одном месте, сразу понятно где искать, читаемость вызова таких функций достигает 9999999. ООП не ООП - какая разница, получилось очень удобно
Немного не в тему, но все равно скажу. Это же заебись что статические методы принадлежат одному классу FileUtills. Все хранятся в одном месте, сразу понятно где искать, читаемость вызова таких функций достигает 9999999. ООП не ООП - какая разница, получилось очень удобно
>>719316
А про Message Passing и динамизм забыл, хотя это и есть самое главное в ОП, а не классы с наследованием.
А про Message Passing и динамизм забыл, хотя это и есть самое главное в ОП, а не классы с наследованием.
>>614724
Про opaque types современные зумеры наверное и не слышали
Про opaque types современные зумеры наверное и не слышали
>>615202
Там это дрочат чтобы по максимуму в кэш попадать, data driven
Там это дрочат чтобы по максимуму в кэш попадать, data driven
>>611441
Это чистая субъективщина, но мне кажется, что джава намного легче понимается чем шарпей. Хотя странно, первым языком у меня сам шарп
Это чистая субъективщина, но мне кажется, что джава намного легче понимается чем шарпей. Хотя странно, первым языком у меня сам шарп
>>615245
Ты перепутал, екс-парашу труднее перелопачивать.
Ты перепутал, екс-парашу труднее перелопачивать.
Люблю я эту картину, когда собираются вместе ооп-сектанты и ооп-хейтеры и устраивают шизобатлы. А самое смешно, что никто даже не может дать точное определение ООП.
>>735896
Потому и срутся, что у одного определение противоречит определению другого.
Потому и срутся, что у одного определение противоречит определению другого.
>>735896
Ты просто дебил и не шаришь. У тебя наверное и имена классов заканчиваются на -er.
мимо егор.
Ты просто дебил и не шаришь. У тебя наверное и имена классов заканчиваются на -er.
мимо егор.
>>735912
Int Eger.
Int Eger.
>>610066
Для этого придумали модули и пакеты, в которых хранятся типы и функции с процедурами для работы с ними.
>Удобно хранить тип данных, вместо с методами работы с ним. Очень блядь удобно. Невыносимо удобно.
Для этого придумали модули и пакеты, в которых хранятся типы и функции с процедурами для работы с ними.
>>616238
У тебя точно умственная отсталость, если ты не различаешь свои субъективные ощущения и объективное существование.
>Просто если ты не ощущаешь вокруг себя количественные явления, то это умственная отсталость.
У тебя точно умственная отсталость, если ты не различаешь свои субъективные ощущения и объективное существование.
>>660132
Недооценённый пост
>ооп - один из возможных подходов к композиции структур данных и алгоритмов, обрабатывающих эти данные
Недооценённый пост
>>679460
Си -- это вообще недоязык высокого уровня, в нём нет ни модульности, ни массивов, это по большому счёту универсальный ассемблер.
>На С без всякого ООП целые операционные системы писали, представь себе. Вот только каким хуем это наделяет С всем тем, что есть у ООП и каким хуем оно отменяет те возможности, которые ООП предоставляет, одному тебе, долбоебу, известно.
Си -- это вообще недоязык высокого уровня, в нём нет ни модульности, ни массивов, это по большому счёту универсальный ассемблер.
>>721053
Класека, функциональщики сами себе придумали трудность и героически ее преодолели.
Класека, функциональщики сами себе придумали трудность и героически ее преодолели.
>>741252
Удобнее писать через точку
system.getDisplay().getSize()
чем пробрасывать парашу через свободные функции. Ты там одних временных переменных заебешься делать. Будет как во всяких старых винапи
System sys
Display disp
GetCurrentSystem(&sys)
GetDisplay(sys, &disp, TRUE)
SizeClassXXL size
GetSize(disp, (DisplayDevice*)0, size)
Спасибо наелись
Удобнее писать через точку
system.getDisplay().getSize()
чем пробрасывать парашу через свободные функции. Ты там одних временных переменных заебешься делать. Будет как во всяких старых винапи
System sys
Display disp
GetCurrentSystem(&sys)
GetDisplay(sys, &disp, TRUE)
SizeClassXXL size
GetSize(disp, (DisplayDevice*)0, size)
Спасибо наелись
>>741301
Ну да, ведь императивщикам чистота и контролируемые сайд-эффекты не нужны, они и без неё пишут безопасный и композабельный код. А нет, постойте, не пишут.
Ну да, ведь императивщикам чистота и контролируемые сайд-эффекты не нужны, они и без неё пишут безопасный и композабельный код. А нет, постойте, не пишут.
>>742844
Вот только код в примерах идентичен (за исключением героического оборачивания в монаду)
Удивительное совпадение, да?
Вот только код в примерах идентичен (за исключением героического оборачивания в монаду)
Удивительное совпадение, да?
>>742862
Монадическое IO в хаски нужно для отделения чистого кода от эффектов. Императивщики такого разделения не делают, им и так норм.
Монадическое IO в хаски нужно для отделения чистого кода от эффектов. Императивщики такого разделения не делают, им и так норм.
>>743610
Smalltalk же.
Smalltalk же.
>>721053
Охохо, давайте положим код не в void main, а в main = do, ведь от этого он тут же станет правильнее и безопаснее (нет)
Охохо, давайте положим код не в void main, а в main = do, ведь от этого он тут же станет правильнее и безопаснее (нет)
>>802347
Проведи эксперимент:
Найди объект.
Измени его свойство.
Если для этого не пришлось делать копию -- это не ФП.
Проведи эксперимент:
Найди объект.
Измени его свойство.
Если для этого не пришлось делать копию -- это не ФП.
Тред утонул или удален.
Это копия, сохраненная 1 января 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 1 января 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.