ВЫ БЛЯТЬ ГЛЯНЬТЕ НА ОБЪЕМ КОДА ПОД КАПОТОМ ЧТОБЫ ОДНОЙ СРАНОЙ ПЕРЕМЕННОЙ ПРИСВОИТЬ ЗНАЧЕНИЕ!
СУКА БЛЯТЬ. И это еще даже не байт-код. Пидорасы, блять. Пидорасы. Сука, Гитлера на вас нет.
СУКА БЛЯТЬ. И это еще даже не байт-код. Пидорасы, блять. Пидорасы. Сука, Гитлера на вас нет.
4 ИМЕННОВАННЫЕ КОНСТАНТЫ? НАХУЯ?
Давайте лучше сделаем блять классы, которые у нас развернутся вот в такую хуйню. И это еще блять перед компиляцией в байт-код. Ради 4 констант. 16 байтов. Листинг кода на всю страницу.
Давайте лучше сделаем блять классы, которые у нас развернутся вот в такую хуйню. И это еще блять перед компиляцией в байт-код. Ради 4 констант. 16 байтов. Листинг кода на всю страницу.
Взгляньте, как люди делали, чтобы игры шли даже на некрожелезе: https://ru.wikipedia.org/wiki/Быстрый_обратный_квадратный_корень
И сравните блять с текущим подходом. Если вы скажите Кармаку, что каждый раз создаете новые объекты, потому что вы мнительные невротики, которые по десять раз дергают ручку двери, потому что вдруг они забыли присвоить переменной нужное значение, то он вас оббоссыт.
Вас, куколдов, сойбоев, педерастов, пассивных пидоров, которые убили блять все программирование. Пидорасы, вы ебаные, жидовье, блять. Иммутабельность они продвигают. За чистотой вашего кода скрывается блять ГОРА ЕБАНОГО МУСОРА и костылей, из-за которых юзер докупает новую оперативку и новый девайс. Пидорасы, сдохните блять уже. Говноеды пидерасты, ненавижу, блять, отрежьте свои отростки и не размножайтесь, хуилы блять.
И сравните блять с текущим подходом. Если вы скажите Кармаку, что каждый раз создаете новые объекты, потому что вы мнительные невротики, которые по десять раз дергают ручку двери, потому что вдруг они забыли присвоить переменной нужное значение, то он вас оббоссыт.
Вас, куколдов, сойбоев, педерастов, пассивных пидоров, которые убили блять все программирование. Пидорасы, вы ебаные, жидовье, блять. Иммутабельность они продвигают. За чистотой вашего кода скрывается блять ГОРА ЕБАНОГО МУСОРА и костылей, из-за которых юзер докупает новую оперативку и новый девайс. Пидорасы, сдохните блять уже. Говноеды пидерасты, ненавижу, блять, отрежьте свои отростки и не размножайтесь, хуилы блять.
А сейчас для этого есть инструкция в процессоре, которая будет работать быстрее олдскульного хака.
Только она не используется, потому что не заложено в быдлоязыки из говна.
Как пример, видел игру, требующую SSE4.2. Казалось бы, круто жы, оптимизации, а на деле патчик из нескольких байтов убирает это требование и идет спокойно без всяких SSE4.2 Вот так. Тупо показуха, стоит галочка на использование, а на самом деле ничего не используется, а дебилы, пидоры, и прочие иммутабельные выродки воображают в своих тупорылых головках какие у них охуенные технологии.
Хуя жавамакаку разорвало.
>ПРОИЗВОЛЬНЫЙ ДОСТУП К ОБЪЕКТАМ В ПАМЯТИ
Додель, произвольный доступ и иммутабельность - это разные плоскости абсолютно. Можно на няшных иммутабельных лиспах написать код, который будет последовательно читать данные из рамы и тем самым аккуратно вдоль шерсти расчёсывать кэш процессора, а можно на гольной сишке нашароёбить код, который будет хуй пойми как тыкаться по разным областям выделенной памяти и КЭШ МИСС ГРОБ КЛАДБИЩЕ ПИДОР.
пашол пидорас >>= нахуй
То есть, тебе например нормально что в жабе вместо паблик полей геттеры и сеттеры и это объясняется в пользу будущего рефакторинга, мол можно будет туда бизнес логику еще засунуть в будущем. Но в реале в поля никогда никто бизнес логику не сует в том числе и я за 15 лет.
Тебя уже обманывают много лет, а к иммутабельному просто еще не привык. Поверь, ты еще не видишь и капли того бойлерплейта который есть в современном программирование иногда люди берут фреймворки чтобы решить недельную работу, но потом тратять на этот фреймворк месяцы и это нормально в этом кустарном мире программирования
>Можно на няшных иммутабельных лиспах написать код
Лисперы: пиздеж since 1984
> Анон, зачем (((они))) от мира программирования продвигают такую фичу как иммутабельность и принудительно пересаживают всех на ее оверхеды?
Потому что успех ученых не зависит от успеха бизнеса, и в науке пышным цветом цветут манятеории. В этом, кстати, нет ничего плохого, наука для того и нужна, чтобы из манятеорий бизнес потом приходил и брал нужное. Если бы было не так, то это была бы не наука, а бизнес, а бизнес уже есть.
Проблемы начинаются, когда весь бред ученых начинают принимать на веру. Например, большинство ученых, помимо того, что она продвигают иммутабельность, продвигают еще и марксизм.
Неизбежная смерть императивных языков, которую они продвигают, - это такой же марксизм. Высеры типа "а вот мы ща как все автоматически распараллелим" - это рассуждения о экономическом гении Сталина. И так далее.
>Они продвигают %чето%
>Думаю они делают это потому что марксизм
>Думаю это %чето% хуйня потому что марксизм
Кекнул
Для аутистов напоминаю: собеседнику не требуется доказывать то, по поводу чего у вас уже консенсус.
Все используется
>Если вы скажите Кармаку
>скажите
Очередной безграмотный школьник пришел поучить отцов ебаться.
Ну, ооооок.
Потому что иммутабельность во много раз облегчает параллельные вычисления, за которыми будущее, так как мы уже уперлись в лимит процессорных мощностей и тупо наращиваем ядра.
Вообще-то нет
ОП, для понимания ответа на свой вопрос тебе необходимо достичь просветления.
Сам ответ: причина в (((Лиспе))).
Бред. Иммутабельность упрощает работу с данными и спасает от мучительных дебагов. То что в Котлине и Джаве горы бойлерплейта и абстрактные фабрики это уже проблема другой области, в JS как раз все хорошо получается, вместо лапши и хуевого кода чистенькие редьюсеры, хороший стейт менеджмент и т.д.
пик не имеет никакого смысла
Очевидный намек на хайповые технологии.
Питон поменять с хаскелем хотя бы
Хаскель говнище для аутистов, хайпа там нет. А вот Питон сейчас везде + ML.
Извинись
Он устарел. JS не хайповый без ноды. Python тоже не хайповый. А Rust-то вообще каким боком?
Пайтон хайпуется очень активно в среде дата-сосаентистов. JS хайповый и без ноды, непонятно правда, что именно греет рынок, но за последний год средние зарплаты жабаскриптеров выросли очень сильно. Го нуф сейд. Свифт там зря, да, про раст сложно сказать.
В жс хачкель имитируют в объектном языке, как костыль выглядит вся эта недофункцианальщина
В жабах тоже костыль, но там можно, тк многопоточность, и скала если что есть
Прошу прощения
Зачем мне прощения от питхуонщика мланальщика?
Пашол нахуй
>Пайтон хайпуется очень активно в среде дата-сосаентистов
Тогда почему язык R не хайповый? Среди датасаянтистов-то хайповый-то. Скорее сам датасаянтизм хайповый, а не питон.
>JS хайповый и без ноды
Фронтенд не хайповый. А зарплаты растут наверно потому шо фронтов не хватает. Ты ещё скажи jQuery хайповый.. JS просто нужен в любом веб приложении, вот и всё. Но такими словами HTML так вообще все рекорды хайпа мочит.
>Го нуф сейд.
А вроде уже стихает.
>Свифт там зря, да, про раст сложно сказать.
Вот свист вроде как не зря. Я про свивт часто слышу, хотя в большенстве свифт это язык разработки под эпл технику
Мем про сойбоев это самое хайповое, что есть в этом треде, и его принесло ты.
DataOriented закукарекал.
Кэшмисс это какие-то еврейские байки, чтобы оправдать DoD.
На деле все жалкие попытки сделать такую архитектуру пож проект сложнее хеллоуворлда сосут хуй потому что ВНЕЗАПНО гешефт от него гораздо меньше (вообще нет его блять), чем человекочасы, потраченные на еблю с АрХиТеКтУрОй.
>пук
Где эта инструкция?
Во-первых, since 1958.
Во-вторых, есть дохуя лиспов с иммутабельностью, хотя бы та же Clojure, но в кругозор императивной жабамакаки он, конечно же, не входит.
>Кэшмисс это какие-то еврейские байки, чтобы оправдать DoD.
Ооок, вопросов больше не имею.
Хз, я лампово пишу код на Go мутабелтный, с циклами и тп. Один m4.large у меня 10к rps держит при загрузке проца в 90%
>16 vcpu 32 gib mem up to 10 Gbps
>90% при 10к rps
Обычный результат же
Зис. Пару лет назад я осознал что все манябестпрактисес противоречат сами себе, а еще они не фальсифицируемы, и вообще весь ойти сплошь роится суевериями и религиями. Начал писать дома код полажа хуй на все это, полет нормальный. На работе постоянно плююсь про себя, что надо соблюдать весь этот фен-шуй, от которого толку ноль, но времени уходит дохуя.
петушок тебя в /ga/ заждались
>подразумевает что /pr/ не филиал /ga/
Ну если только ржавотред
Ты, видимо, главный из ожидающих.
>Во-первых, since 1958.
Не имею ничего против работ Маккарти
>Во-вторых, есть дохуя лиспов с иммутабельностью
Угу, и на каждом можнозделоть то, что написано в том посте.
> Угу, и на каждом можнозделоть то, что написано в том посте.
Ну так-то да, например https://docs.racket-lang.org/reference/vectors.html
Машиномощности сейчас гораздо быстрее развиваются, чем пожирание программами ресурсов, вот и переходят на такое. 99,9% загрузки - дыры в использовании памяти с плохим отсечением, а не просто "выделили в 10 раз больше памяти, чем нужно"
Как раз наоборот. Закон Мура кончился, а вот закон Вирта нет. Скоро весь софт начнет адово тормозить, и всякие быдлокодеры пишущие неоптимальный код соснут.
>Кармаку
Так его же разработал Абраш
Тут много причин. Во-первых, concurrency. Во-вторых, это очень сильно упрощает код, что очень годный перк, когда над проектом работают много человек. В-третьих, код становится проще покрыть тестами или вовсе доказать корректность формальными методами. В-последних, оверхед не такой уж и большой, как ты себе представляешь, даже в убогой имплементации Котлина или что там у тебя на пике. Со временем ты откроешь, как на деле работают аллокаторы памяти, как любые проекты переизобретают dataflow графы, как твой любимый Джон Кармак самолично топит за иммутабельность и почему JIT в целом не такая уж и плохая идея. Очень много ресерча стоит за этим, буквально десятилетия. Да и современные компьютеры работают немножко не так, как ты себе представляешь. Начни хотя бы с https://lwn.net/Articles/250967/ и MIT 6.851.
rsqrtss/rsqrtps ровно 20 лет назад завезли в SSE. Относительно недавно их расширили для AVX.
>Во-первых, concurrency
Это единственная реальная причина, остальное бред и хуйня. Код "проще" не становится, любая императивщина как раз воспринимается легче и интуитивнее, чем мешанина из функций. Чтобы код был тестируемый, его внезапно надо дизайнить тестируемым(то есть писать через TDD), от конкретной парадигмы это не зависит. Если ты думаешь, что писал говно в ООП, а потом вдруг открыл для себя ФП и твой код внезапно стал легче и понятнее, то нет, не стал, ты все так же пишешь говно, скорее даже еще более лютое, потому что дело было не в парадигме, а в программисте.
Как раз-таки Кармак угорает по Racket (который, как Scheme, дофига функциональный).
Дебил блять это лиспосемейство они все функциональные.
>concurrency легчи!!!11111
Пример из продакшна и аналогичный на императивщине без иммутабельности, где первый дает пососать второму или нахуй с тупичка
Common Lisp функционален? Лол, в нём рекурсию зазорно делать, вместо него идиоматично использовать императивный loop.
чё за иммутабельность я ньюфаг
Уничтожение Людей Икс
чо
Иммутабельность = Нет Мутантов
ААААААААААААААААААА
Вот это делирий портвешкового байтоговнарика.
Лабу на завтра хоть подготовил?
Рекурсию вообще во многих функциональных языках зазорно использовать, потому что даже с tail-call оптимизацией она все равно жрет больше других способов, которые доступны как альтернатива в 99% случаев, да еще и читаются/понимаются лучше.
Джон Кармак в свободное от окулуса время пишет на хаскеле.
Этот пост ложь. Никто не пишет на Хаскеле.
Ты инсталлятор у окулусов видел? Джон, блядь, Кармак. Это худший кусок говна, который я видел в своей жизни.
Кармак пишет на плюсах, в очень прямолинейном "геймдевовском" стиле работал в фейсбуке и видел его пул реквесты. Хотя пишет код он мало, и в основном ради своих экспериментов, в фейсбуке его держат в основном для пиара.
С хаскелем он немного поигрался в прошлом и забросил.
Скока зашибал в пейсбуке?
Что за хуйню ты несешь? Tail-call оптимизируется в сраный цикл с аккумулятором. cmp и je - хуле ты еще хочешь?
Около 200к в год должен был зарабатывать, мне там не понравилось и я свалил не проработав год
Неблохо. Сколько бы осталось после налогов и повседневных затрат? Сейчас зашибаешь больше? Европка или штаты? Собесы сложные были?
Оставалось бы тысяч 50-70 в год, в зависимости от трат. Сейчас зашибаю столько же, но работа куда приятнее. Штаты. Собесы уровня средних задач на литкоде и разговоров об опыте, прошлых проектах, "раскажите о сложной задаче".
Очередное доказательство, что маняфантазии фп-дебилов мало чего имеют с реальностью, ведь даже в своем языке (((ОНИ))) не разбираются.
Хуя, это в sf или другой штат? 200к звучит охуенно, а после расходов выходит как у меня в дс. А что по другим аспектам? Как люди, культура разработки, бытовые моменты? Что лучше, чем в дс, что хуже?
>Тогда почему язык R не хайповый?
Потому что это слабая и медленная хуета. Не говоря уже о том, что в нем нет даже устоявшегося синтаксиса.
R это часть той же современной парадигмы, как и иммутабельность в новых языках — попытка настолько опустить порог вхождения, что программеры будут не нужны (по крайней мере, не в таком количестве.). По этой же причине сейчас даже на самых НЕтехнических направлениях в универах учат прогу, чтобы любой специалист, независимо от образования, по дефолту мог мутить какие-то инструменты.
Не понятно только почему всякие джависты, си-бляди и крестанутые с этого подгорают. Если эта парадигма реально будет править, то с их работами как раз ничего не произойдёт, а возможно работы станет больше, как и денег на их стеках.
мимо социолог-крестовик из большой четверки.
> попытка настолько опустить порог вхождения, что программеры будут не нужны
Ну такое. По мне так R - не тот язык, на котором хомяки пишут. Всё-таки датасаянся это датасаянс.
> иммутабельность в новых языках
> новых
Функциональному программированию не меньше лет чем ООП, и оно не то что бы проще.
>попытка настолько опустить порог вхождения, что программеры будут не нужны
Вообще мимо кассы. Если раньше, в 70ых и 80ых в стране белых людей можно было 35 лет работать инженером с паяльником, а потом вкатиться в программинг, то сейчас ищат именно людей с призванием. Программирование стало основной деятельностью, а не одной из. И это не меняется.
> Если эта парадигма реально будет править, то с их работами как раз ничего не произойдёт
Из твоей предпосылки, с которой я не согласен, как раз следует что потеряют, ибо их работу вытеснят вместе с их ебучим стеком.
Да и с каких это пор крестовики с джавистами в одной корзине? Джава же язык без менеждмента памяти, а значит и без порога вхождения. Вот как в джаве аллокатор написать?
>в жабе нет мемори менеджемента
учи JVM штобы не быть баттхертом
Так в этом и суть, если конкретный код с рекурсией легко оптимизируется в цикл, то пиши его сразу циклом, тебе потом спасибо скажут, когда будут читать код.
>Джава же язык без менеждмента памяти, а значит и без порога вхождения. Вот как в джаве аллокатор написать?
Какой же ты даун. Надеюсь, ты никогда не прикоснешься к проектированию большого распределенного энтерпрайза. Такие как ты весь проект завалят.
ну да, в принципе, под андроид нужен был бы язычек типа бейсика или дельфи(паскаля)
чтобы не оче образованные кодеры (ничего такого обидного в этом не вижу) могли глепать прикладной софт
а котлин сложный язык для изучения
кстати, нуралиев сотоварищи, когда делали 1С, это понимали
именно поэтому они запилили тупо подобие русского бейсика, чтоби нихуя не было кроме циклов и условий, чтобы была тупая сборка ссылок и все
Есть такая философия, её конечно не услышишь в подкастах и конференциях, отсюда и подражателей то особо и нет. Но, в общем, есть профессиональные программисты, которые помимо кода мыслят шире и понимают что код ради кода не имеет смысла. Значение имеет только конечный продукт и как легко его потом сопровождать и продать. Трудно их назвать "не очень образованными".
Но в тоже время мы видим такие правильные языки как раст, скала, хаскель, на которых писать или сопровождать код невыносимо.
Так что это еще большой вопрос кто тут сильнее ограничен.
>такие уебанские языки как раст, скала, хаскель
Пофиксил, не благодари.
>котлин сложный язык
>нужен был бы язычек
>язычек
Да тебе, пидору тупому, и родной язык сложноват
Мобильной разработки хватило бы и python или js. Клепать 90% времени круды на статических языках, это как на самолете ездить в магазин.
>а котлин сложный язык для изучения
Забавное то, что чтобы писать на котлине надо знать бэкграунд джавы, но в тоже время сам котлин очень так не похож на ту джаву. Я хз как джунов учить, как им объяснять зачем они так поиздевались над конструкторами, почему вместо "static" теперь надо писать "companion object" и то, почему не лучший выбор юзать их любимый vs code.
Лол, за то что не знал какие-то тонкости джавы? Я на джаве ни дня не кодил.
DOD'ики так и не объяснили почему в 2к19 под текстовый редактор нужен 16 ГБ
В 2004 году комп перестал тянуть игры, стал программировать.
@
В 2019 комп перестал тянуть IDE, стал играть в игры.
Тому що безрукие жабаскриптодебилы с синдромом NIH запилили его на ебучем электроне, очевидно же.
А может кто кто-нибудь на примерах объяснить как иммутабельность упрощает многопоточность? И ещё что делать с постоянным выделением памяти ведь это такой удар по производительности получается?
Java подделки тормозят и жрут еще больше. кококо-статические типы, оптимизации кококо
Никак, нельзя просто взять и решить проблему потребности шаред данных. Либо ты ручками контролишь, либо костылями со своими плюсами и минусами.
>как иммутабельность упрощает многопоточность
бОльшая часть проблем в многопотоке - это когда два или более потока одновременно читают и меняют один и тот же стейт. Если у тебя функциональный язык и все иммутабельное, то такой проблемы в принципе не может быть(на самом деле не все иммутабельное, стейт разумеется есть, но для его использования надо совершать дополнительные телодвижения и обычно он по умолчанию залочен, то есть все изменения идут в виде реквестов и обрабатываются по порядку)
>И ещё что делать с постоянным выделением памяти
Это давно оптимизируется на уровне языка, объекты копируются не полностью, а по ссылкам, например если у тебя есть длинный массив [a, b, c...] и ты добавляешь туда [d | a, b, c...], то это второй массив просто хранит в себе ссылку на первый и доп. значение d. В языке с мутабельностью такого не сделать, потому что даже если ты сохраняешь ссылку, то объект по ссылке может в любой момент поменяться, а вот в функциональных - ссылайся не хочу.
>жопаскриптер пиздит на жавагоспод, которые программируют дольше, чем он на свете живет
Потому что это не текстовый редактор. Хочешь текстовый редактор? Вперёд, пиши свои маняпрожекты в блокноте, хуле. Что-что? Нет выделения синтаксиса? Хочешь посмотреть сорц функции из стандартной либы? Хочешь автозаполнение? Хочешь форматировать код кнопкой, а не руками? Так пиши скрипты под блокнот. Только потом не пизди, что у тебя блокнот открывает один файл больше часа.
Манятеории откуда-то из 90-х. Проще научиться писать иммутабельный код на нормальном языке, чем брать функциональный язык ради такой мелочи, как ключевое слово const.
Вообще основное достоинство того же хаскеля, это не иммутабельность и ленивость, а система типов.
В Emacs и Vim все это есть, только они при этом ещё и не тормозят.
мимо сышный бомжара
Если в емаксе всключить все, он начнет тормозить.
Редух твой умрёт скоро, потому что есть божественный Mobx, который позволяет написать тот же самый функционал намного проще, быстрее и понятнее. А редух со своей тонной бойлерпрейта идёт нахуй.
У меня все быстро идёт, и это при том что ноутбук старенький.
Значит не все включил. Или у нас разные пороги раздражения от латентности редактора.
Потому что джава сегодня это практически сетевая преблуда, где сама джава может прогреться. А не прогретая джава, тормозит. И удивительно что её выбрали для IDE.
Ну еще кривое программирование на жабе никто не отменял, где абстракция абстракцией погоняется
>В языке с мутабельностью такого не сделать
Односвязный список не сделать?
>В языке с мутабельностью
Ну в каком-нибудь js есть Object.freeze. И всё нормально.
А вот работать с vector'ами в haskell'е, это уже одно страдание.
>А вот работать с vector'ами в haskell'е, это уже одно страдание.
С чего это?
Покажи хотя бы кусок кода где ты с ними страдал
>того же хаскеля
Тут вроде речь идет о реальных продакшен-языках, а не гиммиках для выебонов.
Ну делай, только нахуя кусать локти и бороться с языком? ЖС - это кривой-косой, но ОО-язык в первую очередь. Разумеется там можно и нужно использовать элементы ФП(как и в любом ОО-языке и наоборот), но если пытаться писать на нем в фул-ФП стиле, то это контр-продуктивный долбоебизм.
>Тут вроде речь идет о реальных продакшен-языках, а не гиммиках для выебонов.
В этих языках и честной иммутабельности нет
Какая честность, наркоман, ты не в суде. Значение имеет только практичность.
https://lmgtfy.com/?q=haskell+mutable+vector+example
>только нахуя кусать локти и бороться с языком
Односвязный список - это не борьба с языком. А js просто из-за Object.freeze пример.
То есть фризить каждый объект и делать свою реализацию списков - это не борьба с языком? И это далеко не единственные вещи, которые тебе придется сделать, но все равно не приблизишься к уровню любого современного ФП-языка по удобству. Так что зачем? Никаких ощутимых плюсов в читабельность и размер кода это не дает(особенно если использовать манябиблиотеки и/или собранный на коленке API повсюду) Если пишешь в браузер без возможности выбрать язык, то там на асинхронность и мутабельность по большему счету поебать, базовые вещи есть и ладно. А если не в браузер, то нахуя ты используешь жс в принципе?
>То есть фризить каждый объект и делать свою реализацию списков - это не борьба с языком
На фоне монады ST - нет. И да, если в императивном языке есть нормально работающий const / final, то и фризить ничего не придётся.
>кусок кода где ты с ними страдал
>пук
Ясно
Извините пожалуйста, сейчас же метнуть искать n-летние хеллоу ворлды искать.
Зачем тебе в хеллоу ворлдах были односвязные списки?
В том то и дело, что нужны были мутабельные ram вектора
Хули на машинных кодах не пишешь сразу тогда, долбоеб. Само программирование это уже абстракция, и чем выше уровень тем лучше.
>тем лучше(нет)
Так хули не пишешь, если "(нет)"?
пишу что ты дебил
Подожди, ты действительно настолько даун, что думаешь, что при работе с иммутабельными структурами данные будут копироваться?
Есть такая порода людей, которая считает, что каждый, кто на что-то претендует, просто обязан хлебнуть говна. Например, "настоящий мужчина" обязан сходить в армию или отсидеть в тюрьме, ведь что тюрьма, что армия - школа жизни; "настоящий программист" обязан писать на крестах, жабе, ПХП или тому подобном, ведь сами они на нём писали, а кто не хапнул этого говна, тот и не программист вовсе. С одной стороны понять их можно - механизм примерно такой же как у дедовщины в уже упомянутой армии или прописки на малолетке ("меня опускали, теперь я буду опускать" - ну просто обучение и сделование паттерну, через пиздюли навязанному авторитетом, детская психика так устроена), с другой - сами они со временем так нихуя и не понимают, и любые попытки объяснить им, что все эти боль и унижения, через которые они прошли, в общем-то лишние, встречают у них агрессию и отрицание.
Выговорился? А теперь марш спать, завтра ведь крудики опять лепить на твоей любимой рельсе/фласке/очередном макака-фреймворке.
ФП языки не практичны. Const и персистентные структуры данных практичны.
>ФП языки не практичны
Нехило в лужу пернул.
>implying не копируются
хоть бы пруфнуть попробовал а то так даже неинтересно
Ну, в той же ржавчине просто переназначается указатель, если ты пишешь какое-нибудь
let s = String::new();
let mut s1 = s;
Теперь указатель 's' не сработает, а сработает только 's1'. А копирует структуру полностью только
let mut s1 = s.clone();
Смысл в том, что тому, кто будет это читать, будет сразу понятно, что 's' нигде не меняется, пока не станет 's1'. И можно не гадать, будет ли это тот же самый 's' после какого-нибудь
s.make_strange_shit_with_self();
Ну и да, забыл добавить, что вся эта иммутабельность бесплатная, потому что это тупо ограничение на уровне компилятора. То есть, ты можешь хоть все свои "let" переменные ебануть мутабельными, компилятор тебе просто варнинг выпишет, что их можно и не делать мутабельными; но если ты "let" без "mut" попытаешься изменить, то там уже ошибка, но не ошибка кода, а ошибка компилятора. Так что да, современные макаки от кодинга просто обленились, поэтому топят за иммутабельность. А так никакой разницы нет.
Давно такого уродливого синтаксиса не видел. Это новый стандарт крестов?
пашол нахуй
> синтаксис уёбищный
> лучше в 1С писать, там же вообще русские слова
> или в Brainfuck, там вообще божественный синтаксис
let mut public static void main<Result<<Box<T>. E>.unwrap()
Навернул говница
Твоя хуета не сконпелируется. Никак. Потому что после let mut требуется имя переменной. С тем же успехом я могу скорчить брейнлета и написать тебе, что запилить изначально константную переменную, а потом пустить её по const_cast в крестах — это нормально.
Result<box<optional<optional<optional<String>>>>
Вот только кресты тебе дадут ебануть UB таким образом, а ржавый уёбищный синтаксис идёт в коробке с языком, который пытается избавлться от UB вообще везде, пока кресты их плодят. В итоге запомнить один раз все эти спецификаторы и страшные дженерики-трейты-лайфтаймы-енамы проще, чем каждый раз ебать себе мозг вопросами "эта хуета UB или не UB?"
Раст прекрасен.
Макак не умеет в fmap, сразу язык виноват.
ОП, судя по посту, считает что копируется и не приводит никаких пруфов.
Посмотри код GHC, и принеси мне пример с копированием.
>чем человекочасы, потраченные на еблю с АрХиТеКтУрОй
Главный секрет ДоД, про который молчат проповедники - это то, что оно не совместимо с архитектурой. На ходовых языках просто удобные абстракции не построить под него. Единственный выход - кодить под задачу at hand массивами как диды на Фортране. Такой подход далеко не везде применим, но он единственный, который реально работает.
>ОП, судя по посту, считает что копируется и не приводит никаких пруфов.
У него какой-то jvm язык в ОП-посте. Там они, естественно, копируются тупо потому что value-типов не завезли.
Попался на кручок деплоя реакт гавна которое оказалось полностью поломано и нужно переписывать половину репы
А вы что делаете?
уже не вижу в какие трежы пишу
А вы что делаете?
уже не вижу в какие трежы пишу
бля 2 раза промахнулся
> Зато (((иммутабельность))) Типа трушность. При этом количество забагованнного говна только растет.
Ага, вот например код контроллера двигателя тойоты — 10K глобальных переменных, очевидно, никакой иммутабельности и прочих ненужных абстракций, сплошная байтоебля и ламповое изменение переменных как ты любишь.
Зато машина ускоряется, когда жмешь на тормоз.
http://www.safetyresearch.net/blog/articles/toyota-unintended-acceleration-and-big-bowl-%E2%80%9Cspaghetti%E2%80%9D-code
https://news.ycombinator.com/item?id=9643551
Очевидно она ускоряется только если тормоз жмёт гайдзин.
>что такое move semantics
Растодебилы настолько тупые, что в своем собственном языке не разбираются
Ебать, в каком месте там ошибка?
ого я что на /pol/ кукчана?
Ну было бы у них 1000 иммутабельных классов с лапшой и пауками, думаешь лучше бы было? Там явно проблема в организации процесса, а не в языке.
Да. Множество различных состояний программы меньше.
Очевидно, что проблема тут в глобальных переменных, а не иммутабельности.
А в тех классах еще по 1000 полей в каждом.
различных
Функциональщики не понимают, что стейт зачастую - это наилучшее и простейшее представление предметной области.
В итоге изобретают конструкции вида
new_yoba = f(old_yoba), всякие FRP и продьюсеры-консьюмеры, прячат их в монады и радуются, что у них стейта нету.
В итоге изобретают конструкции вида
new_yoba = f(old_yoba), всякие FRP и продьюсеры-консьюмеры, прячат их в монады и радуются, что у них стейта нету.
Суть функциональщины на практике не в том, что стейта нету совсем, а в том, что весь стейт изолирован и является исключением, а не правилом.
Ты считаешь, что от разбиения переменных на классы, количество состояний программы магически уменьшится?
>стейт является исключением, а не правилом
В программе без данных действительно все просто и понятно. Только бесполезно.
На иммутабельные? Как запустил, их состояние больше не меняется. И да, следить за состоянием, спратанным, в монадах таки проще.
Ну, простейший тебе пример.
Говно:
int x_length;
int@ x;
int y_length;
int@ y;
Получше:
struct array {
int length;
int@ data;
};
array x;
array y;
Совсем хорошо:
vector<pair<int, int>> points;
А разница в том, что классы можно сделать так, чтобы они автоматически следили за инвариантами в коде. В последнем случае чрезвычайно сложно сделать так, чтобы длина x и y не совпадала, а в первом вообще минное поле.
Данные и стейт это разные вещи
Галоперидол, принимаем не задерживаемся, галоперидол, пока горячий.
Охуел, чтоле сука?
С каких это пор такой код (на некотором абсрактном языке, поддерживающем TCO):
function addNat(x, y) {
if (y == Null) then return x
else return addNat(succ(x), pred(y))
}
читается и поддерживается хуже вот этого:
function addNat(x, y) {
while (y != Null) {
x := succ(x);
y := pred(y);
}
return x;
}
В первом случае ты прямо записал определение, во втором тебе приходится городить какую-то хуйню с присваиваниями и разворачивать цикл в уме, если надо отдебажить что-то более сложное.
Наркоман? Любой цикл как раз читается сверху вниз, а вот рекурсию надо разворачивать в уме. Как только она станет сложнее, чем в дегенеративном примере из книжки, то ты сразу охуеешь это поддерживать и разбирать.
>А разница в том, что классы можно сделать так, чтобы они автоматически следили за инвариантами в коде
А функции нельзя так сделать? В чем эта чрезвычайная сложность?
>Данные и стейт это разные вещи
И в чем разница? В твоем примере points - это данные или стейт?
В теории, это одно и то же, как адрес и значение ничем принципиальным не различаются. Но в ФП принято эти вещи различать. Стейт не изменяется, какие бы ты данные не ввёл, то есть, если ты вводишь тысячу различных инпутов, то если потом опять ввести идентичный первому инпут, то ты и выход получишь идентичный первому.
>Стейт не изменяется, какие бы ты данные не ввёл
То есть стейт - это какая-то константа?
Ну да. Вот эти вот функции, которые ты вызываешь на свой инпут — они и есть стейт. Что бы ты не ввёл, функция "прибавить_два" всегда прибавит два.
>Вот эти вот функции, которые ты вызываешь на свой инпут — они и есть стейт
Что тогда значит "изолировать стейт"?
Она вернёт X + 2. С Х ничего не происходит.
сука, я понял кто это - это борщехлеб из сикп треда!
Я узнал его по ебанутой аргументации превосходства ФП!
В ООП метод класса который прибавляет два тоже всегда прибавляет два.
Вот это охуеть, вот это прорыв.
Не ебу, не я же писал.
Да, вот только она тебе его вернёт в другую функцию или на выход. В итоге либо некст функция работает уже не с x, а с x+2, либо ты получаешь на выход x+2.
Ты же говорил, что стейт - это данные. Теперь стейт - это функции? Как в лиспе "код - это данные"?
Я не аргументирую за ФП, я просто рассказываю, как ФПшеры думают.
Ну, ебать, скажи мне, чем различаются команды для CPU и данные?
Тем, что данные нельзя исполнять, если у тебя не микроконтроллер без защиты памяти.
test
Со стейтом та же хуйня. Он не изменяется в функциональных языках, пока ты его не поменяешь извне, то есть, пока ты не впишешь какую-нибудь функцию в код. А твои императивные — это как раз такая штука без защиты памяти.
Чистая функциональщина гарантирует, что твой выход зависит только от входа. А вот в императивных какой-нибудь забытый указатель из другого потока может ВНЕЗАПНО изменить твой выход.
>пока ты не впишешь какую-нибудь функцию в код
А до этого функция где находится? Не в коде?
По Фон Нейману:
Лежит в памяти => однохуйственно
Читай внимательнее:
> Стейт не изменится пока ты не изменишь код: один поток никогда не изменит данные другого потока СЛУЧАЙНЫМ образом, да и неслучайным обычно не меняет.
> В императивных языках забытый указатель может ВНЕЗАПНО изменить данные в другом потоке и вообще где угодно.
>висячий указатель ряяя
В ФП надо в функциональной лапше разбираться, которая не гарантирует невозможность аналогичного обсера.
Есть нормальные аргументы?
Да, не гарантирует, но если ты обосрался в ФП, ты сразу видишь, в какой строчке; в императивном ты этого увидеть не можешь. Плюсы ФП иди сам гугли, тебе всякие статьи повываливаются про мультипоточность и обновление без остановки машины.
>обновление без остановки машины
Кто на такое кроме эрланга способен?
>А функции нельзя так сделать? В чем эта чрезвычайная сложность?
Я отвечал на вопрос "Ты считаешь, что от разбиения переменных на классы, количество состояний программы магически уменьшится?". Уменьшится, за счет того, что класс уменьшает количество степеней свободы.
>И в чем разница? В твоем примере points - это данные или стейт?
Учитывая какой вопрос я отвечал, points - это глобальные переменные, т.е. стейт.
А разница в том, что стейт ты меняешь, когда видишь оператор присваивания (не путать с инициализацией). Нет присваивания - стейт не меняется.
Java HotSpot
HotSwap
>>148648может пример кода покажешь или так и будешь баззвордами кидаться?
>Уменьшится, за счет того, что класс уменьшает количество степеней свободы.
С чего это? Почему у класса с 1000 полей будет меньше состояний, чем у 1000 переменных?
например, за счет того, что класс может не дать тебе менять ни одну из них
про инкапсуляцию ты не слыхал, поэтому и срешь тут тупым говном.
Интересно как GHC получается обгонять С если это тупое говно копирующее все строки)
>Ну и наконец в-третьих. Гигантский оверхед на создание памяти, аллокацию, отслеживание неактуальных ссылок.
Нет никакого оверхеда.
Если это простые переменные то это мизер памяти и стек. Зато хуйню в расчётах не сделаешь.
Делать все-всё иммутабельным конечно бессмысленно и глупо, а работает это особенно хорошо в случае параллельного доступа к объектам.
Нужно использовать то и тогда когда это разумно.
Немного необычный пример иммутабельности - двойная буферизация в графике.
Тут понятно зачем оно нужно?
>Так в этом и суть, если конкретный код с рекурсией легко оптимизируется в цикл, то пиши его сразу циклом, тебе потом спасибо скажут, когда будут читать код.
Он не в процедурный цикл оптимизируется.
Процедурный цикл по типу фор менее эффективен, не говоря уже о читабельности хтонической хуйни из вложенный циклов и аккумуляторов.
>класс может
Ну так и императивщина может. Инкапсуляция и сишке есть.
А если нет оптимизации tail-call'а? Передавать N аргументов в каждую итерацию рекурсии? Даже если они будут из одной буквы, это пиздец дохуя места занимает. А в озаloopленном виде это всё не в одну строчку и нормально читается.
Какая разница? Внутри ФП языков рекурсия почти всегда менее эффективна и читаема, чем аналог из (ФП) цикла и ее рекомендуется избегать, где можно. erlang/elixir/clojure в пример.
Ну clojure очень хороший пример JVM, а с эрлангом что? Поподробней
Какой оп дурачок, это нечто. Учёные, мол, насочиняли всякой ерунды, то ли дело программисты-практики.
В ходе развития функциональных языков вроде Lisp теоретики обсуждали преимущества чистых функций, иммутабельности и прочих ныне модных штук.
Параллельно в бородатые годы суровые байтослесари на Форте пришли к аналогичной идее, но не теоретически, а чисто из практики. Так называемые "тупые" слова - это конкатенативные аналоги чистых функций.
И теория, и практика пришла к одному и тому же. Фортер в 80-х годах бы сказал: вот я определяю несколько переменных, в которых хранится состояние, и определяю слова (читай - функции) для работы с ними; затем я определяю новые тупые слова для работы с ними, причём то, что они выдают на стек, зависит только от входных аргументов на стеке. Эти слова отлаживаются, убедиться в корректности их работы не трудно, их легко тестировать по-отдельности. Далее с помощью этих проблемно-ориентированных слов решается задача. Ничего не напоминает?
В ходе развития функциональных языков вроде Lisp теоретики обсуждали преимущества чистых функций, иммутабельности и прочих ныне модных штук.
Параллельно в бородатые годы суровые байтослесари на Форте пришли к аналогичной идее, но не теоретически, а чисто из практики. Так называемые "тупые" слова - это конкатенативные аналоги чистых функций.
И теория, и практика пришла к одному и тому же. Фортер в 80-х годах бы сказал: вот я определяю несколько переменных, в которых хранится состояние, и определяю слова (читай - функции) для работы с ними; затем я определяю новые тупые слова для работы с ними, причём то, что они выдают на стек, зависит только от входных аргументов на стеке. Эти слова отлаживаются, убедиться в корректности их работы не трудно, их легко тестировать по-отдельности. Далее с помощью этих проблемно-ориентированных слов решается задача. Ничего не напоминает?
ОП — тупой зумерок-смузихлёб, не осиливший функциональное программирование. Айсикью ниже трехзначного конфирмед. Пссссс на ОПа, окропил уринушкой.
К ФП-дебилам приопдинилприсоединиласьась аватаватаркасрка и зумер, которы сясчитаетитапт FORTH функциональным языком, но конкретных примеров кода где иммутаьельность и фп уделывает мутабельную императивку всё ещё не завезли.
Ты задницей по клавиатуре что ли юлозишь?
>которы сясчитаетитапт FORTH функциональным языком
Forth - не целиком функциональный язык в современном понимании, но на нём можно и нужно писать в функциональном стиле. Выглядит, правда, это очень странно, потому что у языка довольно низкий уровень.
>А если нет оптимизации tail-call'а
Тогда это не ФП.
Нахуя рекурсию разворачивать? Рекурсивная запись - это прямой перевод формулировки исходной задачи на целевой язык программирования, короче говоря, рекурсия декларативна. Если тебе надо разворачивать рекурсию, то ты делаешь что-то неправильно. А вот цикл - это последовательность действий с изменяемым состоянием, за которым надо постоянно глаз да глаз.
>Кто на такое кроме эрланга способен?
Эрланг тоже на такое не способен. Виртуальную машину останавливать действительно не надо, а вот дерево процессов очень даже надо, если обновление не является тривиальным.
>но на нём можно и нужно писать в функциональном стиле
Ебать вы кукаретики. На форте невозможно писать в функциональном стиле. Хотя бы потому, что через стек ты иммутабельную структуру не передашь, туда можно класть только инты и флоаты.
Форт, наоборот, максимум стейтфул фигня, переменные там используются очень часто, потому что с одним (тремя на самом деле) стеком ты далеко не уедешь. Плюс все переменные фактически глобальные, хотя есть и инкапсуляция, а в некоторых фортах - локальные переменные.
>А если нет оптимизации tail-call'а?
Тогда не делай рекурсию кроме случаев когда это действительно делает код наглядным и гарантированно не переполняет стек.
>Какая разница?
Еще раз, рекурсия разворачивается в джампы, она не разворачивается в процедурные циклы. Иногда это даёт измеримый прирост производительности.
А с внешней точки зрения, многие алгоритмы нагляднее и понятнее в рекурсивной форме. Это бессмысленно тут объяснять, нужно самому пробовать. В случае с процедурными циклами тебе нужно сохранять кучу мутабельных состояний.
Если ты никогда хоть немного сложные алгоритмы, вроде обхода дерева, не реализовывал, то попробуй челе.
>Внутри ФП языков рекурсия почти всегда менее эффективна и читаема
Что ты подразумеваешь под "чтение внутри ФП языка" ?
>JVM
Проклятая жвм мешает производить TCO, мешает оптимизировать рекурсию в цикл и вообще говна в жопу заливает? Расскажи, интересно.
>с эрлангом
HOF предпочтительнее рекурсий и даже быстрее(хоть и незначительно)
Интересные истории, но вам надо пойти поработать с этим на практике, а не цитировать манямир из учебника по CS в каждом посте. И я не спорю, манямир очень привлекательный и логичный, но разбивается, когда приходится писать/читать сложную рекурсивную функцию, которая обрабатывает реальную логику в приложении, а не доказанные заранее на бумажке математические алгоритмы.
Учебник по CS говорит несколько вещей
1. goto - плохо
2. tail call ничем не отличается от goto по выразительности
3. в ФП нужно комбинировать комбинаторы, чтобы голые tail call'ы никто не видел
Если человек не знает п. 3, он не знает именно теории
>в ФП нужно комбинировать комбинаторы, чтобы голые tail call'ы никто не видел
Отличный совет, только теперь TCO сломалась в 99% языков. Но зато теорию соблюли.
>Отличный совет, только теперь TCO сломалась в 99% языков
Щито
>но разбивается, когда приходится писать/читать сложную рекурсивную функцию, которая обрабатывает реальную логику в приложении
Так все же пишут рекурсивные функции в реальном мире?
И в чем проблема?
Лапшу из вложенных форов с мутабелными состояниями разделяемыми на всех уровнях вложенности проще читать\писать?
> не доказанные заранее на бумажке математические алгоритмы
В твоём реальном мире бизнес логику придумывают налёту? Я молчу про бизнес аналитиков там, не удосужившись убедиться в работе математических формул?
>Лапшу из вложенных форов с мутабелными состояниями
Лапша из вложенных форов будет выглядеть в сто раз хуже в виде аналогичной лапши из рекурсии. И никто не мешает тебе вынести вложенный фор в отдельную функцию.
>В твоём реальном мире бизнес логику придумывают налёту
В моем реальном мире бизнес логику, как и верность работы компьютерной программы доказать в математическом понимании нельзя, ее можно только протестировать(поставить эксперимент). А эксперименты как известно не могут доказать теорию, только ее опровергнуть.
>А эксперименты как известно не могут доказать теорию, только ее опровергнуть.
Этот парень шарит.
>А эксперименты как известно не могут доказать теорию, только ее опровергнуть.
Чушь спизданул. Эксперименты доказывают, или опровергают гипотезы. Теория - это доказанная экспериментом гипотеза.
Если весь твой код - это гипотеза, а не теория, то у меня для тебя плохие новости.
>Лапша из вложенных форов будет выглядеть в сто раз хуже в виде аналогичной лапши из рекурсии.
Анус ставишь?
>В моем реальном мире бизнес логику, как и верность работы компьютерной программы доказать в математическом понимании нельзя
Ты наверное не знаешь, но формулы которые ты кодишь делают умные дяди с учёными степенями которые, внезапно, доказывают их корректность по самым разным критериям.
Впрочем может конкретно тебя и не пускают к такой вот логике.
>верность работы компьютерной программы доказать в математическом понимании нельзя
Внезапно, можно, у тебя какой-то мир не реальный, а выдуманный. Есть для этого специальный инструменты, и даже специальные ЯП.
>А эксперименты как известно не могут доказать теорию, только ее опровергнуть.
Ты теперь уже просто чушь несёшь.
Я так понимаю твою позицию:
>программист = машинистка, и нечего мудрить, а кто мудрит тот манятеоретик очкастый
Я тебя правильно понимаю?
https://ru.wikipedia.org/wiki/Фальсифицируемость
Он это имеет ввиду.
Эксперимент не может доказать гипотезу, потому что эксперимент, как правило, покрывает относительно небольшое количество кейсов. Поэтому можно только провести эксперимент, сказать "ок, пока будем считать, что это так", если результаты подтверждают гипотезу, но в будущем, любой другой эксперимент, покрывающий другое множество кейсов, может теорию опровергнуть.
В программировании никто не доказывает корректность программы формально. Обычно тестируют программу (или ее часть) на небольшом множестве инпутов, проверяют эдж кейсы и говорят "ок, будем считать, что оно работает". При этом нет никаких гарантий, что это говно не упадет на инпуте, который мы не тестировали, нет, мы просто верим, что оно не упадет. Доказывать все подряд формально -- это аутизм, на который ни у кого нет ни денег, ни времени.
> программировании никто не доказывает корректность программы формально.
Хаскель, раст, инструменты для анализа С кода?
https://wiki.haskell.org/Haskell_in_industry
?
>мы просто верим, что оно не упадет
Дай Бог вас ИИ заменит скоро.
ИИ никогда не будет, потому что это будет программа настолько сложная, что все борщехлебы помрут от старости, пока будут доказывать ее корректность.
>Анус ставишь?
Это аналог возврата от структурного программирования к goto, с единственным отличием: явным прокидыванием изменяемого стейта.
>Ты наверное не знаешь, но формулы которые ты кодишь делают умные дяди с учёными степенями которые, внезапно, доказывают их корректность по самым разным критериям.
Эти дяди играются в песочнице на бюджетные деньги. Все эти доказательства не работают, потому что написание верификации на несколько порядков сложнее написания программы, и, что самое плохое, программа верификации - это тоже программа, она тоже подвержена ошибкам. Т.е. написав сложную программу, и дальше написав для нее верификатор, ты не можешь доказать корректность верификатора.
Намного эффективнее писать не программы, у которых ошибки отсутствуют, а программы, устойчивые к ошибкам.
>ИИ никогда не будет, потому что это будет программа настолько сложная, что тепловая смерть Вселенной наступит раньше, чем борщехлебы докажут корректность ИИ.
Фикс. Я не учел, что могут появиться новые борщехлебы.
>Эти дяди играются в песочнице на бюджетные деньги. Все эти доказательства не работают
С тобой все в порядке? Доказательство теоремы пифагора работает, или нет?
>Все эти доказательства не работают, потому что написание верификации на несколько порядков сложнее написания программы
Причем тут какие-то программы вообще?
Ты писал
>но разбивается, когда приходится писать/читать сложную рекурсивную функцию, которая обрабатывает реальную логику в приложении, а не доказанные заранее на бумажке математические алгоритм
То есть речь шла о логике, а не о коде, о логике которую код реализует.
Ты утверждал, что, логика эта выдумывается на лету, а не разрабатывается заранее. Мол нахуй скажем метод расчёта баллистической траектории, давайте как-то сами чисто интуитивно накодим? И мол это обычная практика.
>Намного эффективнее писать не программы, у которых ошибки отсутствуют, а программы, устойчивые к ошибкам.
Это просто громкое заявление не привязанное ни к чему.
Чем измеряется эффективность? Что такое "программы у которых отсутствуют ошибки", как измеряться устойчивость к ошибкам?
О чем ты вообще? Насколько мне известно, программ в которых гарантированно нет ошибок - не существует в природе.
Твои высказывания выглядят так, как будто они несут чисто эмоциональный характер.
Я пытаюсь тебя понять, но ничего не выходит.
Я повторю вопрос.
>программист = машинистка, и нечего мудрить, а кто мудрит тот манятеоретик очкастый
Ты это хочешь сказать?
>В программировании никто не доказывает корректность программы формально
Ну, это, положим, ты спизднул
В программировании сайтов-визиток - да, никто не доказывает.
В этой области никто даже не знает, что так можно было.
аваторкоживотное пытается обоссать императивку, но пока получается только себя.
В голос с твоих попуков. В 2к19 языки разрабатываются только с одной главной целью: ускорение и удешевление разработки.
Если с этими фичами код можно быстрее хуячить в продакшн — это сэкономленные миллиарды.
>Причем тут какие-то программы вообще?
Любое формальное математическое доказательство является программой. В том числе и теорема пифагора. Она, конечно, работает. Но теорема пифагора очень простая.
>То есть речь шла о логике, а не о коде, о логике которую код реализует.
В современных программах код и есть логика.
Индустрия пыталась ввести UML и прочую поебень, чтобы формализовать такие вещи как UI, базы данных, и прочую хуйню, но это оказалось мертворожденной корпоративной хуйней. Код первичен.
>Ты утверждал, что, логика эта выдумывается на лету, а не разрабатывается заранее. Мол нахуй скажем метод расчёта баллистической траектории, давайте как-то сами чисто интуитивно накодим?
Вот здесь ключевой момент твоего непонимания. Код расчета баллистической траектории - это 40-е и 60-е годы, это очень простой код, который можно написать даже на ассемблере с комментариями. Этот код пишут ученые, которые даже не являются профессиональными программистами.
Современные программы на несколько порядков сложнее математических расчетов, а формальное доказательство их корректности будет ЕЩЕ сложнее.
>Он это имеет ввиду.
Это вообще о другом.
>Эксперимент не может доказать гипотезу
Только эксперимент и может. Пикрелейтед в помощь.
>как правило, покрывает относительно небольшое количество кейсов
Есть такое понятие - границы применимости теории.
>Доказывать все подряд формально -- это аутизм, на который ни у кого нет ни денег, ни времени.
Это вопрос задачи, а не аутизм. Therac-25 вас так ничему и не научил.
>программист==машинистка
Нет, ты==борщехлеб
Следи за руками, разношу твои аргументы:
>в вебе не доказывают упадет магазин или нет
Потому что им это нахуй не упало, как и во многих других областях, дебилушка ниишная, изучил матлогику на первом курсе, а за лабы на паскале получил двойку?
Сам мат. аппарат основан на физическом мире, а не наоборот.
Логическое выражение основывается на первоначальном наборе аксиом, которые выбирает человек.
И чем ты будешь доказывать обосрался он с выбором или нет?
https://www.sscc.edu/home/jdavidso/math/goedel.html
Математика это инструмент, а не предмет для надрачивания.
>На форте невозможно писать в функциональном стиле
Частично и с оговорками возможно, хотя понятно, что это не чистый функциональный язык.
>Хотя бы потому, что через стек ты иммутабельную структуру не передашь, туда можно класть только инты и флоаты.
Зачем тащить всю структуру, когда можно положить указатель на неё? Вся работа по изменению этой структуры изолируется в наборе простых функций. После того, как они протестированы, можно писать набор по возможности чистых функций для работы со структурой данных через этот набор слов. Этот подход ближе к ФП, чем к ООП.
>Плюс все переменные фактически глобальные
Потому что они по факту ничем не отличаются от прочих слов. Грубо говоря, это некие грязные функции, в которых изолируется состояние вне стека.
>не чистый функциональный язык.
Форт, вообще-то, самый императивный язык из всех: положи на стек, достань со стека, что-то сделай.
Therac-25 как раз научил тому, что нужна устойчивая к ошибкам система, а не безошибочная. Независимый дозиметр с watchdog'ом позволил бы решить все проблемы с этой системой.
Прикол в том, что в therac-20 такая вещь была, а в therac-25 удешивили систему и понадеялись на формальные проверки, за которые ты топишь.
>Независимый дозиметр с watchdog'ом позволил бы решить все проблемы с этой системой.
Интересно как, если система считает, что оператор "сознательно" ввел соответствующую дозу, доза облучения зависят от решения врача, и никакими дозиметрами ты этого не ограничишь.
>и понадеялись на формальные проверки, за которые ты топишь.
Не было там формальных проверок. Там была единственная проверка за которую ты топишь: раз не падает на тестах, значит работает. До первого фатального случая аппараты в сумме наработали десятки тысяч процедур.
>которые программируют дольше
И хуевее
Нахуй ты кормишь дебила?
>Интересно как, если система считает, что оператор "сознательно" ввел соответствующую дозу, доза облучения зависят от решения врача, и никакими дозиметрами ты этого не ограничишь.
А почему она так считает? Потому что ты ее так спроектировал? Ну вот поэтому проектирование подобной системы тебе никто не доверит.
Не в строить в собственный код защиту от дурака, потому что пользователь - врач с корочкой, это как раз что-то уровня therac-25. При том, что therac-20 нормально работал с тем же самым кодом:
Врач из Чикаго Фрэнк Борджер, узнав про ошибку Therac-25, решил выяснить, возможно ли такое на его Therac-20. Ошибку повторить не удалось, но позже обнаружилась связь. Когда новая группа студентов начинала практику на Therac-20, часто срабатывали предохранители-автоматы. Это повторялось в течение трёх недель, но потом практически прекращалось — до следующей группы. Новички часто используют нестандартные способы ввода информации — это значит, что при определённой последовательности, введённой с клавиатуры, случается аварийная ситуация. До переоблучения она не развивалась лишь потому, что в Therac-20 стоял аппаратный блокиратор.
>Не было там формальных проверок.
Были. Просто ты веришь в учоных, с корочкой, которые просмотрят код, выпустят отчет на 500 страниц, и все заебись, а на деле учоные такие же долбоебы, как и любые люди, и совершили ошибки при проверке исходного кода. Хотя даже блок-схемы нарисовали.
>Были.
Не было. Разработчики проигнорировали все что можно, в том числе и формальную верификацию, понадеявшись на либы от Therac 20, в котором стояла аппаратная защита, а ошибки при эксплуатации списывались на аппаратные проблемы. Хотя на самом деле это были ошибки ПО (как потом путем экспериментов и выяснилось).
При формальной проверке невозможны ситуации с переполнением при сложении, деление на ноль итд. А именно эти ошибки привели к печальным последствиям.
>В программировании сайтов-визиток - да, никто не доказывает.
Началось кидание в крайности, будто между визитками и ПО для самолетов (где действительно требуется высокая надежность софта, а поэтому верификация оправдана) ничего не существует.
>В этой области никто даже не знает, что так можно было.
Все всё прекрасно знают. Борщехлебы почему то думают, что они знают тайны Вселенной, которые доступны лишь Избранным, хотя это не так.
>Только эксперимент и может. Пикрелейтед в помощь.
Твой пикрилейтед никак не противоречит моим словам вообще.
>Есть такое понятие - границы применимости теории.
Даже в "границах применимости" можно найти кейс, не покрытый экспериментом, какие бы границы применимости ты ни придумывал. Вот сейчас работает механика Ньютона, а завтра в одном из экспериментов она работать не будет и Ньютон соснет хуйца. Так в общем то было уже один раз, просто тогда сказали, что на малых скоростях все работает. Но нет никаких гарантий, что потом что-то во Вселенной не наебнется и механика Ньютона не будет работать даже на малых скоростях, и никакие границы применимости уже не помогут.
>При формальной проверке невозможны ситуации с переполнением при сложении, деление на ноль итд
При условии, что в формальной проверке нет ошибок. А этого ты для достаточно сложной программы гарантировать не можешь.
>Теория - это доказанная экспериментом гипотеза.
>теория
>доказанная
Студентик матфака попался на незнании базовых вещей. Ладно вы не знаете о научном методе, но хотя бы определение теории можно было загуглить.
>Внезапно, можно, у тебя какой-то мир не реальный, а выдуманный.
Рассказывай, каким образом ты будешь доказывать правильность программы. Напишешь на бумажке алгоритм и докажешь математикой? Но потом придется этот алгоритм переводить в инструкции для реального компьютера, как ты докажешь, что инструкции работают как надо? Еще больше бумажек испишешь? Или подключишь туда другую программу, которая проверяет первую? Но тут мы уже полный круг прошли. Факт в том, что программирование - это эмпирическая наука, а не математика. И доказать в науке ничего нельзя, можно только поставить эксперимент и сформулировать на его основе теорию, которая будет описывать результаты данного эксперимента. Для программирования эксперимент - это тест, а теория - сам код программы.
В математике тоже не все можно доказать, потому что Гёдель.
Раст и C мимо. В расте даже один unsafe блок может тебя в жопу выебать. А программы на C вообще полностью unsafe. Все эти анализаторы хорошо показывают наличие багов, но отвратительно доказывают их отсутствие.
В математике доказательства возможны в принципе, этим она и отличается от обычных наук.
Ну хорошо.
Математика -не наука, если что
Штаны постирай.
>в математике не все можно доказать
>в математике можно доказать
Жопочтец итт
>Любое формальное математическое доказательство является программой.
Ты несёшь чушь.
>В современных программах код и есть логика.
Страшную чушь.
>Вот здесь ключевой момент твоего непонимания.
Ты на простой вопрос ответить можешь? Я тебе его 2раза задал. Ты не понимаешь сути моего вопроса?
>Код расчета баллистической траектории - это 40-е и 60-е годы
17того века надеюсь?
>Этот код пишут ученые, которые даже не являются профессиональными программистами.
Это бессмысленный набор слов. Тебе ок 15 лет? Где эти учёные, зачем они этот код пишут, что значит ДАЖЕ не являются?
Это как сказать:
>эти чертежи рисуют архитекторы, они даже не являются профессиональными крановщиками
Что у тебя в голове за мрак такой страшный.
>Современные программы на несколько порядков сложнее математических расчетов,
В чем отличие программы от математических расчётов и чем ты измеряешь сложность?
>Следи за руками
Цирк шапито уехал вон туда ->
>разношу твои аргументы:
>>в вебе не доказывают упадет магазин или нет
Ты не меня цитируешь, прими срочно галопередон.
>Нет, ты==борщехлеб
Ну как скажешь. Как там кстати в 2007? Мемы еще не протухли?
У нас тут в преддверье 2020 всякая функциональщина и иммутабильность даже в джаву вошла, даже в сишарп, даже в небо.
Вон знакомая макачит на автоматизированном тестировании, так там мать его груви какой-то, замыкание на замыкании, предикаты и операторы фильтрации коллекций. Я от офигел пытаясь в этой жути разобраться.
Функциональщина разве что в Си еще не залезла(С++ то давно уже ту-ту), хотя надо бы проверить на всякий случай.
Так что мы тут все в 2019 борщехлебы, кроме разве что гоферов, вот это тру олдскул пацаны.
>Рассказывай, каким образом ты будешь доказывать правильность программы. Напишешь на бумажке алгоритм и докажешь математикой? Но потом придется этот алгоритм переводить в инструкции для реального компьютера, как ты докажешь, что инструкции работают как надо?
Так, ты очевидно о всяких хаскелях не знаешь даже понаслышке. Я в этом не эксперт, так что объяснить что-то врядли смогу, тебе лучше погуглить то как работает хаскель, какие гарантии и какими средствами он предоставляет, и какая теория за этим стоит.
Там впрочем, насколько мне известно, есть несколько разных подходов к доказательству корректности программного кода.
Самое очевидное, что приходит в голову, это выработать набор условий, нарушение которых будет говорить о некорректно составленной программе, а соблюдение о некой корректности в рамках описанных этими условиями. Ну это как мне кажется. Предлагаю ознакомиться с теорией, и тогда у нас получиться интересный разговор, ты мне сообщишь что-то новое, а я поделюсь своим ценным мнением.
А, и да, выражение
>в математическом понимании
Лишено всякого смысла, анон что это пишет - идиот. Нет никакого "математического понимания" математика это инструмент для описания чего-либо, в ней может быть все что угодно. Математических теорий сотни тысяч, если не миллионы.
Тот анон видимо под математикой понимает школьную математику, дебил короче.
Да без разницы насколько хорошо они это делают. Важно что делают как-то, причём выхлоп от этого достаточен для того чтобы в этом инвестировали миллионы человекочасов и баксов.
>выработать набор условий, нарушение которых будет говорить о некорректно составленной программе
Это не доказательство корректности, это тестирование или дебаг, но не доказательство. Как написал анон:
>Все эти анализаторы хорошо показывают наличие багов, но отвратительно доказывают их отсутствие.
Из того, что вы выработали набор условий и программа этим условиям соответствует, никак не следует то, что программа верна, поэтому что один из кейсов вы можете просто по недосмотру не покрыть. Доказательство подразумевает, что вам вообще не придется придумывать какие-то условия, ловить баги и т.д., т.к. корректность программы будет следовать логически.
>Нет никакого "математического понимания"
Есть общая математическая культура, в которую входит понимание того, что такое доказательство. У обывателей (в частности, у некоторых программистов) этого понимания нет, для них доказательство это что угодно, тестики работают -- уже доказательство корректности, пипи-пупу уга-буга.
Доказательство корректности подразумевает, что у вас есть специально обученные борщехлебы, которые будут сидеть и с помощью прувера доказывать корректность.
>Важно что делают как-то, причём выхлоп от этого достаточен для того чтобы в этом инвестировали миллионы человекочасов и баксов
На порядки больше инвестируют человекочасов и баксов в тестирование и отладку, придумывания разных методологий типа TDD, в разработку инструментов для тестирования и отладки. Доказательство подразумевает, что вам ничего не придется тестировать и отлаживать. Иначе это не доказательство.
>о всяких хаскелях
>Я в этом не эксперт
>Ну это как мне кажется
>Предлагаю ознакомиться с теорией
Ну понятно дело, ты дебил без понимания базовых вещей, а не эксперт. И еще какого-то хуя мнение имеешь, не стесняясь признавать, что ничего не знаешь по сути? Еще раз - невозможность доказательства теорий - это неотъемлемый элемент науки, изучающей реальный мир. Computer science, внезапно, является как раз такой наукой, потому что программы крутятся в этом самом мире, а не в твоей голове.
>Ты несёшь чушь.
Если ты что-то не понимаешь, есть высокая вероятность, что это ты тупой, а не кто-то несет чушь. То, что формальные доказательства - это вычисления, называется изоморфизмом Карри-Говарда, и в среде борщехлебов это истина настолько банальная, что не знать ее и при этом быть апологетом ФП и рассуждать о доказательствах в хаскеле - это полный пиздец.
И вот как с тобой общаться, если ты в очередной раз проявляешь свою сущность шизика? Алло, ты не самый умный и компетентный здесь, и если какой-то текст тебе кажется абракадаброй, то это потому что ты ньюфаг в окружении серьезных дядек. Веди себя соответствующе. Тогда, возможно, ты будешь получать из общения новые знания, а не ощущение того, что ты вышел из спора победителем, потому что оставил за собой последнее слово. Это просто либо красная, либо синяя таблетка. Либо вежливое общение, либо с тобой будут общаться, как с вечно правым и увереным, что вокруг него одни школьники, шизиком. За сим иди нахуй, общаться со школотроном, про "мрак в голове" ДВУМ людям - неинтересно.
А есть морфизм Попенгольца-Хуешмульцера?
Ради тебя, няша, я переоденусь даже в халат японского нечеткого профессора
Это фишка конкатенативных языков: в них последовательное указание имён функций чётко отражает ход реальных вычислений. Этакое низкоуровневое ФП. Заманчивая была идея: использовать преимущества ФП на низком уровне с высокой производительностью. Жаль, на это почти забили.
>мам смотри я шучу про галю!!
>в жабе, сишарпе и даже небе добавили фп
>все жрут говно значит и ты жри
>Я в этом не эксперт
Соответственно попрошу завалить ебальник
>При условии, что в формальной проверке нет ошибок. А этого ты для достаточно сложной программы гарантировать не можешь.
Любая достаточно сложная программа декомпозируется на тривиальные подпрограммы, корректность которых легко доказывается. Из этих корректных тривиальных подпрограмм составляются новые тривиальные подпрограммы, корректность которых так же легко доказывается. И так до самого верхнего уровня, где у тебя написано что-то типа тривиального Application.Run(Config, IO, InitState).
Опять же разговор не о том, что что-то можно пропустить при проверке - при любой проверке: формальной, в тестах, в хардварных ограничителях и во всем остальном можно допустить ошибку. А важно то, насколько можно снизить вероятность возникновения ошибки. При применении формальных методов ошибки встречаются реже, чем при применении тестов и прочих методах. Тестами все случаи входных-выходных значений покрыть невозможно, если их бесконечное количество. А математическое доказательство работает для таких случаев.
>Студентик матфака попался на незнании базовых вещей. Ладно вы не знаете о научном методе, но хотя бы определение теории можно было загуглить.
Цитата из загугленной википедии:
>Теории предшествует гипотеза, получившая воспроизводимое подтверждение.
Что из этого противоречит моим словам?
>И доказать в науке ничего нельзя, можно только поставить эксперимент и сформулировать на его основе теорию, которая будет описывать результаты данного эксперимента.
Вот как раз ты и попался на незнании базовых вещей.
Сначала формулируется гипотеза, затем придумывается эксперимент для её проверки, после чего гипотеза либо выкидывается на свалку, либо превращается в теорию.
>невозможность доказательства теорий - это неотъемлемый элемент науки
Совсем поехал? Теория на то и теория, что её уже не надо доказывать. Она подтверждена экспериментально, в отличие от гипотез. Из теории могут вылезать следствия, которые либо подтверждают её, либо накладывают на неё ограничения при экспериментальной проверке.
Кажется, что ты пытаешься говорить о критерии Поппера, но нихуя не понял в чем его смысл.
Если что-то выглядит как последовательность инструкций и работает как последовательность инструкций, то это и есть последовательность инструкций, что не есть ФП.
>Вот сейчас работает механика Ньютона, а завтра в одном из экспериментов она работать не будет и Ньютон соснет хуйца.
Полная чушь. Эксперимент, поставленный в рамках классической механики, не может ей противоречить, а все потому, что классическая механика - уже давно частный случай более общей теории. Вот у более общих теорий пока точные границы неизвестны, но есть следствия, которые кажутся противоречащими известным фактам, но пока недоступные для экспериментальной проверки.
>Любая достаточно сложная программа декомпозируется на тривиальные подпрограммы, корректность которых легко доказывается
ПОСОНЫ!!!
ВЕСЬ ПРОЕКТ НАДО СНАЧАЛА ДОКАЗАТЬ!!!
ВДРУГ ЧО!
РАЗБИТЬ НА ФУНКЦИИ И ДОКАЗАТЬ ЧТО 2 + 2 = 4!!!!
ПОТОМУ ЧТО ВДРУГ НЕ РАВНО
БОГ ПОСМЕЯЛСЯ И ТЕПЕРЬ 2 + 2 = 5
РАЗРАБОТЧИКИ ОТУПЕЛИ И ПОТЕРЯЛИ ЗРЕНИЕ
НЕ ВЕРЬТЕ СЕБЕ!!!!
ДОКАЗЫВАЙТЕ ВСЕ!!!
СОБИРАЙТЕ КОЛЛЕГИЮ УЧЕНЫХ ЧТОБЫ ДОКАЗАТЬ СВОЙ КОД!!!!
ДОКАЗАТЕЛЬСТВА!!! ГРАНТЫ!!! ПОПИЛ!!!
i = 5;
i = ++i + ++i;
## TEST SNOULD WORKS!!
print(i == 13);
Довай, без доказательства корректности, а с одним тока тестом это в прод это выпусти.
>Теория на то и теория, что её уже не надо доказывать
Кому не надо? Тебе лично не надо? Или все люди в мире собрались и сказали "да нахуй нам доказывать, давайте просто потусим"? Теорию доказать невозможно.
>Она подтверждена экспериментально
Подтверждение = доказательство, так и запишем.
>Любая достаточно сложная программа декомпозируется на тривиальные подпрограммы, корректность которых легко доказывается
Ну вот возьмем простую программу: вычисление md5 хэша. Как ты докажешь ее корректность?
>Если что-то выглядит как последовательность инструкций и работает как последовательность инструкций, то это и есть последовательность инструкций, что не есть ФП
Последовательность инструкций - это последовательность вызова функций. Ты сейчас пиздишь на языки вроде Joy, функциональная природа которых ясно доказана и обоснована. Функциональный язык можно построить и не на лямбда-исчислении.
Дай определение функциональному языку, пожалуйста.
Функциональный язык - это язык, программы на котором задаются:
1) применением функций к их аргументам в определённой взаимосвязи, причём в качестве аргумента могут выступать как результаты применения функций, так и другие функции (аппликативный подход)
2) применением функций к неявно заданным аргументам, технически находящимся (упакованным, если угодно) в некой общей подразумеваемой структуре данных, причём конкатенация функций выражает их композицию (конкатенативный подход)
Пишу строго от балды первое пришедшее в голову без всякой строгости формулировок.
Забыл добавить.
А так как в конкатенативном язык аргументы явно не указываются и функции применяются к некой общей структуре данных, то последовательность записей функций (слов) отражает реальную последовательность их выполнения на компьютере. Отсюда удобство и эффективность реализации, но трудности с распараллеливанием. Всратый вид программ уже научились фиксить.
Всё, теперь ссы.
Тогда ассемблер конкатенативный функциональный язык, у которого структура данных - озу
>Во-вторых, даже архитектура ПК построена на RANDOM ACCESS MEMORY. То есть наши отцы-основатели, в отличие от (((них))), которые теперь паразитируют на отрасли, предпочитали ПРОИЗВОЛЬНЫЙ ДОСТУП К ОБЪЕКТАМ В ПАМЯТИ.
Проиграл. Деды основатели предпочитали иммьютабельные перфокарты. Шах и мат!
Ебать ты в теме шаришь.
Ну расскажи, как "функции" je или mov cx, 10 применяются к оперативной памяти. Ты вообще понимаешь, что такое функция в математике?
Ну плюс регистры. Не суть.
Ещё как суть.
В конкатенативном языке параметры функций не указываются явно. В языке ассемблера ты обязан явно указать, что к чему. Как ты будешь неявно обращаться к random access memory? Превратить 8 гигабайт ОЗУ в один большой стек?
В конкатенативном языке новые функции описываются конкатенацией. Как ты думаешь, если я составлю "функцию" mov cmp, она будет корректной с точки зрения синтаксиса? Я молчу про то, будет ли это работать.
Так на дваче доказали, что язык ассемблера не является функциональным. Две премии Тьюринга в этот ИТТ тред.
Java - ФП язык по такому определению.
Обоснуй
Лямбды там есть, метод - это функция, что тебе еще обосновать?
>что тебе еще обосновать?
Только то, что ты утверждаешь, а именно: Java - ФЯП.
>Лямбды там есть
Конкатенативные ФЯ не основываются на лямбда-исчислении, от этого они не становятся менее функциональными. Да и лямбды в последнее время к чему только не приделывают, ждём их в Коболе, лол.
>метод - это функция
Хуюкция. Я с Java почти не знаком, там хоть есть функции высшего порядка? Дело не в том, как что называется, а в том, как это работает. Охуенный ФЯ, в котором оператор присваивания на каждом шагу, ага.
Ты чего порвался? В твоем определении не было никаких функций высшего порядка да, прикинь, map filter reduce там есть, вот это неожиданность и то, что лямбдами нищитово, и про оператор присваивания ничего. По твоему определению выше, Java - ФП язык.
>Конкатенативные ФЯ
Следовательно есть и не конкатенативные, если это надо указывать.
>В твоем определении не было никаких функций высшего порядка
>причём в качестве аргумента могут выступать как результаты применения функций, так и другие функции
Рекомендую повернуться к монитору лицом.
>и про оператор присваивания ничего
И про стек ничего, и про каррирование ничего, и про комбинаторы тоже, представь себе, ничего.
В чистом аппликативном функциональном языке состояние программы хранится в аргументах функций. В чистом конкатенативном функциональном языке состояние программы хранится в общей структуре данных. А теперь вопрос: где хранится состояние в Java-программе?
Язык называется таким-то и таким-то не потому, что в нём есть такие-то фишки, прилепленные сбоку, а потому, что у него есть основа с той или иной сутью. Функции в математическом смысле можно писать и в древнем Фортране. Haskell - это аппликативный язык, хотя конкатенации в нём хоть жопой жуй. Kitten - конкатенативный язык, в котором есть и явные переменные, и инфиксная запись. Так как определить, какой язык к какому типу относится? Просто тыкая в некие признаки наобум? Нет, путём анализа того, какие штуки реализуются через какие механизмы.
Я могу использовать неизменяемые переменные в Java, но тем же механизмом (оператором присваивания) могу по сто раз менять их значение. Я могу написать чистейшую функцию, а могу точно так же написать грязный код. А в Haskell не могу.
>чистом аппликативном функциональном языке
Виляние жопой: вопрос был про ФП, а не чистый аппликативный ФП.
-й
Ты в любом случае получил ответ. Java - это не чистый или не чистый ФЯ, это вообще не ФЯ. Функциональные фичи налеплены поверх, а абстракции текут.
Вычитал тут умное, спасибо гуглу:
https://habr.com/ru/post/421839/
"Для начала, давайте убедимся, что java stream — не функциональная структура данных. Проверим структуру на изменяемость. Для этого создадим такой небольшой стрим:
IntStream standardStream = IntStream.range(1, 10);
Сделаем перебор всех элементов в стриме:
standardStream.forEach(System.out::print);
В ответ получаем вывод в консоль: 123456789. Давайте повторим операцию перебора:
standardStream.forEach(System.out::print);
Упс, произошла такая ошибка:
java.lang.IllegalStateException: stream has already been operated upon or closed
Дело в том, что стандартные стримы — это просто некоторая абстракция над итератором. Хоть стримы внешне и кажутся крайне независимыми и мощными, но минусы итераторов никуда не делись."
Замечательный ФЯ, дайте два.
>Так как определить, какой язык к какому типу относится
Гораздо проще - надо посмотреть, какие программы на этом языке обычно пишут. Если там принято писать функциональные программы, то язык можно назвать функциональным. Если OO программы, то объектно-ориентированным. Только один подъеб, что и функциональщину, и ОО, и процедурную залупу можно комбинировать друг с другом и реализовать кучей разных способов, они никак друг друга не исключают. Ты попытался это сказать, но подобосрался на определении функциональной программы, так что давай заново.
Сперва надо определить, что к чему привешано: хвост к собаке или собака к хвосту.
Язык называют функциональным не потому, что люди пишут на нём функциональные программы. Люди пишут на нём функциональные программы потому, что это функциональный язык и его механизмы подходят для этого лучше всего. Обычно люди всё-таки предпочитают не одевать штаны через голову.
>Люди пишут на нём функциональные программы потому, что это функциональный язык и его механизмы подходят для этого лучше всего
Одно слово для тебя - javascript.
Бэкус хорошо заметил, что оператор присваивания в фон неймовских языках как бы расщепляет программирование на два мира: слева и справа от него. Правая часть нередко очень математична и чиста, в последние десятилетия на неё навесили очень много фишек из функционального программирования, что видно в javascript. Да и в древнем Фортране-IV можно было записывать в правой части чистейшую математику. Проблема в том, что есть ещё и левая часть, она никуда не делась.
Поэтому javascript всего лишь императивный в основе язык с кучей фич из ООП и ФП, а Haskell - чистый ФЯ. В нём нет никакого левого мира.
/тхреад
>мам я троллю /pr/
Объясните почему этот малолетний дебил ещё не въебал мочи за такую хуйню в тематике.
В перфокарте можно пробить новую дырочку, или заклеить пластырем имеющуюся.
Да и файлик с исходным кодом тоже можно изменить после написания. Для пущей иммутабельности пусть вообще всё будет рид-онли, например, файловая система тех, кто продвигает иммутабельность, а то это лицемерие и двойные стандарты получаются. Непорядок!
Конкатенация в хаскеле? Ой вэй. В Хаскеле всегда аппликация.
Даже кусок кода "put 5 dup mult" не делает язык конкатенативным.
Забавно, что этот пост был проигнорен, потому что вторая половина десятых нам дала новую порцию борщехлебов: диванные борщехлебы. Если старые борщехлебы в принципе умели программировать хоть что-то, то здесь просто пиздеж ради пиздежа.
Алгоритм итеративный, значит доказывается по индукции. Че тут сложного-то?
Речь шла про доказательство корректности работы программы, а не алгоритма.
Сравниваешь алгоритм и код, попутно ищешь языкоспецифичный undefined behavior, что тут сложного?
есть две функции от одного аргумента, x и y. Определяем новую функцию: z = x y
Совершенно типичная для Хаскелля возможность определить новую функцию как композицию функций через конкатенацию их имён.
Опять же путаешь код и программу. Программа - это запущенный и крутящийся в компьютере код. Как ты докажешь, что она работает корректно?
В данном случае это аппликация, а не конкатенация.
Почему это не конкатенация? Определение функции в примере - это конкатенация, то есть буквально текстовая склейка двух имён функций без явного указания их аргумента. Другой вопрос, что в выражениях с этой функцией она будет разворачиваться в последовательность аппликаций, ну так Haskell и есть аппликативный, а не конкатенативный язык.
>Почему это не конкатенация?
Потому что это аппликация.
>то есть буквально текстовая склейка двух имён функций без явного указания их аргумента
В данном случае одна функция принимает другую функцию в качестве аргумента, а никакая не склейка имен.
Смиренно каюсь, спутал с x . y
Спасибо, анон.
Еще одна порция "блаблабла" от диванного борщехлеба. На этом, собственно, тред можно закрывать. Потому что спорить о терминах хвилосовы могут бесконечно, а вне споров о терминах - сплошное пуканье.
>Любая достаточно сложная программа декомпозируется на тривиальные подпрограммы, корректность которых легко доказывается.
В абсолютно чистом ФП -- может быть и декомпозируется, факт в том, что в чистом ФП никто не пишет, и поведение "тривиальных" подпрограмм зависит от состояния других "тривиальных" подпрограмм. В результате проблема верификации большой программы не разбивается на проблемы верификации маленьких подпрограмм.
>Эксперимент, поставленный в рамках классической механики, не может ей противоречить
Может, если релятивистская механика наебнется вместе с классической, а физики в очередной раз натянуть сову на глобус и придумать более общую теорию не смогут. Эксперименты не могут доказать теорию в принципе, они только опровергают ее. Если теория опровергнута, пилят новую теорию, которая учитывает новые экспериментальные данные (так было с классической механикой, на смену которой пришла релятивистская, и так было с теорией Дарвина, на смену которой пришла Синтетическая теория эволюции). Если бы эксперименты доказывали теорию, новых теорий не появлялось бы, потому что ты не можешь опровергнуть уже доказанный факт, это нонсенс. Тогда не появилось бы той же самой релятивистской механики, ноука же доказала, что Ньютон прав.
Доказательства бывают только в математике, в науке их нет.
Ты либо тупой, либо тролль, либо тупой тролль.
Во-первых, про твою теорию "всеобщего наебения". Если завтра внезапно перестанет работать гравитация, то тебя мгноенно распылит на атомы или кварки, поэтому нет никакого ПРАКТИЧЕСКОГО смысла в том, чтобы задаваться вопросом "а что, если завтра внезапно перестанет работать гравитация?" То есть, в разрезе ЧЕЛОВЕЧЕСТВА, гравитационные силы будут существовать всегда. Может быть, их определение как-то расширят, может переформулируют, но австралийцы не начнут внезапно падать с Земли.
Во-вторых, про твоё "нет чистого ФП". Скажем, есть у нас некий
struct Qwe { private: int one_to_hundred }
И из всех функций доступ к изменению имеет только одна:
new(int new_qwe) { ... }
в теле которой всего пара строчек:
if (new_qwe >= 1 && new_qwe <= 100) { one_to_hundred = new_qwe}
else { call_the_police("nigger tries to give me da wrong numba!" }
И пока ни одна другая функция этой структуры не имеет доступа к переменной one_to_hundred, эта переменная изменяется в только в случаях, вроде отключившейся гравитации: когда диск ёбнулся, когда что-то сверху программы (операционная система, например) поменяло эту переменную и в других похожих. Да, тогда даже такая структура может ёбнуться, но не имеет никакого ПРАКТИЧЕСКОГО смысла такое предполагать. А когда ты хочешь дальше поверх этой структуры что-то сделать, то ты пишешь новую:
struct Ewq { Qwe qwe, int ewq }
и тогда программа разбивается на тривиальные подпрограммы. Да, это дерьмо требует неебического количества лишних операций, но прошедшая через такое доказательство программа ломается только в том случае, которые никак не интересуют нормальных людей, потому что нормальные люди не суют вилку себе в глаз, надеясь, что там ничего не сломается.
>либо тупой тролль
Не просто тупой тролль, но еще и двощер.
Это как выиграть в 3 лотереи сразу.
>МАААМ СКАЖИ ИМ МАААМ У МИНЯ НЕ БОМБИИИТ
>Я МОДЕРАТОРУ ПОЖАЛУСЬ! ЗАБАНЬТЕ ИГО!11111
Но ведь самый тупой ИТТ ты
А там разве говорится, что ты самый тупой?
Опять ебаный третьекурсник порвался на простыню, при этом так и не удосужившись понять основы. Еще раз, дебил ебаный, программирование - это не математика, в своей башке и на бумаге ты можешь придумать хоть какой чистый ФП язык и доказывать на нем любые программы(потому что сам и задаешь начальные аксиомы для этих доказательств, прямо как в математике). Но как только ты напишешь эту программу в реальном мире и запустишь на реальном процессоре, она тут же перестанет быть чисто ФПшной и доказуемой. Остальной твой бабах смысла не имеет.
>Если завтра внезапно перестанет работать гравитация, то тебя мгноенно распылит на атомы или кварки
Это подмена тезиса, я не говорил, что должна перестать работать гравитация. Если завтра поставят опыт, по расчетам которого выйдет, что ускорение свободного падения не 9.8, а 9.7, и этот опыт повторяем, то теория все равно наебнется, для этого выключение гравитации не потребуется.
>поэтому нет никакого ПРАКТИЧЕСКОГО смысла в том, чтобы задаваться вопросом
В нем действительно нет практического смысла, в этом я с тобой согласен. Это мысленный эксперимент, который я поставил, чтобы показать, что научную теорию невозможно доказать в принципе. Математическую -- можно, научную -- нет.
>Может быть, их определение как-то расширят, может переформулируют
Не обязательно. Может все поменяться в любой момент таким образом, что человечество не погибнет, но при этом ученые нихуя не смогут объяснить. Твой оптимизм относительно ноуки не основан ни на чем.
Ниже ты вообще какой-то шизоидный бред написал, который к дискуссии не имеет отношения. Как ты собираешься декомпозировать программы в том же Си, где нахуй прямой доступ к памяти, и любая хуйня может поменять любую хуйню в любой момент?-
То есть, по-твоему, логику процессора пишут инопланетяне?
Логика процессора - это точно такая же программа и к ней применяется все то же самое, что было сказано сверху.
Окей, это C, не спорю. Но приведи мне пример обычного программирования без всяких private_cast (потому что в функциональном языке такого тупо нет), в котором значение переменной one_to_hundred не находилось бы между 1 и 100. И прочти пост внимательнее, там говорится, что ни одна функция кроме new() не имеет доступа к значению переменной.
> Я не могу доказать логику процессора, а потому и остальные люди — дибилы, и не могут сложить 2 и 2.
Серьёзно, это же тупо машинный код, единицы и нули, что там может пойти не так?
Сколько можно повторять дебилу, что есть разница между логикой процессора, написанной(и доказанной) на бумажке, и тем, что крутится в самом процессоре? Ты вообще необучаемый или как?
То есть, уже много лет там всё крутится как на бумажке, а завтра хуяк! и везде перестанет? Мы, кажется, уже договорились, что нет никакого ПРАКТИЧЕСКОГО смысла предполагать, что завтра австралийцы отвалятся от Земли и улетят в космос?
И да, не вижу разницы между 1+1 на бумажке и 1+1 в процессоре. Так что необучаемый тут скорее ты.
>То есть, уже много лет там всё крутится как на бумажке, а завтра хуяк! и везде перестанет
Какой же уебок. Ты доказывал, что therac-25 плох, потому что там предположили, что раз много лет все крутится - значит ошибок нет. А теперь, оказывается, что никаких ФОРМАЛЬНЫХ ПРОВЕРОК не существует, а есть ПРАКТИЧЕСКИЙ СМЫСЛ.
Еще пара лет, с твоим-то IQ, и ты поймешь, что ПРАКТИЧЕСКИЙ СМЫСЛ - это тесты.
Всё крутилось в реальном мире, а на бумаге как раз никто ничего не крутил. Так что твои аргументы — это плевок против ветра.
> а завтра хуяк! и везде перестанет?
Речь шла про доказуемость/недоказуемость, если у тебя уже все выветрилось. Но если мы начнем говорить про практичность, то ты и тут соснешь с проглотом, потому что практично - это не доказывать программу на бумажке в тру-функциональном стиле и стараться ее перенести с минимум ошибок-опечаток, а писать тесты на бизнес-логику.
Мои аргументы на тебя не работают, потому что ты тупой, и за время существования треда ты не поумнел
Ну окей, а теперь более практический пример. md5. С которым ты уже соснул. Ну давай тогда так: конечный автомат протокола TCP.
>и тогда программа разбивается на тривиальные подпрограммы.
Композиция тривиальных программ не является тривиальной программой.
А, это действительно выветрилось. Да и ты же не думаешь, что тут один анон за всё ФП отвечает? Ну и про недоказуемость я уже давно согласился, но вот бумажный ФП как раз чисто математический, а отличий бумажного от программного я не вижу, потому что там та же математика, просто аксиомы вроде "1<2" записаны не в общественном договоре между учёными, а в компиляторе. Да, проблемы остаются, но не в самом ФП.
Вот смотри, структура Qwe тривиальна, и one_to_hundred не может иметь значения отличного от одного из промежутка 1 - 100, так? И это нам надо доказать только один раз, если мы больше не меняем код именно этой структуры. Потом у нас Ewq; но поскольку мы доказали, что Qwe тривиальна и значение её переменной не выходит за рамки, нам не надо это опять доказывать и для Ewq надо только доказать, что int ewq не выходит за некоторые рамки. Опять тривиальная структура, доказать корректность которой надо только один раз! Так что не так в композиции таких структур, содержащих одна другую?
В любом языке, где есть состояния (т.е. не чистый ФП), ты столкнешься с теми же проблемами при верификации, что и в Си. Ты не можешь доказать корректность функции отдельно от всего остального, если это не чистая функция, т.к. тебе придется доказывать корректность состояния, в котором эта функция выполняется. В результате вместо декомпозируемой до примитивных функций программа у нас получается один большой связный граф, где одна хуйня зависит от состояния другой хуйни.
Я не говорю, что пруверы не работают, я это пишу к тому, что твой подход "будем разбивать все на подпрограммы, пока корректность не будет самоочевидной" не работает. Будет работать что-то другое, но точно не это.
>Серьёзно, это же тупо машинный код, единицы и нули, что там может пойти не так?
Что угодно. Если мы говорим о формальном доказательстве того, что программа будет вести себя корректно на реальном компьютере, а не на сферической в вакууме машине Тьюринга, нам как минимум нужны формально верифицированные:
1. ОС
2. Компилятор
3. Процессор
На практике они не то, что оказываются не верифицированными, они имеют кучу недокументированных возможностей, которые невозможно учесть (потому что хуй тебе Интел про них что-то расскажет). ИРЛ австралийцы может и не отвалятся завтра от земли, а вот в x86 и не такая хуйня может произойти в любой момент выполнения твоей уютненькой верифицированной программы.
> приведи мне пример обычного программирования без всяких private_cast (потому что в функциональном языке такого тупо нет), в котором значение переменной one_to_hundred не находилось бы между 1 и 100
Так каким образом в языке без private_cast эта хуйня выходит за рамки? Я не говорю, что она не может выйти в экстремальной ситуации, но если у нас не ёбнулась память и ОС не вредоносный анальный перехватчик, который меняет значения твоих переменных, то как оно выйдет за рамки 1-100 промежутка? Да, если ты будешь куда-то передавать указатель на эту переменную, тебе придётся ещё и за ним следить, но ты же не будешь его передавать по условию. Так как?
Ну и верификация ОС, компилятора и процессора — это уже другой вопрос. Потому что те компании, которым нужно чистое ФП и его плюсы, они как раз могут себе позволить верифицировать весь этот список.
>Потому что те компании, которым нужно чистое ФП и его плюсы, они как раз могут себе позволить верифицировать весь этот список.
И много ты таких компаний знаешь? Если ты еще раз кинешь ссылку на Haskell in industry, я тебе уебу.
>Так что не так в композиции таких структур, содержащих одна другую?
То, что, например, множество Мандельброта генерируется следующим кодом
pmin, pmax, qmin, qmax = -2.5, 1.5, -2, 2
ppoints, qpoints = 200, 200
max_iterations = 300
infinity_border = 10
image = np.zeros((ppoints, qpoints))
for ip, p in enumerate(np.linspace(pmin, pmax, ppoints)):
_for iq, q in enumerate(np.linspace(qmin, qmax, qpoints)):
__c = p + 1j q
__z = 0
__for k in range(max_iterations):
____z = z*2 + c
____if abs(z) > infinity_border:
________image[ip,iq] = 1
________break
Код тривиален, а его поведение - нет.
Любой конечный автомат может иметь тривиальные части, которые будут характеризоваться сложнейшим поведением.
>Если мы говорим о формальном доказательстве того, что программа будет вести себя корректно на реальном компьютере, а не на сферической в вакууме машине Тьюринга, нам как минимум нужны формально верифицированные:
>1. ОС
>2. Компилятор
>3. Процессор
Нет, не нужны.
>На практике они не то, что оказываются не верифицированными, они имеют кучу недокументированных возможностей, которые невозможно учесть
Реальный мир бесконечно сложный, тщетны попытки что-то понять в нем.
Зато сильно упрощённые примитивные мат модели - вполне себе посильны для понимания и доказательства чего-то в рамках этих моделей.
И главное практически полезны.
Так же как ебнутому идиоту шизику с двачей нельзя ничего доказать, так и в реальности ни в чем нельзя быть уверенным, что не отменяет математических моделей(к которым кстати и ЯП относятся).
При этом одни ЯП дают больше гарантий, другие меньше.
Тот факт что в реальности ваще ничего нельзя доказать не отменять практической выгоды от мат моделей в рамках которых что-то доказать можно.
>потому что практично - это не доказывать программу на бумажке в тру-функциональном стиле и стараться ее перенести с минимум ошибок-опечаток, а писать тесты на бизнес-логику.
Ну объясни это всем тем компаниям что используют хаскель.
Заодно выступи в ООН, сообщи что институты и академическую науку можно упразднить, потому как научный метод теперь заменяет тестирование и бизнес логика. В РФ вон РАН упразднили, впереди планеты всей.
>Ну объясни это всем тем компаниям что используют хаскель.
Никто из тех кто использует хаскель не занимается подобной хуйней, которая тебе кажется с дивана
> Пук
А ты инсайдер, сидишь в одной из таких компаний, чтобы пукать?
Тестирование это и есть научный метод, дурачок.
>И главное практически полезны.
Скорее вредны, т.к. дают ложную уверенность в том, что программа корректна в любых условиях, хотя это не может быть так. Можно доказать, что программа корректно работает на сферической в вакууме машине, но не то, что она работает на физически существующем кудахтере.
>Ну объясни это всем тем компаниям что используют хаскель.
Половина списка Haskell in Industry это пиздеж, если не весь список. Прув ми вронг.
А ты думал я твой одноклассник что ли?
>Никто из тех кто использует хаскель не занимается подобной хуйней, которая тебе кажется с дивана
Какой хуйней? Ты с кем вообще говоришь?
Хаскель используют только потому что он автоматически доказывает написанный код.
>Тестирование это и есть научный метод, дурачок.
Как ты протестируешь явление о существовании которого ты ещё не знаешь?
Это мой одноклассник, лол.
Он вас тут всех эпично затраллил, сижу ржу с этой хуйни.
>Хаскель используют только потому что он автоматически доказывает написанный код.
>Как ты протестируешь явление о существовании которого ты ещё не знаешь?
T D D
D
D
> он автоматически доказывает написанный код
Ебать ты долбаёб. Раз в программе нет синтаксических ошибок и ошибок с типами, то в ней вообще нет ошибок?
Новый термин - "синтаксический долбаёб".
Речь идёт о формальной корректности в заданных рамках.
Только Богу доступна полная безошибочность.
>Ебать ты долбаёб
Дух захватывает от твоего интеллектуального уровня.
Ебать ты долбаёб. По твоему, факт успешной компиляции программы на той же сишке - это не "формальная корректность в заданных рамках?
Вы оба долбоебы, поебитесь уже. Где-нибудь подальше от программача.
Нельзя так просто взять, назвать ОПа пидорасом, и послать на хуй. Ты должен создать иммутабельный клон ОПа с атрибутом "пидорас" уже на хую.
Можно, если он экземпляр uniqueness type.
Такой пидорас конечно уникален
>Оверхеды.
Да ты заебал, ты когда уже на оптимизирующиу компиляторы код пересадишь? Или ты под целевую платформу императивную низкоуровневую динамикодрисню пишешь?
>Руби
>Не сойбойский
>Питон
>Сойбойский
Ты зачем ссышь на себя?
Сойбой, плиз. Импортнул тензорфлоу as tf уже?
А это не ты инженер-конструктор из соседнего треда?
Я хадуп-илита.
Тогда понятен твой помпаж, сапог энтерпрайз-господина в жопе болит
Здесь композиция записана явно применением оператора композиции. Запись идет слева направо, а вычисления справа налево. Так что мимо.
>и поведение "тривиальных" подпрограмм зависит от состояния других "тривиальных" подпрограмм.
Если зацепление сильное, то тривиальные подпрогрммы становятся довольно большими (у которых между собой зацепление слабое). Это бесспорно затрудняет формальную верификацию, как, в прочем, и любую другую верификацию. Но хорошие программисты стараются ослабить зацепление, даже кучу техник в ООП, например, для этого придумали.
>Может, если релятивистская механика наебнется вместе с классической
Не может. Теория уже не может наебнуться. Гипотезы - сколько угодно, но не теории. Теории могут перестать использоваться, как геоцентрическая модель Птолемея, например, или стать ограниченными, как ньютоновская механика, но неверными уже никогда не станут.
>Эксперименты не могут доказать теорию в принципе
>Если бы эксперименты доказывали теорию, новых теорий не появлялось бы, потому что ты не можешь опровергнуть уже доказанный факт, это нонсенс.
>Если бы эксперименты доказывали теорию
Ты не понимаешь сути экспериментов. Их ставят:
1 Когда есть несколько конкурирующих теорий, чтобы выбрать наиболее подходящуюю, в этом случае эксперимент может доказать правоту какой-то теории.
2 Когда существующая теория плохо описывает некоторые результаты из ее следствий, чтобы выработать новую гипотезу, в этом случае и так понятно, что теория нихуя не работает при некоторых условиях, но при других работает хорошо и может быть использована. Например, доквантовая модель абсолютно черного тела, ньютонова механика и многие другие до сих пор используются, не смотря на то, что есть более лучшие теории.
На самом деле связь между теорией и экспериментом намного более разнообразная и тесная, чем ты себе её представляешь.
Не заебался копротивляться еще, жулик?
Никакого помпажа. Просто решил поставить мнительную сойбойную мл-мартышку на место.
Ну да, ну да. Мы верим.
Вот, смотри как быстро, уже произошло принятие. Даже не стал отрицать, что ты сойбой и мл-макака. Правильно, нужно смотреть правде в глаза.
По делу есть чо?
Нахуя что-то доказывать бордошизику?
Да все тоже: докажи корректность любой имплементации md5.
Да с тобой уже все понятно. Ваша программа не программа - ваша программа - это электроны в транзисторах.
Просто напиши: я не способен формально доказать корректность программы на md5. Я же не спрашиваю причину. Я вижу, что ты это сделать не можешь. А ведь там даже тьюринг-полноты не требуется.
Тебе бессмысленно что-то доказывать. У тебя же только тесты.
Бессмысленно доказывать не мне, а бессмысленно спорить со мной, потому что моя точка зрения гораздо более обоснована, чем твоя. Ты говоришь - "разбить на тривиальные подзадачи". Ну вперед - бери https://gist.github.com/creationix/4710780 и разбивай
Ты определись сначала что тебе нужно. Разбить, или доказать?
Как доказать - писал выше - проверить на соответствие спецификации и наличие undefined behavior.
Разбить на подпрограммы можно, но нахуя? Код структурирован хорошо и на первый взгляд соответствует RFC.
>Это бесспорно затрудняет формальную верификацию <...> Но хорошие программисты стараются ослабить зацепление
Ясно, у борщехлебов в маняфантазиях все охуенно, а на практике их гениальная схема времен Декарта "мы разобьем сложную задачу на простые" не работает, потому что простые задачи цепляются друг за друга. Кто бы мог подумать.
>Не может. Теория уже не может наебнуться.
Может. Теория делает предсказания относительно опыта. Если опыт поменяется, то теория будет давать ложные предсказания. Как именно должен поменяться опыт в данном случае неважно.
>неверными уже никогда не станут.
Теория и не может быть верной или неверной, она может быть научной или не научной.
В остальном ты не сказал ничего, что противоречило бы моим словам, попробуй еще раз.
>Ясно,
Что ясно-то? Ты же даже не понимаешь о чем я тебе пишу. Уже по кругу уже ходим.
>потому что простые задачи цепляются друг за друга
Это вопрос правильного деления задачи на подзадачи. Если не можешь поделить задачи на элементарные, которые хотя бы можно покрыть юнит-тестами, я уж не упоминаю формальное доказательство - вон из профессии.
>Если опыт поменяется
Опыт поменяться не может в силу своего определения. Можно получить только новый опыт, который данная теория описать не сможет. Старый опыт может прекрасно ей описываться, сколько не повторяй эксперименты из того старого опыта. А новый опыт (незамеченные закономерности, экстремальные случаи итд) может либо её подтверждать, либо накладывать ограничение на применимость теории, что ведет к новым гипотезам, и, в последствии, к обобщающим теориям.
>Теория и не может быть верной или неверной, она может быть научной или не научной
Верна == проходит экспериментальную проверку. Теория всегда верна в рамках своих границ применимости, ибо теория == экспериментально проверенная гипотеза. Про ненаучность я вообще не говорю, т.к., я надеюсь, речь идет исключительно о научных теориях.
Да что ты с ним разговариваешь, он говорит, что завтра значение УСП может внезапно измениться!
>Верна == проходит экспериментальную проверку.
Эксперимент может быть удачным (для теории) стечением обстоятельств. Поэтому доказать теорию невозможно.
>Это вопрос правильного деления задачи на подзадачи.
Программы в общем случае не являются деревом, это граф с циклами.
Есть такая игра - супер марио. В ней объекты мира - довольно примитивны, типа с вшитым алгоритмом уровня "идти, пока не встретишь край, дальше развернуться". Но количество возможных комбинаций объектов таково, что новые баги открывают то сих пор, через 30 лет после выхода. И это - правило, а не исключение. Любой код, управляемый данными, содержит непредсказуемые комбинации этих самых данных. А это любой код, в котором есть пункт меню "файл-открыть..." .
>которые хотя бы можно покрыть юнит-тестами
Маня сдалась и поняла, что в формальные доказательства не может
Есть такое понятие, как воспроизводимость. Или ты думаешь эксперимент, который поставил один раз один моченый и больше никто не смог, примут в качестве доказательства верности гипотезы, или доказательства следствий из теории?
Если ты не знал, то та же элементарная механика перепроверяется в повседневной жизни инженерами. Доказательство тому - тысячи работающих автомобилей, стоящих зданий, мостов и создание и разработка прочих достижений науки и техники.
К слову, g зависит от гравитационной постоянной, массы Земли и радиуса Земли. И от скорости вращения Земли ещё, потому что центростремительная сила.
Если изменится гравитационная постоянная — тебя распидорасит.
Если от Земли оторвётся кусок такого размера, что УСП изменится на 0.1 — тебя распидорасит вместе с планетой.
Если завтра радиус Земли внезапно увеличится на двадцать-тридцать километров — тебя распидорасит. Для сравнения, высота Эвереста над морем — всего девять километров.
И, наконец, если Земля ускорит своё вращение, тебя снова распидорасит. Не сразу, как в случаях до этого, но всё равно.
Сынок, блядь, ознакомся с основами современной науки и не неси очевидную хуйню с умным видом.
>игра вышла тридцать лет назад
>приведу её как пример
>ознакомся
Ознакомься с русским языком, а потом иди нахуй.
>Если изменится гравитационная постоянная — тебя распидорасит.
>Если от Земли оторвётся кусок такого размера, что УСП изменится на 0.1 — тебя распидорасит вместе с планетой.
>Если завтра радиус Земли внезапно увеличится на двадцать-тридцать километров — тебя распидорасит. Для сравнения, высота Эвереста над морем — всего девять километров.
>И, наконец, если Земля ускорит своё вращение, тебя снова распидорасит. Не сразу, как в случаях до этого, но всё равно.
Хуесли. А еще g зависит от высоты. На высоте МКС g меньше девятки. И где твой пиздежь теперь?
>Пук
>Программы в общем случае не являются деревом, это граф с циклами.
И как это мешает осуществить формальное доказательство?
>Любой код, управляемый данными, содержит непредсказуемые комбинации этих самых данных.
Код управляемый данными - по сути интерпретатор, а данные - программа для него. Очевидно, либо необходимо доказательство корректности данных (т.е. программы), либо доказательство способности интерпретатора отвергнуть некорректную комбинацию данных.
>Маня сдалась и поняла, что в формальные доказательства не может
То, что можно покрыть юнит-тестами, является достаточно мелкой подпрограммой и поддается несложному формальному доказательству.
>Очевидно, либо необходимо доказательство корректности данных (т.е. программы), либо доказательство способности интерпретатора отвергнуть некорректную комбинацию данных.
А это невозможно из-за комбинаторного взрыва.
>То, что можно покрыть юнит-тестами, является достаточно мелкой подпрограммой и поддается несложному формальному доказательству.
Нет. Тест дедуктивен, а формальное доказательство индуктивно.
Например, чтобы доказать корректность кода который ты приводил выше тестом, тебе достаточно проверить 3 случая. Чтобы доказать этот же код формально, тебе нужен аппарат зависимых типов (даже если ты будешь доказывать на бумажке - что лично ты сделать не в состоянии, и все твои "формальные доказательства" это детский сад уровня "НУ ЭТО ЖЕ ОЧЕВИДНО ЧТО ТУТ НЕ МОЖЕТ БЫТЬ ОШИБКИ", все равно нужна теория).
>А это невозможно из-за комбинаторного взрыва.
Если перебором, то конечно.
>Нет. Тест дедуктивен, а формальное доказательство индуктивно.
Индуктивный - лишь один из методов доказательства.
>То, что можно покрыть юнит-тестами, является достаточно мелкой подпрограммой
Юнит-тест - это почти любой тест, написанный программистом для своего кода. Если ты тестируешь какой-то юнит и тот юнит в качестве части своей работы дергает другой юнит(например, чтобы отфильтровать массив), то тест внезапно не становится интеграционным или еще каким. Так что чекай определения.
Юнит тесты тот еще обман десятилетия.
Нет, конечно, тестирование любого кода реально помогает баги обнаружить, но само юнит тестирование работает нормально только когда у тебя чистые функции, если же нет, то начинается натягивание моков на глобус.
Нет, конечно, тестирование любого кода реально помогает баги обнаружить, но само юнит тестирование работает нормально только когда у тебя чистые функции, если же нет, то начинается натягивание моков на глобус.
Моки нужны только для тестирования вещей, над которыми у тебя нет прямого контроля. Например, вызов БД мокать не стоит, потому что ты и так можешь вызвать реальную БД в транзакции и в конце теста эту транзакцию отменить, либо вообще ресетить БД полностью в начале каждого теста, если речь идет о какой-нибудь не поддерживающей транзакции параше уровня монги. И уж тем более не стоит мокать никакой из кусков кода, принадлежащих твоему приложению(это включает себя в том числе и либы). Единственное, где без моков не обойтись - это вызовы сторонних API, которые ты никак не контролируешь. Например, запрос на сторонний сервер или эвент с вебсокет-сервера.
Моки - это инструмент установления тотального контроля над чем-то, и если тебе приходится устанавливать тотальный контроль над своим собственным кодом для тестирования оного, то скорее всего ты что-то делаешь не так. Если хочется повысить скорость выполнения тестов, то это решается не через моки, а через вынесение логики из прожорливых компонентов в более простые и изолированные.
> бугуртит с иммутабельности
> всерьез приводит в пример платформеры требующие по 8 гигов и написанные какими-то дегродами на коленке в качестве примера без пруфов
> также всерьез уверен, что в скомпиленном коде реально будет создан новый объект, а не переиспользован предыдущий по возможности
> нихуя не знает про устройство сборщиков мусора и прочей еботни
> считает каждый байт даже в том случае, когда это явно в ущерб скорости выполнения программы
Чувак, у всего есть своя область адекватного применения, прими таблетки и успокойся. Где нужно иммутабельность используется, где не нужно -- не используется. В крайности впадают либо хипстеры, либо долбоебы, что, как правило, одно и то же.
Понятность кода -- вещь весьма и весьма субъективная.
Лично мне понятнее и логичнее кажется функциональный код, но у меня бэкграунд в лямбда-исчислении и теории типов имеется. Императивщина становится намного менее интуитивной, когда пытаешься относительно императивного кода что-то доказать. Тесты не катят, для софта в критических областях именно доказательства корректности программ строят.
В ФП тоже можно написать непонятный трудночитаемый код. Тут вообще не от парадигмы зависит, а от скила написавшего.
сложно
скала норм язык, прост с очень высоким порогом вхождения поэтому средний проект на скале выглядит как говно
>любая императивщина как раз воспринимается легче и интуитивнее
Нет, потому что тебе читая код одной функции/процедуры нужно в голове при этом держать дельту состояния программы после выполнения n строк кода этой функции. Поэтому код разбивают на как можно большее количество функций и процедур, которые вызывают потом друг друга. А ФПбляди такие, хей, а почему бы нам сразу не построить все вокруг функций, а состояние пробрасывать через них?
Але блять, это гейдев, там всегда будет подобного рода байтоебство, глупо мерить все ойти по меркам гейдева. Скрипты для emacs ты тоже предлагаешь на крестах писать?
На работе у нас в проекте получается ускорение в полтора раза просто за счет добавление ключика "-mhaswell" в параметры компиляции.
Но у нас код не совсем обычный, со всякими там умножениями матриц 10000х10000
>Але блять, это гейдев, там всегда будет подобного рода байтоебство, глупо мерить все ойти по меркам гейдева.
Наоборот, только так и нужно мерять. Игры всего лишь требуют больше всего ресурсов, поэтому оптимизация в первых рядах, но это не значит, что в программах не столь требовательных можно хуй забить. хуезабивалово это скользкая дорожка, ведущая к тотальной деградации программирования, которая в итоге и игры уже охватила, и небо и аллаха, и мы сейчас тонем в болоте дерьмософте, когда могли бы лететь к звёздам на том же железе.
>когда могли бы лететь к звёздам на том же железе.
Совсем наркоман обкурился, на компьютерах летать хочет
>Игры всего лишь требуют больше всего ресурсов
Игры ничего не требуют, это издатели соревнуются, кто запилит более охуенную графику на слабом железе, поэтому программисты оптимизируют код как могут. Оптимизация -- это не что-то само собой разумеющееся, что вытекает из "правильных" практик программирования, те же хитровыебанные технологии вроде bsp -- это просто оптимизация, чтобы не рисовать каждый раз то, что игрок и так не увидит.
>хуезабивалово это скользкая дорожка, ведущая к тотальной деградации программирования
Забивание на оптимизацию не ведет к деградации, оно ведет только к более хуевой графике, что в инди игре в принципе терпимо. В остальном ты только выигрываешь в плане более простого дизайна программы и меньшего количества строк кода, дизайн проще менять и рефакторить.
Деградация происходит из-за каргоархитектуры и того, что кодеры ставят софт скиллы выше хард скиллов, т.е. социальные практики выше технических практик, и в общем то первое прямо вытекает из второго. Макаки не могут годами сделать одну веб страницу с логикой уровня программы на бейсике не из-за того, что они не умеют в оптимизации, с оптимизациями они бы делали страницу не годы, а десятилетия. Послушай, что Джон Блоу говорит на этот счет.
https://www.youtube.com/watch?v=dS6rCaDSwW8
>Вас, куколдов, сойбоев, педерастов, пассивных пидоров, которые убили блять все программирование. Пидорасы, вы ебаные, жидовье, блять. Иммутабельность они продвигают.
Не туда воюешь, дебил. Современный геймдев душат не программисты на хаскелях и лиспах, а сирешетка-дебилы, которые искренне считают, что хуюнити - это взаправдашний игровой движок.
У меня стойкое ощущение, что здесь почти никто не понимает, о чём пиздит
Не получается же
Действительно, ведь императивный код никак нельзя разбивать на функции, модули, саб-рутины и прочее. Все пишется в один файл на 10 тыщ строк.
Если бы ты внимательно перечитал мое сообщение, ты бы понял, что я нигде не пишу, что в императивщине нельзя все разбивать на функции, это ты хуйню какую-то в голове себе придумал и сам с ней споришь.
>это ты хуйню какую-то в голове себе придумал и сам с ней споришь.
Это вот это вот и есть:
>ФПбляди такие, хей, а почему бы нам сразу не построить все вокруг функций, а состояние пробрасывать через них?
вся суть функциональщины
>In computer science, functional programming is a programming with IO monad.
>pr-pedia
Почему не лучший вариант вс код?
Пушо есть idea?
> имплаинг иметь возможность разбивать код на функции и строить все вокруг функций одно и то же
Ну толсто ведь
>Во-первых, состояния объектов один из самых маленьких источников ошибок.
Дальше не читал. Очевидно, что у тебя нет никакого опыта. Попробуй вместо рассуждений о теории, писать много кода. Вот тогда и поймешь, почему иммутабельность лучше изменяемого состояния.
>(((
Заставил тебя отсосать.
Можно пример, где изменяемое состояние провоцирует ошибку, а иммутабельность спасает?
fn some_not_obvious_name(a: &mut Object) { a = GLOBAL_B; }
fn main() {
let a = Object::new();
some_not_obvious_name(&a);
println!("{:?}", a);
}
Иммутабельность непригодна ИРЛ. Подходит только для примеров кода в борщехлебских бложеках.
Пацаны, го проходить по веткам дерева через цикл! Ух бля!
Я за то, чтобы все ПО УМОЛЧАНИЮ было иммутабельно и константно, и если ты ГОЛОВОЙ понимаешь, что хочешь мутиции объекта/колекции/поля - ставишь какой-нибудь модификатор
Любой код где есть переменные, которые в последствии изменяются, уже является злом. Поэтому считается хорошей практикой использовать где только возможно константы. Линтеры ругаются когда используешь переменную, там где можно было использовать константу.
Никакого оверхеда нет. Давно уже разработаны умные компиляторы/интерпретаторы, которые сами следят за памятью. В языке Erlang и многих других, вообще нет переменных как таковых, если назначил имени значение, то потом изменить это уже нельзя, можно только создать новое, а виртуальная машина сама позаботится чтобы все было быстро и память не текла.
Везде сейчас есть иммутабельные структуры данных, даже в не функциональных языках. Не просто так это делается, это необходимость. Когда-то, да и по сей день некоторые непонимающие твердят, что мол функциональные языки дают оверхед, и бла-бла-бла. Полная чепуха это все. Современные компиляторы хорошо оптимизируют все опирации, никакой горе-программист не способен вручную так эффективно управлять памятью. Поэтому его код никогда не будет быстрее.
Идейно крепкий речекряк!
То есть переменная а передается по ссылке в функцию, там ее значение меняется по ошибке. Я правильно понимаю? Ну в обычных языках есть const для этого, а что привносят иммутабельные языки?
Это не пример, а мантра какая-то.
Есть игровой персонаж. У него позиция, вращение, скорость, здоровье, мана и т.д. Это все должно быть иммутабельным?
а я вот всё не понимаю, а нахуя? я слышал говорили про дебаг, что-то там стейты. а что дебагеры не могут разобрать изменяемые данные на стейты? можете какие-нибудь статьи кинуть, за смысл?
в принципе, в лиспе я понимаю, там код раскладывается в портянку и по идее можно её весело наворачивать как макароны на вилку, при ошибке. но кажется, это просто проще в плане написать такой интерпритатор, чем ещё и дебагер к нему.
если что извините что влезаю, наверняка я нихрена не понимаю о чём речь.
В дефолтно иммутабельных, типа раста, — "let" короче "mut let", а в дефолтно мутабельных "const" — опциональный параметр, который долбаёбам лень писать. В расте сделать что-то иммутабельное проще, чем мутабельное, а в крестах — наоборот. Поэтому в расте, если это не какой-то хитрый RefCell<>, проще знать, что там со значением (а конпелятор ещё и ворнинг выдаст на лишний 'mut' в твоём "let mut a". В крестах же ты никогда не узнаешь, изменилась или нет переменная, если писатель кода не будет так любезен проставлять везде "const". И не надо мне тут про "ну, вот рефселл же есть, какая иммутабельность!", потому что в крестах всё ещё хуже — const_cast там хуй определишь, оно даже в типе переменной не отображается.
Ставишь модификатор типа переменной, тот же "mut" в расте, — получаешь мутабельную переменную. Не ставишь — получаешь иммутабельную. Он же тебе не про анальную иммутабельность говорит, а про дефолтную, но опциональную.
Тогда мне mut придется ставить на 90% переменных. Не проще ли на 10% констант поставить const? Или нужно какое-то иное мышление?
Это бы играло роль, если бы программисты набирали код непрерывно, но по факту - очень много времени тратится на чтение кода и на раздумья, а как какать его написать.
Да и на объявление полей не так много времени тратится, как на операции над ними. Поэтому подход, принятый в расте действительно хорош
Поле, которое нигде не меняется лучше определить как константу, по факту.
Дело не в том, что кто-нибудь это сделает, дело в том, что ты можешь сделать это, например, при помощи какой-нибудь функциональной либы, которая совершенно неожиданно для тебя может мутировать твой объект, а не вернуть измененную копию. И узнать это можно не всегда, читать доку к каждому ссаному методу мне вот на хуй не надо
Проиграл с мочуха. Чего тебе жопу разорвало, бедняжка жопаскриптерская?
Если ты передаешь что-то в стороннюю либу, то в 99% это либо базовая структура языка, либо структура той либы. В обоих случаях никакие константы тебе не помогут.
Если ты передаешь что-то в стороннюю либу, то в 99% это либо базовая структура языка, либо структура той либы. В обоих случаях никакие константы тебе не помогут.
если бы иммутабельность была по умолчанию, то в подобных либах де факто было бы стандартом делать по две реализации для одного и того же метода аля MutableRever и ImmutableRevert, из названия которых очевидно что они делают.
Особенно неудобно, когда часть библиотечных методов мутируют что-то, а другая часть возвращают измененную копию. И я конечно не гинеколог, но это пизда
Дура, ты не знаешь что ли, что константы есть во всех языках, а не только в Джаваскрипте?
>MutableRever и ImmutableRevert
revert и reverted
Да там глубоко похуй, как они называются, потому что ты в передаваемом типе видишь, будет эта хуета изменяться, или нет.
fn pohui_name(data: &mut Data) { /.../ } // Изменяется в функции.
fn pizda_name(data: &Data) { /.../ } // Не изменяется.
fn yoba_name(data: Data) { /.../ } // Move semantics; если не Copy примитив (int, uint, char, bool), то съедается функцией и дропается где-то в ней.
А если метод класса?
impl Data{
fn foo(&self) {}
fn bar(&mut self) {}
fn foobar(self) {}
fn yaboo() {} // Ошибка, нельзя без "self" вызывать функцию на объект, как раз потому что ты вызываешь её на объект.
// Хочешь просто функцию, пиши её просто в модуль, а не в методы.
}
Те же самые правила, "self" — кейворд для обозначения объекта, на который ты вызываешь эту функцию.
Но когда читаешь код, ты этого не видишь, поэтому sort и sorted, чтобы не лезть каждый раз в декларацию
А, стоп, я проебался, можно и без "self" функцию для класса сделать (то есть, та же fn yaboo() сконпелируется), но вызывать её на объект нельзя, вызывается только как обычная функция:
yobalib::Data::yaboo();
let a = Data::default();
a.yaboo(); // Вот тут ошибка, так нельзя!
Когда читаешь без удобных подсветочек, да, не видно нихуя. Но при попытке компиляции оно тебе выдаст "bar() takes &mut self, a ti tuda pihaesh &self" и не сконпелирует. А если ты про что-то другое, то мутабельность смотрится в объявлении:
let a = 0;
let mut b = a.clone();
В этом треде зумеры-растаманы с радостным удивлением открывают для себя мир ключевого слова const, имевшего место в C с одна тысяча девятьсот шестьдесят восьмого года. Дикая природа удивительна.
Речь ведь как раз в том, что это самое const может быть по дефолту, а mut опционально, и это делает программирование менее рискованным, ведь ничего измениться без твоего желания просто не может.
>ЗАЧЕМ (((ОНИ))) ПРОДВИГАЮТ ИММУТАБЕЛЬНОСТЬ?
ритчи с томпсоном, кстати, добавили const в язык только под давлением общественности и сильно не хотели этого делать
Кстати, да, не шарили. Но "не шарили" — старая проблема, родилась прямо с человечеством. Тот же Эйнштейн — гений. Но неужели было так сложно сделать то, что сделал он? Опять проблема "не шарили". Но даже ОТО этого безумного учёного скоро подвинут, потому что квантмех говорит, что ОТО — хуета с ограниченной областью применения, как классическая механика, а квантмеху верят больше.
Они не шарили, потому что императивщики, наследие ассемблера и фортрана. Кстати, ни один императивный язык не привнес ничего нового ни в языки, ни в компиляторы/интерпретаторы. Все крутые фичи привнесли функциональные языки. Сборка мусора, метапрограммирование, и т.д. и т.п. И по сей день так происходит.
Вся суть тупости мамкиных функциональных шизиков. И ведь этот дурачок всерьез.
Дура, матчасть подтяни. Впервые сборщик мусора появился не в Джаве, как тебе в школе сказали, а в Лиспе, в далеких 50-60-хх годах. Тормоз пля.
> спиздить из лиспа в мейнстрим условный оператор с блоками кода в плечах вместо goto
> спиздить из лиспа в мейнстрим рекурсивные вызовы
> спиздить из лиспа в мейнстрим динамическую типизацию
> спиздить из лиспа в мейнстрим сборку мусора
> спиздить из лиспа в мейнстрим первоклассные функции
> спиздить из лиспа в мейнстрим keyword-аргументы (Гвидо, про тебя речь)
> спиздить из лиспа в мейнстрим ООП с дженериками
> спиздить из лиспа в мейнстрим just-in-time компиляцию
(вы находитесь здесь)
> спиздить из лиспа в мейнстрим тотальную рефлексию среды выполнения
> спиздить из лиспа в мейнстрим концепт образа рантайма
> спиздить из лиспа в мейнстрим код, состоящий исключительно из выражений
> спиздить из лиспа в мейнстрим символьный тип данных
> спиздить из лиспа в мейнстрим гомоиконность
> спиздить из лиспа в мейнстрим макросы
Про отсутствие оверхеда во всяких ерланг жава помоях ты загнул конечно.
Покажи на кукле, в каком месте злые императивщики трогали твой лисп.
Где там оверхед, в чем заключается? Тесты есть или что? В Эрланге вообще все неизменяемое, даже идентификаторы (аналог переменной). При том он может держать миллионы соединений, не нужно никакого прогрева как в джаве, виртуальная машина стартует за миллисекунды.
ты просто не писал в крупной проекте с 5 людьми, мутабельность нахуй не нужна
все должно быть имутабельным.
современные компы уже давно готовы к имутабельности
Полностью согласен. Даже иммутабельный стрейт жопаскриптерского редакса работает нормально и вполне себе успешно умудряется переезжать на андроид.
В нормальных конторах компы вообще не включают, чтобы 100% было иммутабельно.
>Тесты есть или что?
Есть.
>В Эрланге вообще все неизменяемое
И хорошо.
>При том он может держать миллионы соединений
Ну молодец, пусть держит.
>Виртуальная машина стартует за миллисекунды.
Ну пусть стартует.
>Где там оверхед, в чем заключается?
Динамическая типизация, проверка всего и вся на то является ли переданный параметр интом стрингой или массивом. При каждой самой мелкой операции.
Очистка мусора.
Интепритация байткода, вот это всё. Ну ты что, такой тупенький что сам не знаешь?
Ты видимо не в курсе, но switch по енаму в джавке таку юже табличку генерирует.
Алсо многое из этой хуйни вырезаются на этапе сборки приложения.
>проверка всего и вся на то является ли переданный параметр интом стрингой или массивом
Сразу видно статикодебила, который не знает, зачем придумали динамическую типизацию и в чем ее главные преимущества. Если функция получает аргумент, с интерфейсом которого не может работать, то она просто выкидывает рантайм ошибку. Не хочешь рантайм ошибок? Тестируй код. Никто не чекает тип входных аргументов, если это не юзер дата или не супер-популярная либа, где пытаются помочь ньюфагам информативными ошибками. Но в эти два случая требуют ручных проверок абсолютно в любом языке. Не говоря уже про то, что в эрланге типизация есть и ты можешь хоть обдрочиться, указывая тип на каждый пук и чекая это диалайзером.
>Есть.
Выкладывай или переобуешься?
>Динамическая типизация, проверка всего и вся на то является ли переданный параметр интом стрингой или массивом. При каждой самой мелкой операции.
>Очистка мусора.
>Интепритация байткода, вот это всё. Ну ты что, такой тупенький что сам не знаешь?
Очередной вскукарек диллетанта. Эрланг в вебе в лидерах по производительности. При этом жрет не много ресурсов. И код на нем очень короткий, потому что почти нет синтаксиса. То есть на нем можно писать быстрее даже чем на Руби или Питоне, а производительность выше в разы.
>Интепритация
Нет, тупенький здесь только ты.
А откуда твой интерпретатор узнает, совпадают ли типы, байты-то везде одинаково выглядят? Так что не пизди, что там проверок нет, любая динамическая типизация — это как минимум if(type == given_type), а как максимум — switch или match по типам.
>А откуда твой интерпретатор узнает, совпадают ли типы
Диалайзер - это не интерпретатор, а статический анализатор кода. Узнает оттуда же, откуда узнает и любой компилятор - из объявлений типов.
>любая динамическая типизация — это как минимум if(type == given_type)
Разве что в воспаленном сознании студента, который ни на чем толком не писал, кроме си крест крест.
Статический анализатор это прекрасно
Но мы же о РАНТАЙМЕ говорим.
Рантайм как ошибку выкидывает?
>. Эрланг в вебе в лидерах по производительности.
С PHP сравниваешь?
>Выкладывай или переобуешься?
Сам ищи, дебила кусок )))
> есть на нем можно писать быстрее даже чем на Руби или Питоне
Ведеорелейтед
Я думал ты просто долбоеб, который считает, что без ручных проверок на типы нельзя писать на динамике, а ты оказывается еще и шизик-байтоеб, у которого рантайм чек интерфейса на уровне языка ощутимо влияет на производительность. Проснись, 80-е уже прошли.
ГОВОРЮ, ЧТО ПРОВЕРОК НЕТ
@
МНЕ ДОКАЗАЛИ ОБРАТНОЕ
@
"ПРОСНИСЬ, МАНЯ, МЫ НЕ В 80-Х, ГДЕ ИФЫ, ВЫЗЫВАЕМЫЕ НА ЛЮБОЕ ДЕЙСТВИЕ, ЗАМЕДЛЯЛИ РАНТАЙМ; В 2К19 ОНИ БЕСПЛАТНЫЕ, МЫ ЖЕ ПРИПЛЫЛИ В БУДУЩЕЕ, ТУТ КОМПЫ РАБОТАЮТ НА МАГИИ, А НЕ НА БАЙТАХ"
Считатель битов, иди кушать, у тебя там борщ стынет.
Может быть ты в жабе int вместо Integer юзаешь, а? И new int[] заместо new ArrayList()?
>у которого рантайм чек интерфейса на уровне языка
>рантайм
>на уровне языка
У тебя острый бред.
>ощутимо влияет на производительность
Я что-то писал про ОЩУЩЕНИЯ?
бля, когда еще работал на работах, там был программист один
и он точно так же улыбался, скулы с этой улыбки у него наверное были железные
и еще он, сучка, сильно злой был на окружающий мир
но кодер был охуенный, да
Рабочая лошадка так сказать.
Злой от тяжёлой работы очевидно, понимания иммутабельности на уровне проверок интерфейса языка в рантайме, вот этого всего.
Друг, открой уже для себя type tags и осознай, что проверка типа, которая у тебя под кроватью живёт и по ночам тебя так пугает, это один xor и один cmp, которые на современном железе выполняются за доли наносекунды.
Я знаю, что сравнение типов — это сравнение констант, лежащих на самой вершине стэка, которое выполняется очень быстро, почти мгновенно. Но ты же утверждал, что там вообще нет проверок, а теперь вдруг оказывается, что есть. Ты уже обосрался, но пытаешься доказать, что маленький жиденький пук — это не обосранные труселя.
Ну-ка быстро показал, где он такое сказал? Он сказал, что 80е прошли и такие проверки на современном железе ничего не значат
>80е прошли и такие проверки на современном железе ничего не значат
Еще как значат
Я не он
Речь шла конкретно вот об этом:
>Про отсутствие оверхеда во всяких ерланг жава помоях ты загнул конечно.
>Ну-ка быстро показал, где он такое сказал?
Вот показывают, где какой-то ублюдок обсирается в полные штаны:
>Где там оверхед, в чем заключается?
Еще как значат.
Кроме банального оверхеда по памяти, и доп операций, есть множество нетривиальных нюансов связанных с этим говном.
Например выравнивание памяти, и прочая жуть.
>это один xor и один cmp,
Хочешь сказать там даже jmpов нету? А как же тогда рантайм ошибка выбрасывается?
Ты уже с ног до головы в дерьме весь вымазался, и продолжаешь серить.
> Хочешь сказать там даже jmpов нету?
Разумеется, есть, нахуя тогда cmp, если после него нет j*? Флаги туда-сюда подрочить?
> Ты уже с ног до головы в дерьме весь вымазался, и продолжаешь серить.
Я тебе ещё раз говорю, я не он. Я не утверждаю, что у проверок типов в динамических языках нулевой оверхед, я утверждаю, что он околонулевой. Обосрался здесь только ты со своим незнанием стоимости низкоуровневых операций.
это был не он(
>Я тебе ещё раз говорю
Ты мне первый раз что-то такое говоришь.
>я утверждаю, что он околонулевой.
Тогда приводи методику подсчёта.
Например какой оверхед на операцию ++ в процентах от самой операции. По памяти, по времени ЦП, по энергопотреблению.
И например чего-то такого:
(for i=0 i<10 i++){x=i*5}
>Обосрался здесь только ты
В чем конкретно?
>со своим незнанием стоимости низкоуровневых операций.
В чем оно выражается?
> Ты мне первый раз что-то такое говоришь.
> Например какой оверхед на операцию ++ в процентах от самой операции
Оверхед от операции на операцию? Проснись, ты обосрался.
>>Обосрался здесь только ты
>В чем конкретно?
>>со своим незнанием стоимости низкоуровневых операций.
>В чем оно выражается?
В следующем:
> Динамическая типизация, проверка всего и вся на то является ли переданный параметр интом стрингой или массивом.
Уж не говоря об
> При каждой самой мелкой операции.
Я Erlang не знаю, я за Common Lisp топлю, и в нём при (declaim (optimize (speed 3))) компилятор агрессивно выводит типы и выкидывает все проверки типов, какие только может, а когда не может, например, когда нужно передать значение в generic библиотечную функцию (и, как следствие, для этого значения нужен боксинг) выдаёт warning, что, мол, doing float to pointer coercion. Друг, я тебе искренне советую расширять кругозор и не верить стереотипам, а то так и помрёшь, думая, что динамика = медленно.
>а то так и помрёшь, думая, что динамика = медленно.
>компилятор агрессивно выводит типы и выкидывает все проверки типов, какие только может
Ты путаешь динамическую типизацию, и автомтаический вывод типов.
Это понятия из разных логических категорий.
Одно частично может решать проблему другого, но не устранять её принципиально.
И не решает проблемы оверхеда по памяти.
>Оверхед от операции на операцию? Проснись, ты обосрался.
Пахнет? Так ты свои штаны проверь.
В чем конкретно проблема?
Есть операция а сишечке, и есть операия в жаве, проверяем простое выражение x++.
Средствами самого языка это может быть и не очень просто сделать допустим, заменим на вычисление ряда фибоначи, допустим.
Для тебя это что-то необычное, и за гранью понимания?
Вот этом коммон лисп например, создаём список из 10 млн структур (обосеря знач-итн знч-флот знач-байт), и то же делаем в сишечке, а потом смотрим сколько список в памяти занял места?
Иммутабельность это возможность многопоточной коммуникации без значительного оверхеда и без сериализаций. Просто в котлине, судя по всему, пытаются сделать верблюда из камаза. Что-то вроде монад на питоне. Ненужное ненужно.
> Ты путаешь динамическую типизацию, и автомтаический вывод типов.
> Это понятия из разных логических категорий.
> Одно частично может решать проблему другого, но не устранять её принципиально.
Я их не путаю, я тебе говорю, что хороший вывод типов частично устраняет оверхед от проверок типов в рантайме.
> Вот этом коммон лисп например, создаём список из 10 млн структур (обосеря знач-итн знч-флот знач-байт), и то же делаем в сишечке, а потом смотрим сколько список в памяти занял места?
То ты кукарекал про жуткие тормоза от проверок типов, а теперь трёшь за потребление памяти. Найс виляния жопой, но окей, мне самому интересно стало, смотри пикрелейтед. Итог немножко предсказуем: 115M у сишного варианта против (190-112)=78M у CL-ного.
> операия
Друг, да не торопись ты так, всё хорошо будет.
Ты использовал статическую типизацию в лиспе. Давай без объявления типов. Мы о динамической типизации говорим. И не массив, а, СПИСОК. И добавь код проверяющий тип элементов.
> Ты использовал статическую типизацию в лиспе.
В лиспе динамическая типизация, засеря.
> Давай без объявления типов. Мы о динамической типизации говорим.
Динамическая типизация != отсутствие деклараций типов. Динамическая типизация - это когда тип является артибутом значения, а не атрибутом переменной. Друг, у тебя и правда с кругозором всё худо.
> И добавь код проверяющий тип элементов.
Зачем его проверять, если и я, и компилятор точно знаем тип?
>Итог немножко предсказуем: 115M у сишного варианта против (190-112)=78M у CL-ного.
1358M у цлного, нет?
Или что ты хочешь сказать, в твоём волшебном лиспе байт занимает меньше 8ми бит?
>Зачем его проверять, если и я, и компилятор точно знаем тип?
Где тогда динамическая типизация? Покажи её.
Не ебись в глаза, это колонка VIRT. Нас же реальное потребление памяти интересует, поэтому смотрим в следующую колонку, RSS.
> Где тогда динамическая типизация? Покажи её.
Друг, для тебя ничего не жалко: https://ru.wikipedia.org/wiki/Динамическая_типизация
>Память не память.
Окей.
сишная структура выравнивается по умолчанию, итого будет занимать 12 байт, поэтому и 117 мбайт по итогу массив занимает
что странно, дак это то, что, по видимому, эта реализация lisp не делает такого выравнивания, упаковывая все плотно, за счет этого и достигается экономия по памяти
но ведь это сильно снижает производительность
>я за Common Lisp топлю, и в нём при (declaim (optimize (speed 3))) компилятор агрессивно выводит типы и выкидывает все проверки типов, какие только может, а когда не может, например, когда нужно передать значение в generic библиотечную функцию (и, как следствие, для этого значения нужен боксинг) выдаёт warning, что, мол, doing float to pointer coercion
это, наверно, все же относится к особенностям реализации конкретного компилятора, но не самого стандарта
или все же в самом стандарте прописываются требования к таким оптимизациям?
>Друг, для тебя ничего не жалко: https://ru.wikipedia.org/wiki/Динамическая_типизация
Уныло троллишь. В программе твоей она где?
Компилятор у тебя использует декларацию типов и генерирует статически типизированный код.
У нас речь шла о динамической типизации.
Если ты не можешь запросить тип элемента, или записать в свой массив элемент другого типа, в чем блядь динамическая типизация в твоём коде заключается, где она?
Да нет, нельзя просто ёбнуть такую хуету, это проёб века будет. Скорее лисп из контекста понимает, что можно сделать три массива, каждый под свой тип, вместо одного под структуру, а всю структуру доставать по одинаковому индексу.
Двач образовательный. https://ru.wikipedia.org/wiki/Виртуальная_память
Нет, переупаковки aos в soa там не происходит, этот прав, там просто плотная упаковка. И да, в некоторых юз-кейсах при записи этого поля действительно будет некоторая просадка по производительности, но если тебя интересуют такие тонкие машиноспецифичные оптимизации, то ничто не мешает определить структуру и функции для работы с ней на сишке и дёргать их в лиспе через CFFI.
Вообще да, в стандарте не сказано, что информацию о типах нужно использовать для оптимизации, просто в SBCL исторически хороший вывод типов, ещё с тех времён, когда он был CMU CL. Может, в каких-нибудь коммерческих компиляторах типа Franz так же, не знаю, не пользовался.
Друг, это ты уныло троллишь.
> Если ты не можешь запросить тип элемента
Смотри пикрелейтед.
>юз-кейсах при записи этого поля действительно будет некоторая просадка по производительности
не "некоторая" а значительная
по крайней мере в языке си работа с невыровненными данными может просаживать производительность на некоторых платформах (в том числе и x86 в первую очередь) аж в несколько раз
>но если тебя интересуют такие тонкие машиноспецифичные оптимизации, то ничто не мешает определить структуру и функции для работы с ней на сишке и дёргать их в лиспе через CFFI.
хм, ожидается что таки компиляторы лиспа таки должны по умолчанию делать выравнивание структур и массивов, иначе это было бы очень странно
>по крайней мере в языке си
Ничего другого и нет. Современные процы оптимизированы под выполнение Си кода. По крайней мере риски всякие и х86(который тот-же риск но в соусе из сладкого хлебушка).
>Да нет, нельзя просто ёбнуть такую хуету, это проёб века будет. Скорее лисп из контекста понимает, что можно сделать три массива, каждый под свой тип, вместо одного под структуру, а всю структуру доставать по одинаковому индексу.
кстати, в си этот прием тоже активно используется (часто в библиотеках для интенсивных численных вычислений, к примеру), подход этот унаследован с фортрана
то есть не берут структуру с тремя полями (для примера), а делают три массива
и работают потом не с указателями, а со смещениями в массиве
>Современные процы оптимизированы под выполнение Си кода.
хм, скорее си-компиляторы способны генерировать эффективный машинный код..
что не отменяет того что (в контекте данного треда) и те же компиляторы lisp могут генерировать не менее эффективный машинный код (будьто "на лету", либо в виде объектного кода, "запакованного" в исполняемый файл)
А у меня вопрос не по теме ОП-поста, но связанный с его стилистикой и настроением.
Много ли альт-райтов, NRx или правых акселерационистов в IT-сфере? Молдбага и Ника Ланда кто-нибудь читает?
Если в лиспе дефолтным считается создание структуры без выравния (или хотя бы автоматически оптимизированного выравния, как в расте), то компиляторы лиспа могут только хуйца соснуть по сравнению с языками общего назначения.
Шел 2019-ый год
Еще были дебилы верящие, что память работает в Random Access
Тред не читал, но осуждаю
Еще были дебилы верящие, что память работает в Random Access
Тред не читал, но осуждаю
Я подробно вопрос выравнивания в CL-ных структурах не изучал, но если тебе охота побайтоёбствовать, всегда можно в структуре определить у поля тип, выровненный по длине на нужное количество вместо актуального типа, например, сделать вместо usnigned-byte (1 байт) fixnum (машинное слово, на хуй86-64 - 8 байт) и пользоваться им, помня, что у тебя там на самом деле 1 байт.
> Еще были дебилы верящие, что память работает в Random Access
Где, под кроватью у тебя?
ай-ти деполитизирована тем что в нем (по крайней мере для программистов) осуществляется жесткий отбор по способностям к программированию в первую очередь, к инженерному или математическому бэкграунду (которые осталяют мало времени на формирование каких то политических предпочтений, не до этого)
не вина сообщества в том что в нем оказываются в основном белые (с добавкой желтых азиатов) мужики, можно сказать что это естественный отбор
но следует сказать, что в последнее время, ай-ти сообществу навязывается со стороны некие странные нормы толерантности (типа терпеть пидоров, коих в ай-тишной тусовке всегда было 1-1,5% в отличие от стандартных 7%) типа что должны быть бабы-кодеры (если справляешься - велком, но никаких не должно же поблажек, а сейчас не так), типа черные тоже должны быть в айти (то же самое что и с бабами), потом если ты типа кодер, то ты значит продвинутый, а значит либерал (хотя кодеры всегда были консервативны)
речь о том, делает ли выравнивание структур компилятор той реализации лиспа, которую ты используешь
в си, к примеру, по умолчанию делается выравнивание
причем посредством нехитрого переупорядочивания и, опционально, добавления паддинг-поля в конец структуры, можно добится более плотной упаковки структуры, но которая будет продолжать быть выровненной
с другой стороны, выравнивание структуры (посредством директивы компилятору) можно отключить, и тогда поля ее будут идти в памяти одна за другой - это нужно для прямого чтения (накладыванием структуры на область памяти) различных бинарных форматов или протоколов, где данные идут один за другим
но, скорей всего, компилятор лиспа делает оптимизацию такую - а именно раскидывает эту структуру по массивам, как вот этот человек сказал
Кстати, а почему нет? Меня немного удивляет то как реализованные эти ДДР и контроллеры памяти.
В смысле что, вместо одной 128 битной шины можно было бы сделать 4 32 битных или 16 однобайтных. В чем сакральный смысл 2хканальной памяти мне непонятно?
>ай-ти деполитизирована
Ебать ты выпал из жизни, дедушка. Просто посмотри вот на этот безобидный твит, а потом почитай комменты к нему. Такого количества рвущихся левацких снежинок я не видел даже в твиттере трампа.
https://twitter.com/unclebobmartin/status/1200074140637642754
Random Access - это иллюзия, бро
http://www.1024cores.net/home/in-russian/ram---ne-ram-ili-cache-conscious-data-structures
> речь о том, делает ли выравнивание структур компилятор той реализации лиспа, которую ты используешь
Кстати да, ты прав. Когда не лень будет, посмотрю чо там другие CCL делают.
> но, скорей всего, компилятор лиспа делает оптимизацию такую - а именно раскидывает эту структуру по массивам
Не, точно нет по крайней мере в SBCL. Я дизассемблерные выхлопы смотрел у функций, работающих с массивами структур, там совершенно честный array-of-structs, чтобы сделать soa, нужно это делать явно - я это делаю через хитровыебанные макросы, из-за которых описание выглядит почти как обычная структура, но является soa.
>Random Access - это иллюзия, бро
>
>http://www.1024cores.net/home/in-russian/ram---ne-ram-ili-cache-conscious-data-structures
Мде мда. Пиздос какой-то.
Особенно
>Вкратце рецепт такой — по массивам надо проходить последовательно;
Охуеть теперь.
Пиздец просто пиздец, еще и об этом говне теперь волноваться. Нет, ненужно, унеси свою статью. Забуду это пока не поздно.
Ну и, сколько твой REPL памяти занимает?
>хм, скорее си-компиляторы способны генерировать эффективный машинный код..
Нет, х86 специально был разработан для выполнения Си кода.
Как и РИСК архитектура.
Маркетологи интела всем уши просто проссали в своё время о том что у них процы "универсальные", но это совсем ваще не так.
Насколько я помню историю, их IEE вынудила выпустить С проц.
Язык Си, требовал в своей время, и ничего не поменялось, очень специфичных архитектурных решений, конкретного набора конкретных регистров, модель адресации памяти при которой программе видно всю память, и прочее.
Альтернативой в свое время был ЦП интела же заточенный под паскаль, с разными крутыми фишками безопасности. Интел стёрла о нем почти все упоминания в итоге.
Где ты спал последние лет 20?
Ну чо так жирно-то?
Так я же выше скрин прикладывал, вот тут вторая картинка.
Ну я не про политику внутри IT, а про скорее про политические взгляды айтишников, которые могут и не отражаться в их технической деятельности.
это где ты вычитал такое? что x86 подгоняли под язык си?
Переезжаем:
е
р
е
е
з
ж
а
е
м
v
v
1
5
3
9
6
3
4
е
р
е
е
з
ж
а
е
м
v
v
1
5
3
9
6
3
4
Нахуй иди.
Но это весьма слабый аргумент. Во-первых, состояния объектов один из самых маленьких источников ошибок. Во-вторых, даже архитектура ПК построена на RANDOM ACCESS MEMORY. То есть наши отцы-основатели, в отличие от (((них))), которые теперь паразитируют на отрасли, предпочитали ПРОИЗВОЛЬНЫЙ ДОСТУП К ОБЪЕКТАМ В ПАМЯТИ.
Ну и наконец в-третьих. Гигантский оверхед на создание памяти, аллокацию, отслеживание неактуальных ссылок. В то время, пока код на Си будет лампово изменять переменные, код на Котлин будет создавать абстракции над абстрактным Джава-кодом. Зато (((иммутабельность))) Типа трушность. При этом количество забагованнного говна в ваших плей-маркетах и других магазинах софта только растет. Ебаный в рот, 2D-платформеры требуют 8 гигов оперативной памяти. Зато написано все (((чисто))) и (((иммутабельно)))
Джон Кармак плюет в вас, ссыт вам на ебало, пидорасы. Я ебал ваших матерей, фанаты иммутабельности. Я ссу на вас, я узнаю, где вы живете, заказываю на ваш адрес наркоту, стучу ментам, и радуюсь, когда вас крутят на почте. Я подговариваю таджиков зайти к вам домой и выебать на ваших глазах вашу черноволосую жидовскую девочку. ВЫ пидорасы, хуеглоты, ублюдки, ссу вам в рот, вы убили нахуй программирование, ебаные поджидки.