Этого треда уже нет.
Это копия, сохраненная 16 января 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 16 января 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Анон, зачем (((они))) от мира программирования продвигают такую фичу как иммутабельность и принудительно пересаживают всех на ее оверхеды? Единственный вскукарек, хоть как-то рационализирующий введение иммутабельности — уменьшение количества ошибок при разработке.
Но это весьма слабый аргумент. Во-первых, состояния объектов один из самых маленьких источников ошибок. Во-вторых, даже архитектура ПК построена на RANDOM ACCESS MEMORY. То есть наши отцы-основатели, в отличие от (((них))), которые теперь паразитируют на отрасли, предпочитали ПРОИЗВОЛЬНЫЙ ДОСТУП К ОБЪЕКТАМ В ПАМЯТИ.
Ну и наконец в-третьих. Гигантский оверхед на создание памяти, аллокацию, отслеживание неактуальных ссылок. В то время, пока код на Си будет лампово изменять переменные, код на Котлин будет создавать абстракции над абстрактным Джава-кодом. Зато (((иммутабельность))) Типа трушность. При этом количество забагованнного говна в ваших плей-маркетах и других магазинах софта только растет. Ебаный в рот, 2D-платформеры требуют 8 гигов оперативной памяти. Зато написано все (((чисто))) и (((иммутабельно)))
Джон Кармак плюет в вас, ссыт вам на ебало, пидорасы. Я ебал ваших матерей, фанаты иммутабельности. Я ссу на вас, я узнаю, где вы живете, заказываю на ваш адрес наркоту, стучу ментам, и радуюсь, когда вас крутят на почте. Я подговариваю таджиков зайти к вам домой и выебать на ваших глазах вашу черноволосую жидовскую девочку. ВЫ пидорасы, хуеглоты, ублюдки, ссу вам в рот, вы убили нахуй программирование, ебаные поджидки.
Но это весьма слабый аргумент. Во-первых, состояния объектов один из самых маленьких источников ошибок. Во-вторых, даже архитектура ПК построена на RANDOM ACCESS MEMORY. То есть наши отцы-основатели, в отличие от (((них))), которые теперь паразитируют на отрасли, предпочитали ПРОИЗВОЛЬНЫЙ ДОСТУП К ОБЪЕКТАМ В ПАМЯТИ.
Ну и наконец в-третьих. Гигантский оверхед на создание памяти, аллокацию, отслеживание неактуальных ссылок. В то время, пока код на Си будет лампово изменять переменные, код на Котлин будет создавать абстракции над абстрактным Джава-кодом. Зато (((иммутабельность))) Типа трушность. При этом количество забагованнного говна в ваших плей-маркетах и других магазинах софта только растет. Ебаный в рот, 2D-платформеры требуют 8 гигов оперативной памяти. Зато написано все (((чисто))) и (((иммутабельно)))
Джон Кармак плюет в вас, ссыт вам на ебало, пидорасы. Я ебал ваших матерей, фанаты иммутабельности. Я ссу на вас, я узнаю, где вы живете, заказываю на ваш адрес наркоту, стучу ментам, и радуюсь, когда вас крутят на почте. Я подговариваю таджиков зайти к вам домой и выебать на ваших глазах вашу черноволосую жидовскую девочку. ВЫ пидорасы, хуеглоты, ублюдки, ссу вам в рот, вы убили нахуй программирование, ебаные поджидки.
516 Кб, 1366x768ВЫ БЛЯТЬ ГЛЯНЬТЕ НА ОБЪЕМ КОДА ПОД КАПОТОМ ЧТОБЫ ОДНОЙ СРАНОЙ ПЕРЕМЕННОЙ ПРИСВОИТЬ ЗНАЧЕНИЕ!
СУКА БЛЯТЬ. И это еще даже не байт-код. Пидорасы, блять. Пидорасы. Сука, Гитлера на вас нет.
СУКА БЛЯТЬ. И это еще даже не байт-код. Пидорасы, блять. Пидорасы. Сука, Гитлера на вас нет.
765 Кб, 1366x7684 ИМЕННОВАННЫЕ КОНСТАНТЫ? НАХУЯ?
Давайте лучше сделаем блять классы, которые у нас развернутся вот в такую хуйню. И это еще блять перед компиляцией в байт-код. Ради 4 констант. 16 байтов. Листинг кода на всю страницу.
Давайте лучше сделаем блять классы, которые у нас развернутся вот в такую хуйню. И это еще блять перед компиляцией в байт-код. Ради 4 констант. 16 байтов. Листинг кода на всю страницу.
130 Кб, 750x600Взгляньте, как люди делали, чтобы игры шли даже на некрожелезе: https://ru.wikipedia.org/wiki/Быстрый_обратный_квадратный_корень
И сравните блять с текущим подходом. Если вы скажите Кармаку, что каждый раз создаете новые объекты, потому что вы мнительные невротики, которые по десять раз дергают ручку двери, потому что вдруг они забыли присвоить переменной нужное значение, то он вас оббоссыт.
Вас, куколдов, сойбоев, педерастов, пассивных пидоров, которые убили блять все программирование. Пидорасы, вы ебаные, жидовье, блять. Иммутабельность они продвигают. За чистотой вашего кода скрывается блять ГОРА ЕБАНОГО МУСОРА и костылей, из-за которых юзер докупает новую оперативку и новый девайс. Пидорасы, сдохните блять уже. Говноеды пидерасты, ненавижу, блять, отрежьте свои отростки и не размножайтесь, хуилы блять.
И сравните блять с текущим подходом. Если вы скажите Кармаку, что каждый раз создаете новые объекты, потому что вы мнительные невротики, которые по десять раз дергают ручку двери, потому что вдруг они забыли присвоить переменной нужное значение, то он вас оббоссыт.
Вас, куколдов, сойбоев, педерастов, пассивных пидоров, которые убили блять все программирование. Пидорасы, вы ебаные, жидовье, блять. Иммутабельность они продвигают. За чистотой вашего кода скрывается блять ГОРА ЕБАНОГО МУСОРА и костылей, из-за которых юзер докупает новую оперативку и новый девайс. Пидорасы, сдохните блять уже. Говноеды пидерасты, ненавижу, блять, отрежьте свои отростки и не размножайтесь, хуилы блять.
>>477330
А сейчас для этого есть инструкция в процессоре, которая будет работать быстрее олдскульного хака.
А сейчас для этого есть инструкция в процессоре, которая будет работать быстрее олдскульного хака.
>>477342
Только она не используется, потому что не заложено в быдлоязыки из говна.
Как пример, видел игру, требующую SSE4.2. Казалось бы, круто жы, оптимизации, а на деле патчик из нескольких байтов убирает это требование и идет спокойно без всяких SSE4.2 Вот так. Тупо показуха, стоит галочка на использование, а на самом деле ничего не используется, а дебилы, пидоры, и прочие иммутабельные выродки воображают в своих тупорылых головках какие у них охуенные технологии.
Только она не используется, потому что не заложено в быдлоязыки из говна.
Как пример, видел игру, требующую SSE4.2. Казалось бы, круто жы, оптимизации, а на деле патчик из нескольких байтов убирает это требование и идет спокойно без всяких SSE4.2 Вот так. Тупо показуха, стоит галочка на использование, а на самом деле ничего не используется, а дебилы, пидоры, и прочие иммутабельные выродки воображают в своих тупорылых головках какие у них охуенные технологии.
>>477327 (OP)
Хуя жавамакаку разорвало.
Хуя жавамакаку разорвало.
>>477327 (OP)
Додель, произвольный доступ и иммутабельность - это разные плоскости абсолютно. Можно на няшных иммутабельных лиспах написать код, который будет последовательно читать данные из рамы и тем самым аккуратно вдоль шерсти расчёсывать кэш процессора, а можно на гольной сишке нашароёбить код, который будет хуй пойми как тыкаться по разным областям выделенной памяти и КЭШ МИСС ГРОБ КЛАДБИЩЕ ПИДОР.
>ПРОИЗВОЛЬНЫЙ ДОСТУП К ОБЪЕКТАМ В ПАМЯТИ
Додель, произвольный доступ и иммутабельность - это разные плоскости абсолютно. Можно на няшных иммутабельных лиспах написать код, который будет последовательно читать данные из рамы и тем самым аккуратно вдоль шерсти расчёсывать кэш процессора, а можно на гольной сишке нашароёбить код, который будет хуй пойми как тыкаться по разным областям выделенной памяти и КЭШ МИСС ГРОБ КЛАДБИЩЕ ПИДОР.
>>477327 (OP)
пашол пидорас >>= нахуй
пашол пидорас >>= нахуй
>>477327 (OP)
То есть, тебе например нормально что в жабе вместо паблик полей геттеры и сеттеры и это объясняется в пользу будущего рефакторинга, мол можно будет туда бизнес логику еще засунуть в будущем. Но в реале в поля никогда никто бизнес логику не сует в том числе и я за 15 лет.
Тебя уже обманывают много лет, а к иммутабельному просто еще не привык. Поверь, ты еще не видишь и капли того бойлерплейта который есть в современном программирование иногда люди берут фреймворки чтобы решить недельную работу, но потом тратять на этот фреймворк месяцы и это нормально в этом кустарном мире программирования
То есть, тебе например нормально что в жабе вместо паблик полей геттеры и сеттеры и это объясняется в пользу будущего рефакторинга, мол можно будет туда бизнес логику еще засунуть в будущем. Но в реале в поля никогда никто бизнес логику не сует в том числе и я за 15 лет.
Тебя уже обманывают много лет, а к иммутабельному просто еще не привык. Поверь, ты еще не видишь и капли того бойлерплейта который есть в современном программирование иногда люди берут фреймворки чтобы решить недельную работу, но потом тратять на этот фреймворк месяцы и это нормально в этом кустарном мире программирования
>>477327 (OP)
Потому что успех ученых не зависит от успеха бизнеса, и в науке пышным цветом цветут манятеории. В этом, кстати, нет ничего плохого, наука для того и нужна, чтобы из манятеорий бизнес потом приходил и брал нужное. Если бы было не так, то это была бы не наука, а бизнес, а бизнес уже есть.
Проблемы начинаются, когда весь бред ученых начинают принимать на веру. Например, большинство ученых, помимо того, что она продвигают иммутабельность, продвигают еще и марксизм.
Неизбежная смерть императивных языков, которую они продвигают, - это такой же марксизм. Высеры типа "а вот мы ща как все автоматически распараллелим" - это рассуждения о экономическом гении Сталина. И так далее.
> Анон, зачем (((они))) от мира программирования продвигают такую фичу как иммутабельность и принудительно пересаживают всех на ее оверхеды?
Потому что успех ученых не зависит от успеха бизнеса, и в науке пышным цветом цветут манятеории. В этом, кстати, нет ничего плохого, наука для того и нужна, чтобы из манятеорий бизнес потом приходил и брал нужное. Если бы было не так, то это была бы не наука, а бизнес, а бизнес уже есть.
Проблемы начинаются, когда весь бред ученых начинают принимать на веру. Например, большинство ученых, помимо того, что она продвигают иммутабельность, продвигают еще и марксизм.
Неизбежная смерть императивных языков, которую они продвигают, - это такой же марксизм. Высеры типа "а вот мы ща как все автоматически распараллелим" - это рассуждения о экономическом гении Сталина. И так далее.
>>477450
Кекнул
>Они продвигают %чето%
>Думаю они делают это потому что марксизм
>Думаю это %чето% хуйня потому что марксизм
Кекнул
>>477453
Для аутистов напоминаю: собеседнику не требуется доказывать то, по поводу чего у вас уже консенсус.
Для аутистов напоминаю: собеседнику не требуется доказывать то, по поводу чего у вас уже консенсус.
>>477376
Все используется
Все используется
>>477330
Очередной безграмотный школьник пришел поучить отцов ебаться.
Ну, ооооок.
>Если вы скажите Кармаку
>скажите
Очередной безграмотный школьник пришел поучить отцов ебаться.
Ну, ооооок.
>>477327 (OP)
Потому что иммутабельность во много раз облегчает параллельные вычисления, за которыми будущее, так как мы уже уперлись в лимит процессорных мощностей и тупо наращиваем ядра.
Потому что иммутабельность во много раз облегчает параллельные вычисления, за которыми будущее, так как мы уже уперлись в лимит процессорных мощностей и тупо наращиваем ядра.
>>477698
Вообще-то нет
Вообще-то нет
>>477327 (OP)
ОП, для понимания ответа на свой вопрос тебе необходимо достичь просветления.
Сам ответ: причина в (((Лиспе))).
ОП, для понимания ответа на свой вопрос тебе необходимо достичь просветления.
Сам ответ: причина в (((Лиспе))).
372 Кб, 1024x834>>477327 (OP)
Бред. Иммутабельность упрощает работу с данными и спасает от мучительных дебагов. То что в Котлине и Джаве горы бойлерплейта и абстрактные фабрики это уже проблема другой области, в JS как раз все хорошо получается, вместо лапши и хуевого кода чистенькие редьюсеры, хороший стейт менеджмент и т.д.
Бред. Иммутабельность упрощает работу с данными и спасает от мучительных дебагов. То что в Котлине и Джаве горы бойлерплейта и абстрактные фабрики это уже проблема другой области, в JS как раз все хорошо получается, вместо лапши и хуевого кода чистенькие редьюсеры, хороший стейт менеджмент и т.д.
>>477790
Он устарел. JS не хайповый без ноды. Python тоже не хайповый. А Rust-то вообще каким боком?
Он устарел. JS не хайповый без ноды. Python тоже не хайповый. А Rust-то вообще каким боком?
>>477801
Пайтон хайпуется очень активно в среде дата-сосаентистов. JS хайповый и без ноды, непонятно правда, что именно греет рынок, но за последний год средние зарплаты жабаскриптеров выросли очень сильно. Го нуф сейд. Свифт там зря, да, про раст сложно сказать.
Пайтон хайпуется очень активно в среде дата-сосаентистов. JS хайповый и без ноды, непонятно правда, что именно греет рынок, но за последний год средние зарплаты жабаскриптеров выросли очень сильно. Го нуф сейд. Свифт там зря, да, про раст сложно сказать.
>>477771
В жс хачкель имитируют в объектном языке, как костыль выглядит вся эта недофункцианальщина
В жс хачкель имитируют в объектном языке, как костыль выглядит вся эта недофункцианальщина
54 Кб, 489x623>>477788
Попизди мне тут.
Попизди мне тут.
В жабах тоже костыль, но там можно, тк многопоточность, и скала если что есть
>>477810
Тогда почему язык R не хайповый? Среди датасаянтистов-то хайповый-то. Скорее сам датасаянтизм хайповый, а не питон.
Фронтенд не хайповый. А зарплаты растут наверно потому шо фронтов не хватает. Ты ещё скажи jQuery хайповый.. JS просто нужен в любом веб приложении, вот и всё. Но такими словами HTML так вообще все рекорды хайпа мочит.
А вроде уже стихает.
Вот свист вроде как не зря. Я про свивт часто слышу, хотя в большенстве свифт это язык разработки под эпл технику
>Пайтон хайпуется очень активно в среде дата-сосаентистов
Тогда почему язык R не хайповый? Среди датасаянтистов-то хайповый-то. Скорее сам датасаянтизм хайповый, а не питон.
>JS хайповый и без ноды
Фронтенд не хайповый. А зарплаты растут наверно потому шо фронтов не хватает. Ты ещё скажи jQuery хайповый.. JS просто нужен в любом веб приложении, вот и всё. Но такими словами HTML так вообще все рекорды хайпа мочит.
>Го нуф сейд.
А вроде уже стихает.
>Свифт там зря, да, про раст сложно сказать.
Вот свист вроде как не зря. Я про свивт часто слышу, хотя в большенстве свифт это язык разработки под эпл технику
>>478160
Мем про сойбоев это самое хайповое, что есть в этом треде, и его принесло ты.
Мем про сойбоев это самое хайповое, что есть в этом треде, и его принесло ты.
>>477385
DataOriented закукарекал.
Кэшмисс это какие-то еврейские байки, чтобы оправдать DoD.
На деле все жалкие попытки сделать такую архитектуру пож проект сложнее хеллоуворлда сосут хуй потому что ВНЕЗАПНО гешефт от него гораздо меньше (вообще нет его блять), чем человекочасы, потраченные на еблю с АрХиТеКтУрОй.
DataOriented закукарекал.
Кэшмисс это какие-то еврейские байки, чтобы оправдать DoD.
На деле все жалкие попытки сделать такую архитектуру пож проект сложнее хеллоуворлда сосут хуй потому что ВНЕЗАПНО гешефт от него гораздо меньше (вообще нет его блять), чем человекочасы, потраченные на еблю с АрХиТеКтУрОй.
>>477443
Во-первых, since 1958.
Во-вторых, есть дохуя лиспов с иммутабельностью, хотя бы та же Clojure, но в кругозор императивной жабамакаки он, конечно же, не входит.
Во-первых, since 1958.
Во-вторых, есть дохуя лиспов с иммутабельностью, хотя бы та же Clojure, но в кругозор императивной жабамакаки он, конечно же, не входит.
>>477327 (OP)
Хз, я лампово пишу код на Go мутабелтный, с циклами и тп. Один m4.large у меня 10к rps держит при загрузке проца в 90%
Хз, я лампово пишу код на Go мутабелтный, с циклами и тп. Один m4.large у меня 10к rps держит при загрузке проца в 90%
>>477432
Зис. Пару лет назад я осознал что все манябестпрактисес противоречат сами себе, а еще они не фальсифицируемы, и вообще весь ойти сплошь роится суевериями и религиями. Начал писать дома код полажа хуй на все это, полет нормальный. На работе постоянно плююсь про себя, что надо соблюдать весь этот фен-шуй, от которого толку ноль, но времени уходит дохуя.
Зис. Пару лет назад я осознал что все манябестпрактисес противоречат сами себе, а еще они не фальсифицируемы, и вообще весь ойти сплошь роится суевериями и религиями. Начал писать дома код полажа хуй на все это, полет нормальный. На работе постоянно плююсь про себя, что надо соблюдать весь этот фен-шуй, от которого толку ноль, но времени уходит дохуя.
>>478266
Ну если только ржавотред
Ну если только ржавотред
>>478255
Ты, видимо, главный из ожидающих.
Ты, видимо, главный из ожидающих.
>>478233
Не имею ничего против работ Маккарти
Угу, и на каждом можнозделоть то, что написано в том посте.
>Во-первых, since 1958.
Не имею ничего против работ Маккарти
>Во-вторых, есть дохуя лиспов с иммутабельностью
Угу, и на каждом можнозделоть то, что написано в том посте.
>>478277
Ну так-то да, например https://docs.racket-lang.org/reference/vectors.html
> Угу, и на каждом можнозделоть то, что написано в том посте.
Ну так-то да, например https://docs.racket-lang.org/reference/vectors.html
Машиномощности сейчас гораздо быстрее развиваются, чем пожирание программами ресурсов, вот и переходят на такое. 99,9% загрузки - дыры в использовании памяти с плохим отсечением, а не просто "выделили в 10 раз больше памяти, чем нужно"
>>478890
Как раз наоборот. Закон Мура кончился, а вот закон Вирта нет. Скоро весь софт начнет адово тормозить, и всякие быдлокодеры пишущие неоптимальный код соснут.
Как раз наоборот. Закон Мура кончился, а вот закон Вирта нет. Скоро весь софт начнет адово тормозить, и всякие быдлокодеры пишущие неоптимальный код соснут.
>>477327 (OP)
Тут много причин. Во-первых, concurrency. Во-вторых, это очень сильно упрощает код, что очень годный перк, когда над проектом работают много человек. В-третьих, код становится проще покрыть тестами или вовсе доказать корректность формальными методами. В-последних, оверхед не такой уж и большой, как ты себе представляешь, даже в убогой имплементации Котлина или что там у тебя на пике. Со временем ты откроешь, как на деле работают аллокаторы памяти, как любые проекты переизобретают dataflow графы, как твой любимый Джон Кармак самолично топит за иммутабельность и почему JIT в целом не такая уж и плохая идея. Очень много ресерча стоит за этим, буквально десятилетия. Да и современные компьютеры работают немножко не так, как ты себе представляешь. Начни хотя бы с https://lwn.net/Articles/250967/ и MIT 6.851.
>>478225
rsqrtss/rsqrtps ровно 20 лет назад завезли в SSE. Относительно недавно их расширили для AVX.
Тут много причин. Во-первых, concurrency. Во-вторых, это очень сильно упрощает код, что очень годный перк, когда над проектом работают много человек. В-третьих, код становится проще покрыть тестами или вовсе доказать корректность формальными методами. В-последних, оверхед не такой уж и большой, как ты себе представляешь, даже в убогой имплементации Котлина или что там у тебя на пике. Со временем ты откроешь, как на деле работают аллокаторы памяти, как любые проекты переизобретают dataflow графы, как твой любимый Джон Кармак самолично топит за иммутабельность и почему JIT в целом не такая уж и плохая идея. Очень много ресерча стоит за этим, буквально десятилетия. Да и современные компьютеры работают немножко не так, как ты себе представляешь. Начни хотя бы с https://lwn.net/Articles/250967/ и MIT 6.851.
>>478225
rsqrtss/rsqrtps ровно 20 лет назад завезли в SSE. Относительно недавно их расширили для AVX.
>>479120
Это единственная реальная причина, остальное бред и хуйня. Код "проще" не становится, любая императивщина как раз воспринимается легче и интуитивнее, чем мешанина из функций. Чтобы код был тестируемый, его внезапно надо дизайнить тестируемым(то есть писать через TDD), от конкретной парадигмы это не зависит. Если ты думаешь, что писал говно в ООП, а потом вдруг открыл для себя ФП и твой код внезапно стал легче и понятнее, то нет, не стал, ты все так же пишешь говно, скорее даже еще более лютое, потому что дело было не в парадигме, а в программисте.
>Во-первых, concurrency
Это единственная реальная причина, остальное бред и хуйня. Код "проще" не становится, любая императивщина как раз воспринимается легче и интуитивнее, чем мешанина из функций. Чтобы код был тестируемый, его внезапно надо дизайнить тестируемым(то есть писать через TDD), от конкретной парадигмы это не зависит. Если ты думаешь, что писал говно в ООП, а потом вдруг открыл для себя ФП и твой код внезапно стал легче и понятнее, то нет, не стал, ты все так же пишешь говно, скорее даже еще более лютое, потому что дело было не в парадигме, а в программисте.
>>477330
Как раз-таки Кармак угорает по Racket (который, как Scheme, дофига функциональный).
Как раз-таки Кармак угорает по Racket (который, как Scheme, дофига функциональный).
>>479120
Пример из продакшна и аналогичный на императивщине без иммутабельности, где первый дает пососать второму или нахуй с тупичка
>concurrency легчи!!!11111
Пример из продакшна и аналогичный на императивщине без иммутабельности, где первый дает пососать второму или нахуй с тупичка
>>479433
Common Lisp функционален? Лол, в нём рекурсию зазорно делать, вместо него идиоматично использовать императивный loop.
Common Lisp функционален? Лол, в нём рекурсию зазорно делать, вместо него идиоматично использовать императивный loop.
>>479445
ААААААААААААААААААА
ААААААААААААААААААА
>>479437
Рекурсию вообще во многих функциональных языках зазорно использовать, потому что даже с tail-call оптимизацией она все равно жрет больше других способов, которые доступны как альтернатива в 99% случаев, да еще и читаются/понимаются лучше.
Рекурсию вообще во многих функциональных языках зазорно использовать, потому что даже с tail-call оптимизацией она все равно жрет больше других способов, которые доступны как альтернатива в 99% случаев, да еще и читаются/понимаются лучше.
>>477327 (OP)
Джон Кармак в свободное от окулуса время пишет на хаскеле.
Джон Кармак в свободное от окулуса время пишет на хаскеле.
>>479582
Этот пост ложь. Никто не пишет на Хаскеле.
Этот пост ложь. Никто не пишет на Хаскеле.
>>479582
Ты инсталлятор у окулусов видел? Джон, блядь, Кармак. Это худший кусок говна, который я видел в своей жизни.
Ты инсталлятор у окулусов видел? Джон, блядь, Кармак. Это худший кусок говна, который я видел в своей жизни.
>>479582
Кармак пишет на плюсах, в очень прямолинейном "геймдевовском" стиле работал в фейсбуке и видел его пул реквесты. Хотя пишет код он мало, и в основном ради своих экспериментов, в фейсбуке его держат в основном для пиара.
С хаскелем он немного поигрался в прошлом и забросил.
Кармак пишет на плюсах, в очень прямолинейном "геймдевовском" стиле работал в фейсбуке и видел его пул реквесты. Хотя пишет код он мало, и в основном ради своих экспериментов, в фейсбуке его держат в основном для пиара.
С хаскелем он немного поигрался в прошлом и забросил.
>>479522
Что за хуйню ты несешь? Tail-call оптимизируется в сраный цикл с аккумулятором. cmp и je - хуле ты еще хочешь?
Что за хуйню ты несешь? Tail-call оптимизируется в сраный цикл с аккумулятором. cmp и je - хуле ты еще хочешь?
>>479597
Около 200к в год должен был зарабатывать, мне там не понравилось и я свалил не проработав год
Около 200к в год должен был зарабатывать, мне там не понравилось и я свалил не проработав год
>>479599
Неблохо. Сколько бы осталось после налогов и повседневных затрат? Сейчас зашибаешь больше? Европка или штаты? Собесы сложные были?
Неблохо. Сколько бы осталось после налогов и повседневных затрат? Сейчас зашибаешь больше? Европка или штаты? Собесы сложные были?
>>479600
Оставалось бы тысяч 50-70 в год, в зависимости от трат. Сейчас зашибаю столько же, но работа куда приятнее. Штаты. Собесы уровня средних задач на литкоде и разговоров об опыте, прошлых проектах, "раскажите о сложной задаче".
Оставалось бы тысяч 50-70 в год, в зависимости от трат. Сейчас зашибаю столько же, но работа куда приятнее. Штаты. Собесы уровня средних задач на литкоде и разговоров об опыте, прошлых проектах, "раскажите о сложной задаче".
>>479601
Хуя, это в sf или другой штат? 200к звучит охуенно, а после расходов выходит как у меня в дс. А что по другим аспектам? Как люди, культура разработки, бытовые моменты? Что лучше, чем в дс, что хуже?
Хуя, это в sf или другой штат? 200к звучит охуенно, а после расходов выходит как у меня в дс. А что по другим аспектам? Как люди, культура разработки, бытовые моменты? Что лучше, чем в дс, что хуже?
>>478160
Потому что это слабая и медленная хуета. Не говоря уже о том, что в нем нет даже устоявшегося синтаксиса.
R это часть той же современной парадигмы, как и иммутабельность в новых языках — попытка настолько опустить порог вхождения, что программеры будут не нужны (по крайней мере, не в таком количестве.). По этой же причине сейчас даже на самых НЕтехнических направлениях в универах учат прогу, чтобы любой специалист, независимо от образования, по дефолту мог мутить какие-то инструменты.
Не понятно только почему всякие джависты, си-бляди и крестанутые с этого подгорают. Если эта парадигма реально будет править, то с их работами как раз ничего не произойдёт, а возможно работы станет больше, как и денег на их стеках.
мимо социолог-крестовик из большой четверки.
>Тогда почему язык R не хайповый?
Потому что это слабая и медленная хуета. Не говоря уже о том, что в нем нет даже устоявшегося синтаксиса.
R это часть той же современной парадигмы, как и иммутабельность в новых языках — попытка настолько опустить порог вхождения, что программеры будут не нужны (по крайней мере, не в таком количестве.). По этой же причине сейчас даже на самых НЕтехнических направлениях в универах учат прогу, чтобы любой специалист, независимо от образования, по дефолту мог мутить какие-то инструменты.
Не понятно только почему всякие джависты, си-бляди и крестанутые с этого подгорают. Если эта парадигма реально будет править, то с их работами как раз ничего не произойдёт, а возможно работы станет больше, как и денег на их стеках.
мимо социолог-крестовик из большой четверки.
>>479608
Ну такое. По мне так R - не тот язык, на котором хомяки пишут. Всё-таки датасаянся это датасаянс.
Функциональному программированию не меньше лет чем ООП, и оно не то что бы проще.
Вообще мимо кассы. Если раньше, в 70ых и 80ых в стране белых людей можно было 35 лет работать инженером с паяльником, а потом вкатиться в программинг, то сейчас ищат именно людей с призванием. Программирование стало основной деятельностью, а не одной из. И это не меняется.
Из твоей предпосылки, с которой я не согласен, как раз следует что потеряют, ибо их работу вытеснят вместе с их ебучим стеком.
Да и с каких это пор крестовики с джавистами в одной корзине? Джава же язык без менеждмента памяти, а значит и без порога вхождения. Вот как в джаве аллокатор написать?
> попытка настолько опустить порог вхождения, что программеры будут не нужны
Ну такое. По мне так R - не тот язык, на котором хомяки пишут. Всё-таки датасаянся это датасаянс.
> иммутабельность в новых языках
> новых
Функциональному программированию не меньше лет чем ООП, и оно не то что бы проще.
>попытка настолько опустить порог вхождения, что программеры будут не нужны
Вообще мимо кассы. Если раньше, в 70ых и 80ых в стране белых людей можно было 35 лет работать инженером с паяльником, а потом вкатиться в программинг, то сейчас ищат именно людей с призванием. Программирование стало основной деятельностью, а не одной из. И это не меняется.
> Если эта парадигма реально будет править, то с их работами как раз ничего не произойдёт
Из твоей предпосылки, с которой я не согласен, как раз следует что потеряют, ибо их работу вытеснят вместе с их ебучим стеком.
Да и с каких это пор крестовики с джавистами в одной корзине? Джава же язык без менеждмента памяти, а значит и без порога вхождения. Вот как в джаве аллокатор написать?
>>479598
Так в этом и суть, если конкретный код с рекурсией легко оптимизируется в цикл, то пиши его сразу циклом, тебе потом спасибо скажут, когда будут читать код.
Так в этом и суть, если конкретный код с рекурсией легко оптимизируется в цикл, то пиши его сразу циклом, тебе потом спасибо скажут, когда будут читать код.
>>479675
Какой же ты даун. Надеюсь, ты никогда не прикоснешься к проектированию большого распределенного энтерпрайза. Такие как ты весь проект завалят.
>Джава же язык без менеждмента памяти, а значит и без порога вхождения. Вот как в джаве аллокатор написать?
Какой же ты даун. Надеюсь, ты никогда не прикоснешься к проектированию большого распределенного энтерпрайза. Такие как ты весь проект завалят.
ну да, в принципе, под андроид нужен был бы язычек типа бейсика или дельфи(паскаля)
чтобы не оче образованные кодеры (ничего такого обидного в этом не вижу) могли глепать прикладной софт
а котлин сложный язык для изучения
чтобы не оче образованные кодеры (ничего такого обидного в этом не вижу) могли глепать прикладной софт
а котлин сложный язык для изучения
>>479746
кстати, нуралиев сотоварищи, когда делали 1С, это понимали
именно поэтому они запилили тупо подобие русского бейсика, чтоби нихуя не было кроме циклов и условий, чтобы была тупая сборка ссылок и все
кстати, нуралиев сотоварищи, когда делали 1С, это понимали
именно поэтому они запилили тупо подобие русского бейсика, чтоби нихуя не было кроме циклов и условий, чтобы была тупая сборка ссылок и все
517 Кб, 400x592>>479746
Есть такая философия, её конечно не услышишь в подкастах и конференциях, отсюда и подражателей то особо и нет. Но, в общем, есть профессиональные программисты, которые помимо кода мыслят шире и понимают что код ради кода не имеет смысла. Значение имеет только конечный продукт и как легко его потом сопровождать и продать. Трудно их назвать "не очень образованными".
Но в тоже время мы видим такие правильные языки как раст, скала, хаскель, на которых писать или сопровождать код невыносимо.
Так что это еще большой вопрос кто тут сильнее ограничен.
Есть такая философия, её конечно не услышишь в подкастах и конференциях, отсюда и подражателей то особо и нет. Но, в общем, есть профессиональные программисты, которые помимо кода мыслят шире и понимают что код ради кода не имеет смысла. Значение имеет только конечный продукт и как легко его потом сопровождать и продать. Трудно их назвать "не очень образованными".
Но в тоже время мы видим такие правильные языки как раст, скала, хаскель, на которых писать или сопровождать код невыносимо.
Так что это еще большой вопрос кто тут сильнее ограничен.
>>479746
Да тебе, пидору тупому, и родной язык сложноват
>котлин сложный язык
>нужен был бы язычек
>язычек
Да тебе, пидору тупому, и родной язык сложноват
126 Кб, 1214x724>>479746
Мобильной разработки хватило бы и python или js. Клепать 90% времени круды на статических языках, это как на самолете ездить в магазин.
Забавное то, что чтобы писать на котлине надо знать бэкграунд джавы, но в тоже время сам котлин очень так не похож на ту джаву. Я хз как джунов учить, как им объяснять зачем они так поиздевались над конструкторами, почему вместо "static" теперь надо писать "companion object" и то, почему не лучший выбор юзать их любимый vs code.
Мобильной разработки хватило бы и python или js. Клепать 90% времени круды на статических языках, это как на самолете ездить в магазин.
>а котлин сложный язык для изучения
Забавное то, что чтобы писать на котлине надо знать бэкграунд джавы, но в тоже время сам котлин очень так не похож на ту джаву. Я хз как джунов учить, как им объяснять зачем они так поиздевались над конструкторами, почему вместо "static" теперь надо писать "companion object" и то, почему не лучший выбор юзать их любимый vs code.
>>480546
В 2004 году комп перестал тянуть игры, стал программировать.
@
В 2019 комп перестал тянуть IDE, стал играть в игры.
В 2004 году комп перестал тянуть игры, стал программировать.
@
В 2019 комп перестал тянуть IDE, стал играть в игры.
>>480546
Тому що безрукие жабаскриптодебилы с синдромом NIH запилили его на ебучем электроне, очевидно же.
Тому що безрукие жабаскриптодебилы с синдромом NIH запилили его на ебучем электроне, очевидно же.
А может кто кто-нибудь на примерах объяснить как иммутабельность упрощает многопоточность? И ещё что делать с постоянным выделением памяти ведь это такой удар по производительности получается?
>>480634
Никак, нельзя просто взять и решить проблему потребности шаред данных. Либо ты ручками контролишь, либо костылями со своими плюсами и минусами.
Никак, нельзя просто взять и решить проблему потребности шаред данных. Либо ты ручками контролишь, либо костылями со своими плюсами и минусами.
>>480634
бОльшая часть проблем в многопотоке - это когда два или более потока одновременно читают и меняют один и тот же стейт. Если у тебя функциональный язык и все иммутабельное, то такой проблемы в принципе не может быть(на самом деле не все иммутабельное, стейт разумеется есть, но для его использования надо совершать дополнительные телодвижения и обычно он по умолчанию залочен, то есть все изменения идут в виде реквестов и обрабатываются по порядку)
Это давно оптимизируется на уровне языка, объекты копируются не полностью, а по ссылкам, например если у тебя есть длинный массив [a, b, c...] и ты добавляешь туда [d | a, b, c...], то это второй массив просто хранит в себе ссылку на первый и доп. значение d. В языке с мутабельностью такого не сделать, потому что даже если ты сохраняешь ссылку, то объект по ссылке может в любой момент поменяться, а вот в функциональных - ссылайся не хочу.
>как иммутабельность упрощает многопоточность
бОльшая часть проблем в многопотоке - это когда два или более потока одновременно читают и меняют один и тот же стейт. Если у тебя функциональный язык и все иммутабельное, то такой проблемы в принципе не может быть(на самом деле не все иммутабельное, стейт разумеется есть, но для его использования надо совершать дополнительные телодвижения и обычно он по умолчанию залочен, то есть все изменения идут в виде реквестов и обрабатываются по порядку)
>И ещё что делать с постоянным выделением памяти
Это давно оптимизируется на уровне языка, объекты копируются не полностью, а по ссылкам, например если у тебя есть длинный массив [a, b, c...] и ты добавляешь туда [d | a, b, c...], то это второй массив просто хранит в себе ссылку на первый и доп. значение d. В языке с мутабельностью такого не сделать, потому что даже если ты сохраняешь ссылку, то объект по ссылке может в любой момент поменяться, а вот в функциональных - ссылайся не хочу.
>>480546
Потому что это не текстовый редактор. Хочешь текстовый редактор? Вперёд, пиши свои маняпрожекты в блокноте, хуле. Что-что? Нет выделения синтаксиса? Хочешь посмотреть сорц функции из стандартной либы? Хочешь автозаполнение? Хочешь форматировать код кнопкой, а не руками? Так пиши скрипты под блокнот. Только потом не пизди, что у тебя блокнот открывает один файл больше часа.
Потому что это не текстовый редактор. Хочешь текстовый редактор? Вперёд, пиши свои маняпрожекты в блокноте, хуле. Что-что? Нет выделения синтаксиса? Хочешь посмотреть сорц функции из стандартной либы? Хочешь автозаполнение? Хочешь форматировать код кнопкой, а не руками? Так пиши скрипты под блокнот. Только потом не пизди, что у тебя блокнот открывает один файл больше часа.
>>480744
Манятеории откуда-то из 90-х. Проще научиться писать иммутабельный код на нормальном языке, чем брать функциональный язык ради такой мелочи, как ключевое слово const.
Вообще основное достоинство того же хаскеля, это не иммутабельность и ленивость, а система типов.
Манятеории откуда-то из 90-х. Проще научиться писать иммутабельный код на нормальном языке, чем брать функциональный язык ради такой мелочи, как ключевое слово const.
Вообще основное достоинство того же хаскеля, это не иммутабельность и ленивость, а система типов.
>>477771
Редух твой умрёт скоро, потому что есть божественный Mobx, который позволяет написать тот же самый функционал намного проще, быстрее и понятнее. А редух со своей тонной бойлерпрейта идёт нахуй.
Редух твой умрёт скоро, потому что есть божественный Mobx, который позволяет написать тот же самый функционал намного проще, быстрее и понятнее. А редух со своей тонной бойлерпрейта идёт нахуй.
>>484271
Значит не все включил. Или у нас разные пороги раздражения от латентности редактора.
Значит не все включил. Или у нас разные пороги раздражения от латентности редактора.
>>477327 (OP)
Потому что джава сегодня это практически сетевая преблуда, где сама джава может прогреться. А не прогретая джава, тормозит. И удивительно что её выбрали для IDE.
Ну еще кривое программирование на жабе никто не отменял, где абстракция абстракцией погоняется
Потому что джава сегодня это практически сетевая преблуда, где сама джава может прогреться. А не прогретая джава, тормозит. И удивительно что её выбрали для IDE.
Ну еще кривое программирование на жабе никто не отменял, где абстракция абстракцией погоняется
>>480744
Односвязный список не сделать?
Ну в каком-нибудь js есть Object.freeze. И всё нормально.
А вот работать с vector'ами в haskell'е, это уже одно страдание.
>В языке с мутабельностью такого не сделать
Односвязный список не сделать?
>В языке с мутабельностью
Ну в каком-нибудь js есть Object.freeze. И всё нормально.
А вот работать с vector'ами в haskell'е, это уже одно страдание.
>>484411
С чего это?
Покажи хотя бы кусок кода где ты с ними страдал
>А вот работать с vector'ами в haskell'е, это уже одно страдание.
С чего это?
Покажи хотя бы кусок кода где ты с ними страдал
>>484266
Тут вроде речь идет о реальных продакшен-языках, а не гиммиках для выебонов.
>>484411
Ну делай, только нахуя кусать локти и бороться с языком? ЖС - это кривой-косой, но ОО-язык в первую очередь. Разумеется там можно и нужно использовать элементы ФП(как и в любом ОО-языке и наоборот), но если пытаться писать на нем в фул-ФП стиле, то это контр-продуктивный долбоебизм.
>того же хаскеля
Тут вроде речь идет о реальных продакшен-языках, а не гиммиках для выебонов.
>>484411
Ну делай, только нахуя кусать локти и бороться с языком? ЖС - это кривой-косой, но ОО-язык в первую очередь. Разумеется там можно и нужно использовать элементы ФП(как и в любом ОО-языке и наоборот), но если пытаться писать на нем в фул-ФП стиле, то это контр-продуктивный долбоебизм.
>>484447
В этих языках и честной иммутабельности нет
>Тут вроде речь идет о реальных продакшен-языках, а не гиммиках для выебонов.
В этих языках и честной иммутабельности нет
>>484426
https://lmgtfy.com/?q=haskell+mutable+vector+example
Односвязный список - это не борьба с языком. А js просто из-за Object.freeze пример.
https://lmgtfy.com/?q=haskell+mutable+vector+example
>только нахуя кусать локти и бороться с языком
Односвязный список - это не борьба с языком. А js просто из-за Object.freeze пример.
>>484474
То есть фризить каждый объект и делать свою реализацию списков - это не борьба с языком? И это далеко не единственные вещи, которые тебе придется сделать, но все равно не приблизишься к уровню любого современного ФП-языка по удобству. Так что зачем? Никаких ощутимых плюсов в читабельность и размер кода это не дает(особенно если использовать манябиблиотеки и/или собранный на коленке API повсюду) Если пишешь в браузер без возможности выбрать язык, то там на асинхронность и мутабельность по большему счету поебать, базовые вещи есть и ладно. А если не в браузер, то нахуя ты используешь жс в принципе?
То есть фризить каждый объект и делать свою реализацию списков - это не борьба с языком? И это далеко не единственные вещи, которые тебе придется сделать, но все равно не приблизишься к уровню любого современного ФП-языка по удобству. Так что зачем? Никаких ощутимых плюсов в читабельность и размер кода это не дает(особенно если использовать манябиблиотеки и/или собранный на коленке API повсюду) Если пишешь в браузер без возможности выбрать язык, то там на асинхронность и мутабельность по большему счету поебать, базовые вещи есть и ладно. А если не в браузер, то нахуя ты используешь жс в принципе?
>>484479
На фоне монады ST - нет. И да, если в императивном языке есть нормально работающий const / final, то и фризить ничего не придётся.
>То есть фризить каждый объект и делать свою реализацию списков - это не борьба с языком
На фоне монады ST - нет. И да, если в императивном языке есть нормально работающий const / final, то и фризить ничего не придётся.
>>484551
В том то и дело, что нужны были мутабельные ram вектора
В том то и дело, что нужны были мутабельные ram вектора
145 Кб, 569x651>>477327 (OP)
Хули на машинных кодах не пишешь сразу тогда, долбоеб. Само программирование это уже абстракция, и чем выше уровень тем лучше.
Хули на машинных кодах не пишешь сразу тогда, долбоеб. Само программирование это уже абстракция, и чем выше уровень тем лучше.
>>484754
пишу что ты дебил
пишу что ты дебил
>>477327 (OP)
Подожди, ты действительно настолько даун, что думаешь, что при работе с иммутабельными структурами данные будут копироваться?
Подожди, ты действительно настолько даун, что думаешь, что при работе с иммутабельными структурами данные будут копироваться?
>>480746
Есть такая порода людей, которая считает, что каждый, кто на что-то претендует, просто обязан хлебнуть говна. Например, "настоящий мужчина" обязан сходить в армию или отсидеть в тюрьме, ведь что тюрьма, что армия - школа жизни; "настоящий программист" обязан писать на крестах, жабе, ПХП или тому подобном, ведь сами они на нём писали, а кто не хапнул этого говна, тот и не программист вовсе. С одной стороны понять их можно - механизм примерно такой же как у дедовщины в уже упомянутой армии или прописки на малолетке ("меня опускали, теперь я буду опускать" - ну просто обучение и сделование паттерну, через пиздюли навязанному авторитетом, детская психика так устроена), с другой - сами они со временем так нихуя и не понимают, и любые попытки объяснить им, что все эти боль и унижения, через которые они прошли, в общем-то лишние, встречают у них агрессию и отрицание.
Есть такая порода людей, которая считает, что каждый, кто на что-то претендует, просто обязан хлебнуть говна. Например, "настоящий мужчина" обязан сходить в армию или отсидеть в тюрьме, ведь что тюрьма, что армия - школа жизни; "настоящий программист" обязан писать на крестах, жабе, ПХП или тому подобном, ведь сами они на нём писали, а кто не хапнул этого говна, тот и не программист вовсе. С одной стороны понять их можно - механизм примерно такой же как у дедовщины в уже упомянутой армии или прописки на малолетке ("меня опускали, теперь я буду опускать" - ну просто обучение и сделование паттерну, через пиздюли навязанному авторитетом, детская психика так устроена), с другой - сами они со временем так нихуя и не понимают, и любые попытки объяснить им, что все эти боль и унижения, через которые они прошли, в общем-то лишние, встречают у них агрессию и отрицание.
>>484813
Выговорился? А теперь марш спать, завтра ведь крудики опять лепить на твоей любимой рельсе/фласке/очередном макака-фреймворке.
Выговорился? А теперь марш спать, завтра ведь крудики опять лепить на твоей любимой рельсе/фласке/очередном макака-фреймворке.
>>484836
Ну, в той же ржавчине просто переназначается указатель, если ты пишешь какое-нибудь
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 s = String::new();
let mut s1 = s;
Теперь указатель 's' не сработает, а сработает только 's1'. А копирует структуру полностью только
let mut s1 = s.clone();
Смысл в том, что тому, кто будет это читать, будет сразу понятно, что 's' нигде не меняется, пока не станет 's1'. И можно не гадать, будет ли это тот же самый 's' после какого-нибудь
s.make_strange_shit_with_self();
>>484867
Ну и да, забыл добавить, что вся эта иммутабельность бесплатная, потому что это тупо ограничение на уровне компилятора. То есть, ты можешь хоть все свои "let" переменные ебануть мутабельными, компилятор тебе просто варнинг выпишет, что их можно и не делать мутабельными; но если ты "let" без "mut" попытаешься изменить, то там уже ошибка, но не ошибка кода, а ошибка компилятора. Так что да, современные макаки от кодинга просто обленились, поэтому топят за иммутабельность. А так никакой разницы нет.
Ну и да, забыл добавить, что вся эта иммутабельность бесплатная, потому что это тупо ограничение на уровне компилятора. То есть, ты можешь хоть все свои "let" переменные ебануть мутабельными, компилятор тебе просто варнинг выпишет, что их можно и не делать мутабельными; но если ты "let" без "mut" попытаешься изменить, то там уже ошибка, но не ошибка кода, а ошибка компилятора. Так что да, современные макаки от кодинга просто обленились, поэтому топят за иммутабельность. А так никакой разницы нет.
>>484914
пашол нахуй
пашол нахуй
>>484914
> синтаксис уёбищный
> лучше в 1С писать, там же вообще русские слова
> или в Brainfuck, там вообще божественный синтаксис
>>484933
Навернул говница
Навернул говница
>>484933
Твоя хуета не сконпелируется. Никак. Потому что после let mut требуется имя переменной. С тем же успехом я могу скорчить брейнлета и написать тебе, что запилить изначально константную переменную, а потом пустить её по const_cast в крестах — это нормально.
Твоя хуета не сконпелируется. Никак. Потому что после let mut требуется имя переменной. С тем же успехом я могу скорчить брейнлета и написать тебе, что запилить изначально константную переменную, а потом пустить её по const_cast в крестах — это нормально.
>>484933
Вот только кресты тебе дадут ебануть UB таким >>484960 образом, а ржавый уёбищный синтаксис идёт в коробке с языком, который пытается избавлться от UB вообще везде, пока кресты их плодят. В итоге запомнить один раз все эти спецификаторы и страшные дженерики-трейты-лайфтаймы-енамы проще, чем каждый раз ебать себе мозг вопросами "эта хуета UB или не UB?"
Вот только кресты тебе дадут ебануть UB таким >>484960 образом, а ржавый уёбищный синтаксис идёт в коробке с языком, который пытается избавлться от UB вообще везде, пока кресты их плодят. В итоге запомнить один раз все эти спецификаторы и страшные дженерики-трейты-лайфтаймы-енамы проще, чем каждый раз ебать себе мозг вопросами "эта хуета UB или не UB?"
>>485463
Макак не умеет в fmap, сразу язык виноват.
Макак не умеет в fmap, сразу язык виноват.
>>484836
ОП, судя по посту, считает что копируется и не приводит никаких пруфов.
Посмотри код GHC, и принеси мне пример с копированием.
ОП, судя по посту, считает что копируется и не приводит никаких пруфов.
Посмотри код GHC, и принеси мне пример с копированием.
>>478194
Главный секрет ДоД, про который молчат проповедники - это то, что оно не совместимо с архитектурой. На ходовых языках просто удобные абстракции не построить под него. Единственный выход - кодить под задачу at hand массивами как диды на Фортране. Такой подход далеко не везде применим, но он единственный, который реально работает.
>чем человекочасы, потраченные на еблю с АрХиТеКтУрОй
Главный секрет ДоД, про который молчат проповедники - это то, что оно не совместимо с архитектурой. На ходовых языках просто удобные абстракции не построить под него. Единственный выход - кодить под задачу at hand массивами как диды на Фортране. Такой подход далеко не везде применим, но он единственный, который реально работает.
>>485801
У него какой-то jvm язык в ОП-посте. Там они, естественно, копируются тупо потому что value-типов не завезли.
>ОП, судя по посту, считает что копируется и не приводит никаких пруфов.
У него какой-то jvm язык в ОП-посте. Там они, естественно, копируются тупо потому что value-типов не завезли.
22 Кб, 300x250Попался на кручок деплоя реакт гавна которое оказалось полностью поломано и нужно переписывать половину репы
А вы что делаете?
уже не вижу в какие трежы пишу
А вы что делаете?
уже не вижу в какие трежы пишу
>>485887
бля 2 раза промахнулся
бля 2 раза промахнулся
>>477327 (OP)
Ага, вот например код контроллера двигателя тойоты — 10K глобальных переменных, очевидно, никакой иммутабельности и прочих ненужных абстракций, сплошная байтоебля и ламповое изменение переменных как ты любишь.
Зато машина ускоряется, когда жмешь на тормоз.
http://www.safetyresearch.net/blog/articles/toyota-unintended-acceleration-and-big-bowl-“spaghetti”-code
https://news.ycombinator.com/item?id=9643551
> Зато (((иммутабельность))) Типа трушность. При этом количество забагованнного говна только растет.
Ага, вот например код контроллера двигателя тойоты — 10K глобальных переменных, очевидно, никакой иммутабельности и прочих ненужных абстракций, сплошная байтоебля и ламповое изменение переменных как ты любишь.
Зато машина ускоряется, когда жмешь на тормоз.
http://www.safetyresearch.net/blog/articles/toyota-unintended-acceleration-and-big-bowl-“spaghetti”-code
https://news.ycombinator.com/item?id=9643551
>>485899
Очевидно она ускоряется только если тормоз жмёт гайдзин.
Очевидно она ускоряется только если тормоз жмёт гайдзин.
>>484867
Растодебилы настолько тупые, что в своем собственном языке не разбираются
>что такое move semantics
Растодебилы настолько тупые, что в своем собственном языке не разбираются
>>485943
Ебать, в каком месте там ошибка?
Ебать, в каком месте там ошибка?
>>477327 (OP)
ого я что на /pol/ кукчана?
ого я что на /pol/ кукчана?
>>485899
Ну было бы у них 1000 иммутабельных классов с лапшой и пауками, думаешь лучше бы было? Там явно проблема в организации процесса, а не в языке.
Ну было бы у них 1000 иммутабельных классов с лапшой и пауками, думаешь лучше бы было? Там явно проблема в организации процесса, а не в языке.
>>485899
Очевидно, что проблема тут в глобальных переменных, а не иммутабельности.
Очевидно, что проблема тут в глобальных переменных, а не иммутабельности.
Функциональщики не понимают, что стейт зачастую - это наилучшее и простейшее представление предметной области.
В итоге изобретают конструкции вида
new_yoba = f(old_yoba), всякие FRP и продьюсеры-консьюмеры, прячат их в монады и радуются, что у них стейта нету.
В итоге изобретают конструкции вида
new_yoba = f(old_yoba), всякие FRP и продьюсеры-консьюмеры, прячат их в монады и радуются, что у них стейта нету.
>>486019
Суть функциональщины на практике не в том, что стейта нету совсем, а в том, что весь стейт изолирован и является исключением, а не правилом.
Суть функциональщины на практике не в том, что стейта нету совсем, а в том, что весь стейт изолирован и является исключением, а не правилом.
>>486017
Ты считаешь, что от разбиения переменных на классы, количество состояний программы магически уменьшится?
Ты считаешь, что от разбиения переменных на классы, количество состояний программы магически уменьшится?
>>486115
В программе без данных действительно все просто и понятно. Только бесполезно.
>стейт является исключением, а не правилом
В программе без данных действительно все просто и понятно. Только бесполезно.
>>486220
На иммутабельные? Как запустил, их состояние больше не меняется. И да, следить за состоянием, спратанным, в монадах таки проще.
На иммутабельные? Как запустил, их состояние больше не меняется. И да, следить за состоянием, спратанным, в монадах таки проще.
>>486220
Ну, простейший тебе пример.
Говно:
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 не совпадала, а в первом вообще минное поле.
>>486223
Данные и стейт это разные вещи
Ну, простейший тебе пример.
Говно:
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 не совпадала, а в первом вообще минное поле.
>>486223
Данные и стейт это разные вещи
>>479726
Охуел, чтоле сука?
С каких это пор такой код (на некотором абсрактном языке, поддерживающем 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;
}
В первом случае ты прямо записал определение, во втором тебе приходится городить какую-то хуйню с присваиваниями и разворачивать цикл в уме, если надо отдебажить что-то более сложное.
Охуел, чтоле сука?
С каких это пор такой код (на некотором абсрактном языке, поддерживающем 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;
}
В первом случае ты прямо записал определение, во втором тебе приходится городить какую-то хуйню с присваиваниями и разворачивать цикл в уме, если надо отдебажить что-то более сложное.
>>486341
Наркоман? Любой цикл как раз читается сверху вниз, а вот рекурсию надо разворачивать в уме. Как только она станет сложнее, чем в дегенеративном примере из книжки, то ты сразу охуеешь это поддерживать и разбирать.
Наркоман? Любой цикл как раз читается сверху вниз, а вот рекурсию надо разворачивать в уме. Как только она станет сложнее, чем в дегенеративном примере из книжки, то ты сразу охуеешь это поддерживать и разбирать.
>>486297
А функции нельзя так сделать? В чем эта чрезвычайная сложность?
>А разница в том, что классы можно сделать так, чтобы они автоматически следили за инвариантами в коде
А функции нельзя так сделать? В чем эта чрезвычайная сложность?
>>486297
И в чем разница? В твоем примере points - это данные или стейт?
>Данные и стейт это разные вещи
И в чем разница? В твоем примере points - это данные или стейт?
>>486372
В теории, это одно и то же, как адрес и значение ничем принципиальным не различаются. Но в ФП принято эти вещи различать. Стейт не изменяется, какие бы ты данные не ввёл, то есть, если ты вводишь тысячу различных инпутов, то если потом опять ввести идентичный первому инпут, то ты и выход получишь идентичный первому.
В теории, это одно и то же, как адрес и значение ничем принципиальным не различаются. Но в ФП принято эти вещи различать. Стейт не изменяется, какие бы ты данные не ввёл, то есть, если ты вводишь тысячу различных инпутов, то если потом опять ввести идентичный первому инпут, то ты и выход получишь идентичный первому.
>>486393
Ну да. Вот эти вот функции, которые ты вызываешь на свой инпут — они и есть стейт. Что бы ты не ввёл, функция "прибавить_два" всегда прибавит два.
Ну да. Вот эти вот функции, которые ты вызываешь на свой инпут — они и есть стейт. Что бы ты не ввёл, функция "прибавить_два" всегда прибавит два.
>>486395
Что тогда значит "изолировать стейт"?
>Вот эти вот функции, которые ты вызываешь на свой инпут — они и есть стейт
Что тогда значит "изолировать стейт"?
>>486395
сука, я понял кто это - это борщехлеб из сикп треда!
Я узнал его по ебанутой аргументации превосходства ФП!
В ООП метод класса который прибавляет два тоже всегда прибавляет два.
Вот это охуеть, вот это прорыв.
сука, я понял кто это - это борщехлеб из сикп треда!
Я узнал его по ебанутой аргументации превосходства ФП!
В ООП метод класса который прибавляет два тоже всегда прибавляет два.
Вот это охуеть, вот это прорыв.
>>486395
Ты же говорил, что стейт - это данные. Теперь стейт - это функции? Как в лиспе "код - это данные"?
Ты же говорил, что стейт - это данные. Теперь стейт - это функции? Как в лиспе "код - это данные"?
>>486405
Я не аргументирую за ФП, я просто рассказываю, как ФПшеры думают.
Я не аргументирую за ФП, я просто рассказываю, как ФПшеры думают.
>>486413
Тем, что данные нельзя исполнять, если у тебя не микроконтроллер без защиты памяти.
Тем, что данные нельзя исполнять, если у тебя не микроконтроллер без защиты памяти.
test
>>486417
Со стейтом та же хуйня. Он не изменяется в функциональных языках, пока ты его не поменяешь извне, то есть, пока ты не впишешь какую-нибудь функцию в код. А твои императивные — это как раз такая штука без защиты памяти.
Чистая функциональщина гарантирует, что твой выход зависит только от входа. А вот в императивных какой-нибудь забытый указатель из другого потока может ВНЕЗАПНО изменить твой выход.
Со стейтом та же хуйня. Он не изменяется в функциональных языках, пока ты его не поменяешь извне, то есть, пока ты не впишешь какую-нибудь функцию в код. А твои императивные — это как раз такая штука без защиты памяти.
Чистая функциональщина гарантирует, что твой выход зависит только от входа. А вот в императивных какой-нибудь забытый указатель из другого потока может ВНЕЗАПНО изменить твой выход.
>>486440
Читай внимательнее:
Читай внимательнее:
> Стейт не изменится пока ты не изменишь код: один поток никогда не изменит данные другого потока СЛУЧАЙНЫМ образом, да и неслучайным обычно не меняет.
> В императивных языках забытый указатель может ВНЕЗАПНО изменить данные в другом потоке и вообще где угодно.
>>486450
В ФП надо в функциональной лапше разбираться, которая не гарантирует невозможность аналогичного обсера.
Есть нормальные аргументы?
>висячий указатель ряяя
В ФП надо в функциональной лапше разбираться, которая не гарантирует невозможность аналогичного обсера.
Есть нормальные аргументы?
>>486468
Да, не гарантирует, но если ты обосрался в ФП, ты сразу видишь, в какой строчке; в императивном ты этого увидеть не можешь. Плюсы ФП иди сам гугли, тебе всякие статьи повываливаются про мультипоточность и обновление без остановки машины.
Да, не гарантирует, но если ты обосрался в ФП, ты сразу видишь, в какой строчке; в императивном ты этого увидеть не можешь. Плюсы ФП иди сам гугли, тебе всякие статьи повываливаются про мультипоточность и обновление без остановки машины.
>>486371
Я отвечал на вопрос "Ты считаешь, что от разбиения переменных на классы, количество состояний программы магически уменьшится?". Уменьшится, за счет того, что класс уменьшает количество степеней свободы.
>>486372
Учитывая какой вопрос я отвечал, points - это глобальные переменные, т.е. стейт.
А разница в том, что стейт ты меняешь, когда видишь оператор присваивания (не путать с инициализацией). Нет присваивания - стейт не меняется.
>А функции нельзя так сделать? В чем эта чрезвычайная сложность?
Я отвечал на вопрос "Ты считаешь, что от разбиения переменных на классы, количество состояний программы магически уменьшится?". Уменьшится, за счет того, что класс уменьшает количество степеней свободы.
>>486372
>И в чем разница? В твоем примере points - это данные или стейт?
Учитывая какой вопрос я отвечал, points - это глобальные переменные, т.е. стейт.
А разница в том, что стейт ты меняешь, когда видишь оператор присваивания (не путать с инициализацией). Нет присваивания - стейт не меняется.
>>486483
HotSwap
HotSwap
>>148648может пример кода покажешь или так и будешь баззвордами кидаться?
>>486482
С чего это? Почему у класса с 1000 полей будет меньше состояний, чем у 1000 переменных?
>Уменьшится, за счет того, что класс уменьшает количество степеней свободы.
С чего это? Почему у класса с 1000 полей будет меньше состояний, чем у 1000 переменных?
>>486661
например, за счет того, что класс может не дать тебе менять ни одну из них
про инкапсуляцию ты не слыхал, поэтому и срешь тут тупым говном.
например, за счет того, что класс может не дать тебе менять ни одну из них
про инкапсуляцию ты не слыхал, поэтому и срешь тут тупым говном.
2 Мб, 1920x1080>>477327 (OP)
Нет никакого оверхеда.
Если это простые переменные то это мизер памяти и стек. Зато хуйню в расчётах не сделаешь.
Делать все-всё иммутабельным конечно бессмысленно и глупо, а работает это особенно хорошо в случае параллельного доступа к объектам.
Нужно использовать то и тогда когда это разумно.
Немного необычный пример иммутабельности - двойная буферизация в графике.
Тут понятно зачем оно нужно?
>Ну и наконец в-третьих. Гигантский оверхед на создание памяти, аллокацию, отслеживание неактуальных ссылок.
Нет никакого оверхеда.
Если это простые переменные то это мизер памяти и стек. Зато хуйню в расчётах не сделаешь.
Делать все-всё иммутабельным конечно бессмысленно и глупо, а работает это особенно хорошо в случае параллельного доступа к объектам.
Нужно использовать то и тогда когда это разумно.
Немного необычный пример иммутабельности - двойная буферизация в графике.
Тут понятно зачем оно нужно?
879 Кб, 1916x1926>>479726
Он не в процедурный цикл оптимизируется.
Процедурный цикл по типу фор менее эффективен, не говоря уже о читабельности хтонической хуйни из вложенный циклов и аккумуляторов.
>Так в этом и суть, если конкретный код с рекурсией легко оптимизируется в цикл, то пиши его сразу циклом, тебе потом спасибо скажут, когда будут читать код.
Он не в процедурный цикл оптимизируется.
Процедурный цикл по типу фор менее эффективен, не говоря уже о читабельности хтонической хуйни из вложенный циклов и аккумуляторов.
>>486715
А если нет оптимизации tail-call'а? Передавать N аргументов в каждую итерацию рекурсии? Даже если они будут из одной буквы, это пиздец дохуя места занимает. А в озаloopленном виде это всё не в одну строчку и нормально читается.
А если нет оптимизации tail-call'а? Передавать N аргументов в каждую итерацию рекурсии? Даже если они будут из одной буквы, это пиздец дохуя места занимает. А в озаloopленном виде это всё не в одну строчку и нормально читается.
>>486715
Какая разница? Внутри ФП языков рекурсия почти всегда менее эффективна и читаема, чем аналог из (ФП) цикла и ее рекомендуется избегать, где можно. erlang/elixir/clojure в пример.
Какая разница? Внутри ФП языков рекурсия почти всегда менее эффективна и читаема, чем аналог из (ФП) цикла и ее рекомендуется избегать, где можно. erlang/elixir/clojure в пример.
Какой оп дурачок, это нечто. Учёные, мол, насочиняли всякой ерунды, то ли дело программисты-практики.
В ходе развития функциональных языков вроде Lisp теоретики обсуждали преимущества чистых функций, иммутабельности и прочих ныне модных штук.
Параллельно в бородатые годы суровые байтослесари на Форте пришли к аналогичной идее, но не теоретически, а чисто из практики. Так называемые "тупые" слова - это конкатенативные аналоги чистых функций.
И теория, и практика пришла к одному и тому же. Фортер в 80-х годах бы сказал: вот я определяю несколько переменных, в которых хранится состояние, и определяю слова (читай - функции) для работы с ними; затем я определяю новые тупые слова для работы с ними, причём то, что они выдают на стек, зависит только от входных аргументов на стеке. Эти слова отлаживаются, убедиться в корректности их работы не трудно, их легко тестировать по-отдельности. Далее с помощью этих проблемно-ориентированных слов решается задача. Ничего не напоминает?
В ходе развития функциональных языков вроде Lisp теоретики обсуждали преимущества чистых функций, иммутабельности и прочих ныне модных штук.
Параллельно в бородатые годы суровые байтослесари на Форте пришли к аналогичной идее, но не теоретически, а чисто из практики. Так называемые "тупые" слова - это конкатенативные аналоги чистых функций.
И теория, и практика пришла к одному и тому же. Фортер в 80-х годах бы сказал: вот я определяю несколько переменных, в которых хранится состояние, и определяю слова (читай - функции) для работы с ними; затем я определяю новые тупые слова для работы с ними, причём то, что они выдают на стек, зависит только от входных аргументов на стеке. Эти слова отлаживаются, убедиться в корректности их работы не трудно, их легко тестировать по-отдельности. Далее с помощью этих проблемно-ориентированных слов решается задача. Ничего не напоминает?
53 Кб, 500x500ОП — тупой зумерок-смузихлёб, не осиливший функциональное программирование. Айсикью ниже трехзначного конфирмед. Пссссс на ОПа, окропил уринушкой.
К ФП-дебилам приопдинилприсоединиласьась аватаватаркасрка и зумер, которы сясчитаетитапт FORTH функциональным языком, но конкретных примеров кода где иммутаьельность и фп уделывает мутабельную императивку всё ещё не завезли.
>>486845
Ты задницей по клавиатуре что ли юлозишь?
Forth - не целиком функциональный язык в современном понимании, но на нём можно и нужно писать в функциональном стиле. Выглядит, правда, это очень странно, потому что у языка довольно низкий уровень.
Ты задницей по клавиатуре что ли юлозишь?
>которы сясчитаетитапт FORTH функциональным языком
Forth - не целиком функциональный язык в современном понимании, но на нём можно и нужно писать в функциональном стиле. Выглядит, правда, это очень странно, потому что у языка довольно низкий уровень.
>>486369
Нахуя рекурсию разворачивать? Рекурсивная запись - это прямой перевод формулировки исходной задачи на целевой язык программирования, короче говоря, рекурсия декларативна. Если тебе надо разворачивать рекурсию, то ты делаешь что-то неправильно. А вот цикл - это последовательность действий с изменяемым состоянием, за которым надо постоянно глаз да глаз.
Нахуя рекурсию разворачивать? Рекурсивная запись - это прямой перевод формулировки исходной задачи на целевой язык программирования, короче говоря, рекурсия декларативна. Если тебе надо разворачивать рекурсию, то ты делаешь что-то неправильно. А вот цикл - это последовательность действий с изменяемым состоянием, за которым надо постоянно глаз да глаз.
>>486480
Эрланг тоже на такое не способен. Виртуальную машину останавливать действительно не надо, а вот дерево процессов очень даже надо, если обновление не является тривиальным.
>Кто на такое кроме эрланга способен?
Эрланг тоже на такое не способен. Виртуальную машину останавливать действительно не надо, а вот дерево процессов очень даже надо, если обновление не является тривиальным.
>>486852
Ебать вы кукаретики. На форте невозможно писать в функциональном стиле. Хотя бы потому, что через стек ты иммутабельную структуру не передашь, туда можно класть только инты и флоаты.
Форт, наоборот, максимум стейтфул фигня, переменные там используются очень часто, потому что с одним (тремя на самом деле) стеком ты далеко не уедешь. Плюс все переменные фактически глобальные, хотя есть и инкапсуляция, а в некоторых фортах - локальные переменные.
>но на нём можно и нужно писать в функциональном стиле
Ебать вы кукаретики. На форте невозможно писать в функциональном стиле. Хотя бы потому, что через стек ты иммутабельную структуру не передашь, туда можно класть только инты и флоаты.
Форт, наоборот, максимум стейтфул фигня, переменные там используются очень часто, потому что с одним (тремя на самом деле) стеком ты далеко не уедешь. Плюс все переменные фактически глобальные, хотя есть и инкапсуляция, а в некоторых фортах - локальные переменные.
4,9 Мб, 2560x1600>>486771
Тогда не делай рекурсию кроме случаев когда это действительно делает код наглядным и гарантированно не переполняет стек.
>>486781
Еще раз, рекурсия разворачивается в джампы, она не разворачивается в процедурные циклы. Иногда это даёт измеримый прирост производительности.
А с внешней точки зрения, многие алгоритмы нагляднее и понятнее в рекурсивной форме. Это бессмысленно тут объяснять, нужно самому пробовать. В случае с процедурными циклами тебе нужно сохранять кучу мутабельных состояний.
Если ты никогда хоть немного сложные алгоритмы, вроде обхода дерева, не реализовывал, то попробуй челе.
Что ты подразумеваешь под "чтение внутри ФП языка" ?
>А если нет оптимизации tail-call'а?
Тогда не делай рекурсию кроме случаев когда это действительно делает код наглядным и гарантированно не переполняет стек.
>>486781
>Какая разница?
Еще раз, рекурсия разворачивается в джампы, она не разворачивается в процедурные циклы. Иногда это даёт измеримый прирост производительности.
А с внешней точки зрения, многие алгоритмы нагляднее и понятнее в рекурсивной форме. Это бессмысленно тут объяснять, нужно самому пробовать. В случае с процедурными циклами тебе нужно сохранять кучу мутабельных состояний.
Если ты никогда хоть немного сложные алгоритмы, вроде обхода дерева, не реализовывал, то попробуй челе.
>Внутри ФП языков рекурсия почти всегда менее эффективна и читаема
Что ты подразумеваешь под "чтение внутри ФП языка" ?
>>486791
Проклятая жвм мешает производить TCO, мешает оптимизировать рекурсию в цикл и вообще говна в жопу заливает? Расскажи, интересно.
HOF предпочтительнее рекурсий и даже быстрее(хоть и незначительно)
>>486890>>486949
Интересные истории, но вам надо пойти поработать с этим на практике, а не цитировать манямир из учебника по CS в каждом посте. И я не спорю, манямир очень привлекательный и логичный, но разбивается, когда приходится писать/читать сложную рекурсивную функцию, которая обрабатывает реальную логику в приложении, а не доказанные заранее на бумажке математические алгоритмы.
>JVM
Проклятая жвм мешает производить TCO, мешает оптимизировать рекурсию в цикл и вообще говна в жопу заливает? Расскажи, интересно.
>с эрлангом
HOF предпочтительнее рекурсий и даже быстрее(хоть и незначительно)
>>486890>>486949
Интересные истории, но вам надо пойти поработать с этим на практике, а не цитировать манямир из учебника по CS в каждом посте. И я не спорю, манямир очень привлекательный и логичный, но разбивается, когда приходится писать/читать сложную рекурсивную функцию, которая обрабатывает реальную логику в приложении, а не доказанные заранее на бумажке математические алгоритмы.
>>486950
Учебник по CS говорит несколько вещей
1. goto - плохо
2. tail call ничем не отличается от goto по выразительности
3. в ФП нужно комбинировать комбинаторы, чтобы голые tail call'ы никто не видел
Если человек не знает п. 3, он не знает именно теории
Учебник по CS говорит несколько вещей
1. goto - плохо
2. tail call ничем не отличается от goto по выразительности
3. в ФП нужно комбинировать комбинаторы, чтобы голые tail call'ы никто не видел
Если человек не знает п. 3, он не знает именно теории
>>486955
Отличный совет, только теперь TCO сломалась в 99% языков. Но зато теорию соблюли.
>в ФП нужно комбинировать комбинаторы, чтобы голые tail call'ы никто не видел
Отличный совет, только теперь TCO сломалась в 99% языков. Но зато теорию соблюли.
1,3 Мб, 1200x1014>>486950
Так все же пишут рекурсивные функции в реальном мире?
И в чем проблема?
Лапшу из вложенных форов с мутабелными состояниями разделяемыми на всех уровнях вложенности проще читать\писать?
В твоём реальном мире бизнес логику придумывают налёту? Я молчу про бизнес аналитиков там, не удосужившись убедиться в работе математических формул?
>но разбивается, когда приходится писать/читать сложную рекурсивную функцию, которая обрабатывает реальную логику в приложении
Так все же пишут рекурсивные функции в реальном мире?
И в чем проблема?
Лапшу из вложенных форов с мутабелными состояниями разделяемыми на всех уровнях вложенности проще читать\писать?
> не доказанные заранее на бумажке математические алгоритмы
В твоём реальном мире бизнес логику придумывают налёту? Я молчу про бизнес аналитиков там, не удосужившись убедиться в работе математических формул?
>>486980
Лапша из вложенных форов будет выглядеть в сто раз хуже в виде аналогичной лапши из рекурсии. И никто не мешает тебе вынести вложенный фор в отдельную функцию.
В моем реальном мире бизнес логику, как и верность работы компьютерной программы доказать в математическом понимании нельзя, ее можно только протестировать(поставить эксперимент). А эксперименты как известно не могут доказать теорию, только ее опровергнуть.
>Лапшу из вложенных форов с мутабелными состояниями
Лапша из вложенных форов будет выглядеть в сто раз хуже в виде аналогичной лапши из рекурсии. И никто не мешает тебе вынести вложенный фор в отдельную функцию.
>В твоём реальном мире бизнес логику придумывают налёту
В моем реальном мире бизнес логику, как и верность работы компьютерной программы доказать в математическом понимании нельзя, ее можно только протестировать(поставить эксперимент). А эксперименты как известно не могут доказать теорию, только ее опровергнуть.
>>486988
Этот парень шарит.
>А эксперименты как известно не могут доказать теорию, только ее опровергнуть.
Этот парень шарит.
>>486988
Чушь спизданул. Эксперименты доказывают, или опровергают гипотезы. Теория - это доказанная экспериментом гипотеза.
Если весь твой код - это гипотеза, а не теория, то у меня для тебя плохие новости.
>А эксперименты как известно не могут доказать теорию, только ее опровергнуть.
Чушь спизданул. Эксперименты доказывают, или опровергают гипотезы. Теория - это доказанная экспериментом гипотеза.
Если весь твой код - это гипотеза, а не теория, то у меня для тебя плохие новости.
68 Кб, mp4,240x320, 0:01
>>486988
Анус ставишь?
Ты наверное не знаешь, но формулы которые ты кодишь делают умные дяди с учёными степенями которые, внезапно, доказывают их корректность по самым разным критериям.
Впрочем может конкретно тебя и не пускают к такой вот логике.
Внезапно, можно, у тебя какой-то мир не реальный, а выдуманный. Есть для этого специальный инструменты, и даже специальные ЯП.
Ты теперь уже просто чушь несёшь.
Я так понимаю твою позицию:
Я тебя правильно понимаю?
>Лапша из вложенных форов будет выглядеть в сто раз хуже в виде аналогичной лапши из рекурсии.
Анус ставишь?
>В моем реальном мире бизнес логику, как и верность работы компьютерной программы доказать в математическом понимании нельзя
Ты наверное не знаешь, но формулы которые ты кодишь делают умные дяди с учёными степенями которые, внезапно, доказывают их корректность по самым разным критериям.
Впрочем может конкретно тебя и не пускают к такой вот логике.
>верность работы компьютерной программы доказать в математическом понимании нельзя
Внезапно, можно, у тебя какой-то мир не реальный, а выдуманный. Есть для этого специальный инструменты, и даже специальные ЯП.
>А эксперименты как известно не могут доказать теорию, только ее опровергнуть.
Ты теперь уже просто чушь несёшь.
Я так понимаю твою позицию:
>программист = машинистка, и нечего мудрить, а кто мудрит тот манятеоретик очкастый
Я тебя правильно понимаю?
>>486996
https://ru.wikipedia.org/wiki/Фальсифицируемость
Он это имеет ввиду.
Эксперимент не может доказать гипотезу, потому что эксперимент, как правило, покрывает относительно небольшое количество кейсов. Поэтому можно только провести эксперимент, сказать "ок, пока будем считать, что это так", если результаты подтверждают гипотезу, но в будущем, любой другой эксперимент, покрывающий другое множество кейсов, может теорию опровергнуть.
В программировании никто не доказывает корректность программы формально. Обычно тестируют программу (или ее часть) на небольшом множестве инпутов, проверяют эдж кейсы и говорят "ок, будем считать, что оно работает". При этом нет никаких гарантий, что это говно не упадет на инпуте, который мы не тестировали, нет, мы просто верим, что оно не упадет. Доказывать все подряд формально -- это аутизм, на который ни у кого нет ни денег, ни времени.
https://ru.wikipedia.org/wiki/Фальсифицируемость
Он это имеет ввиду.
Эксперимент не может доказать гипотезу, потому что эксперимент, как правило, покрывает относительно небольшое количество кейсов. Поэтому можно только провести эксперимент, сказать "ок, пока будем считать, что это так", если результаты подтверждают гипотезу, но в будущем, любой другой эксперимент, покрывающий другое множество кейсов, может теорию опровергнуть.
В программировании никто не доказывает корректность программы формально. Обычно тестируют программу (или ее часть) на небольшом множестве инпутов, проверяют эдж кейсы и говорят "ок, будем считать, что оно работает". При этом нет никаких гарантий, что это говно не упадет на инпуте, который мы не тестировали, нет, мы просто верим, что оно не упадет. Доказывать все подряд формально -- это аутизм, на который ни у кого нет ни денег, ни времени.
>>487008
Хаскель, раст, инструменты для анализа С кода?
https://wiki.haskell.org/Haskell_in_industry
?
Дай Бог вас ИИ заменит скоро.
> программировании никто не доказывает корректность программы формально.
Хаскель, раст, инструменты для анализа С кода?
https://wiki.haskell.org/Haskell_in_industry
?
>мы просто верим, что оно не упадет
Дай Бог вас ИИ заменит скоро.
>>487013
ИИ никогда не будет, потому что это будет программа настолько сложная, что все борщехлебы помрут от старости, пока будут доказывать ее корректность.
ИИ никогда не будет, потому что это будет программа настолько сложная, что все борщехлебы помрут от старости, пока будут доказывать ее корректность.
>>487004
Это аналог возврата от структурного программирования к goto, с единственным отличием: явным прокидыванием изменяемого стейта.
Эти дяди играются в песочнице на бюджетные деньги. Все эти доказательства не работают, потому что написание верификации на несколько порядков сложнее написания программы, и, что самое плохое, программа верификации - это тоже программа, она тоже подвержена ошибкам. Т.е. написав сложную программу, и дальше написав для нее верификатор, ты не можешь доказать корректность верификатора.
Намного эффективнее писать не программы, у которых ошибки отсутствуют, а программы, устойчивые к ошибкам.
>Анус ставишь?
Это аналог возврата от структурного программирования к goto, с единственным отличием: явным прокидыванием изменяемого стейта.
>Ты наверное не знаешь, но формулы которые ты кодишь делают умные дяди с учёными степенями которые, внезапно, доказывают их корректность по самым разным критериям.
Эти дяди играются в песочнице на бюджетные деньги. Все эти доказательства не работают, потому что написание верификации на несколько порядков сложнее написания программы, и, что самое плохое, программа верификации - это тоже программа, она тоже подвержена ошибкам. Т.е. написав сложную программу, и дальше написав для нее верификатор, ты не можешь доказать корректность верификатора.
Намного эффективнее писать не программы, у которых ошибки отсутствуют, а программы, устойчивые к ошибкам.
>>487023
Фикс. Я не учел, что могут появиться новые борщехлебы.
>ИИ никогда не будет, потому что это будет программа настолько сложная, что тепловая смерть Вселенной наступит раньше, чем борщехлебы докажут корректность ИИ.
Фикс. Я не учел, что могут появиться новые борщехлебы.
>>487025
С тобой все в порядке? Доказательство теоремы пифагора работает, или нет?
Причем тут какие-то программы вообще?
Ты писал
То есть речь шла о логике, а не о коде, о логике которую код реализует.
Ты утверждал, что, логика эта выдумывается на лету, а не разрабатывается заранее. Мол нахуй скажем метод расчёта баллистической траектории, давайте как-то сами чисто интуитивно накодим? И мол это обычная практика.
Это просто громкое заявление не привязанное ни к чему.
Чем измеряется эффективность? Что такое "программы у которых отсутствуют ошибки", как измеряться устойчивость к ошибкам?
О чем ты вообще? Насколько мне известно, программ в которых гарантированно нет ошибок - не существует в природе.
Твои высказывания выглядят так, как будто они несут чисто эмоциональный характер.
Я пытаюсь тебя понять, но ничего не выходит.
Я повторю вопрос.
Ты это хочешь сказать?
>Эти дяди играются в песочнице на бюджетные деньги. Все эти доказательства не работают
С тобой все в порядке? Доказательство теоремы пифагора работает, или нет?
>Все эти доказательства не работают, потому что написание верификации на несколько порядков сложнее написания программы
Причем тут какие-то программы вообще?
Ты писал
>но разбивается, когда приходится писать/читать сложную рекурсивную функцию, которая обрабатывает реальную логику в приложении, а не доказанные заранее на бумажке математические алгоритм
То есть речь шла о логике, а не о коде, о логике которую код реализует.
Ты утверждал, что, логика эта выдумывается на лету, а не разрабатывается заранее. Мол нахуй скажем метод расчёта баллистической траектории, давайте как-то сами чисто интуитивно накодим? И мол это обычная практика.
>Намного эффективнее писать не программы, у которых ошибки отсутствуют, а программы, устойчивые к ошибкам.
Это просто громкое заявление не привязанное ни к чему.
Чем измеряется эффективность? Что такое "программы у которых отсутствуют ошибки", как измеряться устойчивость к ошибкам?
О чем ты вообще? Насколько мне известно, программ в которых гарантированно нет ошибок - не существует в природе.
Твои высказывания выглядят так, как будто они несут чисто эмоциональный характер.
Я пытаюсь тебя понять, но ничего не выходит.
Я повторю вопрос.
>программист = машинистка, и нечего мудрить, а кто мудрит тот манятеоретик очкастый
Ты это хочешь сказать?
>>487008
Ну, это, положим, ты спизднул
В программировании сайтов-визиток - да, никто не доказывает.
В этой области никто даже не знает, что так можно было.
>В программировании никто не доказывает корректность программы формально
Ну, это, положим, ты спизднул
В программировании сайтов-визиток - да, никто не доказывает.
В этой области никто даже не знает, что так можно было.
>>477327 (OP)
В голос с твоих попуков. В 2к19 языки разрабатываются только с одной главной целью: ускорение и удешевление разработки.
Если с этими фичами код можно быстрее хуячить в продакшн — это сэкономленные миллиарды.
В голос с твоих попуков. В 2к19 языки разрабатываются только с одной главной целью: ускорение и удешевление разработки.
Если с этими фичами код можно быстрее хуячить в продакшн — это сэкономленные миллиарды.
>>487042
Любое формальное математическое доказательство является программой. В том числе и теорема пифагора. Она, конечно, работает. Но теорема пифагора очень простая.
В современных программах код и есть логика.
Индустрия пыталась ввести UML и прочую поебень, чтобы формализовать такие вещи как UI, базы данных, и прочую хуйню, но это оказалось мертворожденной корпоративной хуйней. Код первичен.
Вот здесь ключевой момент твоего непонимания. Код расчета баллистической траектории - это 40-е и 60-е годы, это очень простой код, который можно написать даже на ассемблере с комментариями. Этот код пишут ученые, которые даже не являются профессиональными программистами.
Современные программы на несколько порядков сложнее математических расчетов, а формальное доказательство их корректности будет ЕЩЕ сложнее.
>Причем тут какие-то программы вообще?
Любое формальное математическое доказательство является программой. В том числе и теорема пифагора. Она, конечно, работает. Но теорема пифагора очень простая.
>То есть речь шла о логике, а не о коде, о логике которую код реализует.
В современных программах код и есть логика.
Индустрия пыталась ввести UML и прочую поебень, чтобы формализовать такие вещи как UI, базы данных, и прочую хуйню, но это оказалось мертворожденной корпоративной хуйней. Код первичен.
>Ты утверждал, что, логика эта выдумывается на лету, а не разрабатывается заранее. Мол нахуй скажем метод расчёта баллистической траектории, давайте как-то сами чисто интуитивно накодим?
Вот здесь ключевой момент твоего непонимания. Код расчета баллистической траектории - это 40-е и 60-е годы, это очень простой код, который можно написать даже на ассемблере с комментариями. Этот код пишут ученые, которые даже не являются профессиональными программистами.
Современные программы на несколько порядков сложнее математических расчетов, а формальное доказательство их корректности будет ЕЩЕ сложнее.
41 Кб, 800x600>>487008
Это вообще о другом.
Только эксперимент и может. Пикрелейтед в помощь.
Есть такое понятие - границы применимости теории.
Это вопрос задачи, а не аутизм. Therac-25 вас так ничему и не научил.
>Он это имеет ввиду.
Это вообще о другом.
>Эксперимент не может доказать гипотезу
Только эксперимент и может. Пикрелейтед в помощь.
>как правило, покрывает относительно небольшое количество кейсов
Есть такое понятие - границы применимости теории.
>Доказывать все подряд формально -- это аутизм, на который ни у кого нет ни денег, ни времени.
Это вопрос задачи, а не аутизм. Therac-25 вас так ничему и не научил.
>>487042
Нет, ты==борщехлеб
Следи за руками, разношу твои аргументы:
Потому что им это нахуй не упало, как и во многих других областях, дебилушка ниишная, изучил матлогику на первом курсе, а за лабы на паскале получил двойку?
Сам мат. аппарат основан на физическом мире, а не наоборот.
Логическое выражение основывается на первоначальном наборе аксиом, которые выбирает человек.
И чем ты будешь доказывать обосрался он с выбором или нет?
https://www.sscc.edu/home/jdavidso/math/goedel.html
Математика это инструмент, а не предмет для надрачивания.
>программист==машинистка
Нет, ты==борщехлеб
Следи за руками, разношу твои аргументы:
>в вебе не доказывают упадет магазин или нет
Потому что им это нахуй не упало, как и во многих других областях, дебилушка ниишная, изучил матлогику на первом курсе, а за лабы на паскале получил двойку?
Сам мат. аппарат основан на физическом мире, а не наоборот.
Логическое выражение основывается на первоначальном наборе аксиом, которые выбирает человек.
И чем ты будешь доказывать обосрался он с выбором или нет?
https://www.sscc.edu/home/jdavidso/math/goedel.html
Математика это инструмент, а не предмет для надрачивания.
>>486899
Частично и с оговорками возможно, хотя понятно, что это не чистый функциональный язык.
Зачем тащить всю структуру, когда можно положить указатель на неё? Вся работа по изменению этой структуры изолируется в наборе простых функций. После того, как они протестированы, можно писать набор по возможности чистых функций для работы со структурой данных через этот набор слов. Этот подход ближе к ФП, чем к ООП.
Потому что они по факту ничем не отличаются от прочих слов. Грубо говоря, это некие грязные функции, в которых изолируется состояние вне стека.
>На форте невозможно писать в функциональном стиле
Частично и с оговорками возможно, хотя понятно, что это не чистый функциональный язык.
>Хотя бы потому, что через стек ты иммутабельную структуру не передашь, туда можно класть только инты и флоаты.
Зачем тащить всю структуру, когда можно положить указатель на неё? Вся работа по изменению этой структуры изолируется в наборе простых функций. После того, как они протестированы, можно писать набор по возможности чистых функций для работы со структурой данных через этот набор слов. Этот подход ближе к ФП, чем к ООП.
>Плюс все переменные фактически глобальные
Потому что они по факту ничем не отличаются от прочих слов. Грубо говоря, это некие грязные функции, в которых изолируется состояние вне стека.
>>487129
Форт, вообще-то, самый императивный язык из всех: положи на стек, достань со стека, что-то сделай.
>не чистый функциональный язык.
Форт, вообще-то, самый императивный язык из всех: положи на стек, достань со стека, что-то сделай.
>>487108
Therac-25 как раз научил тому, что нужна устойчивая к ошибкам система, а не безошибочная. Независимый дозиметр с watchdog'ом позволил бы решить все проблемы с этой системой.
Прикол в том, что в therac-20 такая вещь была, а в therac-25 удешивили систему и понадеялись на формальные проверки, за которые ты топишь.
Therac-25 как раз научил тому, что нужна устойчивая к ошибкам система, а не безошибочная. Независимый дозиметр с watchdog'ом позволил бы решить все проблемы с этой системой.
Прикол в том, что в therac-20 такая вещь была, а в therac-25 удешивили систему и понадеялись на формальные проверки, за которые ты топишь.
>>487139
Интересно как, если система считает, что оператор "сознательно" ввел соответствующую дозу, доза облучения зависят от решения врача, и никакими дозиметрами ты этого не ограничишь.
Не было там формальных проверок. Там была единственная проверка за которую ты топишь: раз не падает на тестах, значит работает. До первого фатального случая аппараты в сумме наработали десятки тысяч процедур.
>Независимый дозиметр с watchdog'ом позволил бы решить все проблемы с этой системой.
Интересно как, если система считает, что оператор "сознательно" ввел соответствующую дозу, доза облучения зависят от решения врача, и никакими дозиметрами ты этого не ограничишь.
>и понадеялись на формальные проверки, за которые ты топишь.
Не было там формальных проверок. Там была единственная проверка за которую ты топишь: раз не падает на тестах, значит работает. До первого фатального случая аппараты в сумме наработали десятки тысяч процедур.
>>487139
Нахуй ты кормишь дебила?
Нахуй ты кормишь дебила?
>>487148
А почему она так считает? Потому что ты ее так спроектировал? Ну вот поэтому проектирование подобной системы тебе никто не доверит.
Не в строить в собственный код защиту от дурака, потому что пользователь - врач с корочкой, это как раз что-то уровня therac-25. При том, что therac-20 нормально работал с тем же самым кодом:
Врач из Чикаго Фрэнк Борджер, узнав про ошибку Therac-25, решил выяснить, возможно ли такое на его Therac-20. Ошибку повторить не удалось, но позже обнаружилась связь. Когда новая группа студентов начинала практику на Therac-20, часто срабатывали предохранители-автоматы. Это повторялось в течение трёх недель, но потом практически прекращалось — до следующей группы. Новички часто используют нестандартные способы ввода информации — это значит, что при определённой последовательности, введённой с клавиатуры, случается аварийная ситуация. До переоблучения она не развивалась лишь потому, что в Therac-20 стоял аппаратный блокиратор.
Были. Просто ты веришь в учоных, с корочкой, которые просмотрят код, выпустят отчет на 500 страниц, и все заебись, а на деле учоные такие же долбоебы, как и любые люди, и совершили ошибки при проверке исходного кода. Хотя даже блок-схемы нарисовали.
>Интересно как, если система считает, что оператор "сознательно" ввел соответствующую дозу, доза облучения зависят от решения врача, и никакими дозиметрами ты этого не ограничишь.
А почему она так считает? Потому что ты ее так спроектировал? Ну вот поэтому проектирование подобной системы тебе никто не доверит.
Не в строить в собственный код защиту от дурака, потому что пользователь - врач с корочкой, это как раз что-то уровня therac-25. При том, что therac-20 нормально работал с тем же самым кодом:
Врач из Чикаго Фрэнк Борджер, узнав про ошибку Therac-25, решил выяснить, возможно ли такое на его Therac-20. Ошибку повторить не удалось, но позже обнаружилась связь. Когда новая группа студентов начинала практику на Therac-20, часто срабатывали предохранители-автоматы. Это повторялось в течение трёх недель, но потом практически прекращалось — до следующей группы. Новички часто используют нестандартные способы ввода информации — это значит, что при определённой последовательности, введённой с клавиатуры, случается аварийная ситуация. До переоблучения она не развивалась лишь потому, что в Therac-20 стоял аппаратный блокиратор.
>Не было там формальных проверок.
Были. Просто ты веришь в учоных, с корочкой, которые просмотрят код, выпустят отчет на 500 страниц, и все заебись, а на деле учоные такие же долбоебы, как и любые люди, и совершили ошибки при проверке исходного кода. Хотя даже блок-схемы нарисовали.
>>487162
Не было. Разработчики проигнорировали все что можно, в том числе и формальную верификацию, понадеявшись на либы от Therac 20, в котором стояла аппаратная защита, а ошибки при эксплуатации списывались на аппаратные проблемы. Хотя на самом деле это были ошибки ПО (как потом путем экспериментов и выяснилось).
При формальной проверке невозможны ситуации с переполнением при сложении, деление на ноль итд. А именно эти ошибки привели к печальным последствиям.
>Были.
Не было. Разработчики проигнорировали все что можно, в том числе и формальную верификацию, понадеявшись на либы от Therac 20, в котором стояла аппаратная защита, а ошибки при эксплуатации списывались на аппаратные проблемы. Хотя на самом деле это были ошибки ПО (как потом путем экспериментов и выяснилось).
При формальной проверке невозможны ситуации с переполнением при сложении, деление на ноль итд. А именно эти ошибки привели к печальным последствиям.
>>487063
Началось кидание в крайности, будто между визитками и ПО для самолетов (где действительно требуется высокая надежность софта, а поэтому верификация оправдана) ничего не существует.
Все всё прекрасно знают. Борщехлебы почему то думают, что они знают тайны Вселенной, которые доступны лишь Избранным, хотя это не так.
>>487108
Твой пикрилейтед никак не противоречит моим словам вообще.
Даже в "границах применимости" можно найти кейс, не покрытый экспериментом, какие бы границы применимости ты ни придумывал. Вот сейчас работает механика Ньютона, а завтра в одном из экспериментов она работать не будет и Ньютон соснет хуйца. Так в общем то было уже один раз, просто тогда сказали, что на малых скоростях все работает. Но нет никаких гарантий, что потом что-то во Вселенной не наебнется и механика Ньютона не будет работать даже на малых скоростях, и никакие границы применимости уже не помогут.
>В программировании сайтов-визиток - да, никто не доказывает.
Началось кидание в крайности, будто между визитками и ПО для самолетов (где действительно требуется высокая надежность софта, а поэтому верификация оправдана) ничего не существует.
>В этой области никто даже не знает, что так можно было.
Все всё прекрасно знают. Борщехлебы почему то думают, что они знают тайны Вселенной, которые доступны лишь Избранным, хотя это не так.
>>487108
>Только эксперимент и может. Пикрелейтед в помощь.
Твой пикрилейтед никак не противоречит моим словам вообще.
>Есть такое понятие - границы применимости теории.
Даже в "границах применимости" можно найти кейс, не покрытый экспериментом, какие бы границы применимости ты ни придумывал. Вот сейчас работает механика Ньютона, а завтра в одном из экспериментов она работать не будет и Ньютон соснет хуйца. Так в общем то было уже один раз, просто тогда сказали, что на малых скоростях все работает. Но нет никаких гарантий, что потом что-то во Вселенной не наебнется и механика Ньютона не будет работать даже на малых скоростях, и никакие границы применимости уже не помогут.
>>487173
При условии, что в формальной проверке нет ошибок. А этого ты для достаточно сложной программы гарантировать не можешь.
>При формальной проверке невозможны ситуации с переполнением при сложении, деление на ноль итд
При условии, что в формальной проверке нет ошибок. А этого ты для достаточно сложной программы гарантировать не можешь.
>>486996
Студентик матфака попался на незнании базовых вещей. Ладно вы не знаете о научном методе, но хотя бы определение теории можно было загуглить.
>>487004
Рассказывай, каким образом ты будешь доказывать правильность программы. Напишешь на бумажке алгоритм и докажешь математикой? Но потом придется этот алгоритм переводить в инструкции для реального компьютера, как ты докажешь, что инструкции работают как надо? Еще больше бумажек испишешь? Или подключишь туда другую программу, которая проверяет первую? Но тут мы уже полный круг прошли. Факт в том, что программирование - это эмпирическая наука, а не математика. И доказать в науке ничего нельзя, можно только поставить эксперимент и сформулировать на его основе теорию, которая будет описывать результаты данного эксперимента. Для программирования эксперимент - это тест, а теория - сам код программы.
>Теория - это доказанная экспериментом гипотеза.
>теория
>доказанная
Студентик матфака попался на незнании базовых вещей. Ладно вы не знаете о научном методе, но хотя бы определение теории можно было загуглить.
>>487004
>Внезапно, можно, у тебя какой-то мир не реальный, а выдуманный.
Рассказывай, каким образом ты будешь доказывать правильность программы. Напишешь на бумажке алгоритм и докажешь математикой? Но потом придется этот алгоритм переводить в инструкции для реального компьютера, как ты докажешь, что инструкции работают как надо? Еще больше бумажек испишешь? Или подключишь туда другую программу, которая проверяет первую? Но тут мы уже полный круг прошли. Факт в том, что программирование - это эмпирическая наука, а не математика. И доказать в науке ничего нельзя, можно только поставить эксперимент и сформулировать на его основе теорию, которая будет описывать результаты данного эксперимента. Для программирования эксперимент - это тест, а теория - сам код программы.
>>487013
Раст и C мимо. В расте даже один unsafe блок может тебя в жопу выебать. А программы на C вообще полностью unsafe. Все эти анализаторы хорошо показывают наличие багов, но отвратительно доказывают их отсутствие.
Раст и C мимо. В расте даже один unsafe блок может тебя в жопу выебать. А программы на C вообще полностью unsafe. Все эти анализаторы хорошо показывают наличие багов, но отвратительно доказывают их отсутствие.
>>487230
В математике доказательства возможны в принципе, этим она и отличается от обычных наук.
В математике доказательства возможны в принципе, этим она и отличается от обычных наук.
>>487260
Ну хорошо.
Ну хорошо.
>>487313
Штаны постирай.
Штаны постирай.
>>487081
Ты несёшь чушь.
Страшную чушь.
Ты на простой вопрос ответить можешь? Я тебе его 2раза задал. Ты не понимаешь сути моего вопроса?
17того века надеюсь?
Это бессмысленный набор слов. Тебе ок 15 лет? Где эти учёные, зачем они этот код пишут, что значит ДАЖЕ не являются?
Это как сказать:
Что у тебя в голове за мрак такой страшный.
В чем отличие программы от математических расчётов и чем ты измеряешь сложность?
>Любое формальное математическое доказательство является программой.
Ты несёшь чушь.
>В современных программах код и есть логика.
Страшную чушь.
>Вот здесь ключевой момент твоего непонимания.
Ты на простой вопрос ответить можешь? Я тебе его 2раза задал. Ты не понимаешь сути моего вопроса?
>Код расчета баллистической траектории - это 40-е и 60-е годы
17того века надеюсь?
>Этот код пишут ученые, которые даже не являются профессиональными программистами.
Это бессмысленный набор слов. Тебе ок 15 лет? Где эти учёные, зачем они этот код пишут, что значит ДАЖЕ не являются?
Это как сказать:
>эти чертежи рисуют архитекторы, они даже не являются профессиональными крановщиками
Что у тебя в голове за мрак такой страшный.
>Современные программы на несколько порядков сложнее математических расчетов,
В чем отличие программы от математических расчётов и чем ты измеряешь сложность?
![255644-konosuba-gods-blessing-on-this-wonderful-world-megum[...].jpg](https://2ch.hk//pr/src/1477327/15700429902980.jpg)
>>487112
Цирк шапито уехал вон туда ->
Ты не меня цитируешь, прими срочно галопередон.
Ну как скажешь. Как там кстати в 2007? Мемы еще не протухли?
У нас тут в преддверье 2020 всякая функциональщина и иммутабильность даже в джаву вошла, даже в сишарп, даже в небо.
Вон знакомая макачит на автоматизированном тестировании, так там мать его груви какой-то, замыкание на замыкании, предикаты и операторы фильтрации коллекций. Я от офигел пытаясь в этой жути разобраться.
Функциональщина разве что в Си еще не залезла(С++ то давно уже ту-ту), хотя надо бы проверить на всякий случай.
Так что мы тут все в 2019 борщехлебы, кроме разве что гоферов, вот это тру олдскул пацаны.
>>487221
Так, ты очевидно о всяких хаскелях не знаешь даже понаслышке. Я в этом не эксперт, так что объяснить что-то врядли смогу, тебе лучше погуглить то как работает хаскель, какие гарантии и какими средствами он предоставляет, и какая теория за этим стоит.
Там впрочем, насколько мне известно, есть несколько разных подходов к доказательству корректности программного кода.
Самое очевидное, что приходит в голову, это выработать набор условий, нарушение которых будет говорить о некорректно составленной программе, а соблюдение о некой корректности в рамках описанных этими условиями. Ну это как мне кажется. Предлагаю ознакомиться с теорией, и тогда у нас получиться интересный разговор, ты мне сообщишь что-то новое, а я поделюсь своим ценным мнением.
А, и да, выражение
Лишено всякого смысла, анон что это пишет - идиот. Нет никакого "математического понимания" математика это инструмент для описания чего-либо, в ней может быть все что угодно. Математических теорий сотни тысяч, если не миллионы.
Тот анон видимо под математикой понимает школьную математику, дебил короче.
>>487237
Да без разницы насколько хорошо они это делают. Важно что делают как-то, причём выхлоп от этого достаточен для того чтобы в этом инвестировали миллионы человекочасов и баксов.
>Следи за руками
Цирк шапито уехал вон туда ->
>разношу твои аргументы:
>>в вебе не доказывают упадет магазин или нет
Ты не меня цитируешь, прими срочно галопередон.
>Нет, ты==борщехлеб
Ну как скажешь. Как там кстати в 2007? Мемы еще не протухли?
У нас тут в преддверье 2020 всякая функциональщина и иммутабильность даже в джаву вошла, даже в сишарп, даже в небо.
Вон знакомая макачит на автоматизированном тестировании, так там мать его груви какой-то, замыкание на замыкании, предикаты и операторы фильтрации коллекций. Я от офигел пытаясь в этой жути разобраться.
Функциональщина разве что в Си еще не залезла(С++ то давно уже ту-ту), хотя надо бы проверить на всякий случай.
Так что мы тут все в 2019 борщехлебы, кроме разве что гоферов, вот это тру олдскул пацаны.
>>487221
>Рассказывай, каким образом ты будешь доказывать правильность программы. Напишешь на бумажке алгоритм и докажешь математикой? Но потом придется этот алгоритм переводить в инструкции для реального компьютера, как ты докажешь, что инструкции работают как надо?
Так, ты очевидно о всяких хаскелях не знаешь даже понаслышке. Я в этом не эксперт, так что объяснить что-то врядли смогу, тебе лучше погуглить то как работает хаскель, какие гарантии и какими средствами он предоставляет, и какая теория за этим стоит.
Там впрочем, насколько мне известно, есть несколько разных подходов к доказательству корректности программного кода.
Самое очевидное, что приходит в голову, это выработать набор условий, нарушение которых будет говорить о некорректно составленной программе, а соблюдение о некой корректности в рамках описанных этими условиями. Ну это как мне кажется. Предлагаю ознакомиться с теорией, и тогда у нас получиться интересный разговор, ты мне сообщишь что-то новое, а я поделюсь своим ценным мнением.
А, и да, выражение
>в математическом понимании
Лишено всякого смысла, анон что это пишет - идиот. Нет никакого "математического понимания" математика это инструмент для описания чего-либо, в ней может быть все что угодно. Математических теорий сотни тысяч, если не миллионы.
Тот анон видимо под математикой понимает школьную математику, дебил короче.
>>487237
Да без разницы насколько хорошо они это делают. Важно что делают как-то, причём выхлоп от этого достаточен для того чтобы в этом инвестировали миллионы человекочасов и баксов.
>>487112
Цирк шапито уехал вон туда ->
Ты не меня цитируешь, прими срочно галопередон.
Ну как скажешь. Как там кстати в 2007? Мемы еще не протухли?
У нас тут в преддверье 2020 всякая функциональщина и иммутабильность даже в джаву вошла, даже в сишарп, даже в небо.
Вон знакомая макачит на автоматизированном тестировании, так там мать его груви какой-то, замыкание на замыкании, предикаты и операторы фильтрации коллекций. Я от офигел пытаясь в этой жути разобраться.
Функциональщина разве что в Си еще не залезла(С++ то давно уже ту-ту), хотя надо бы проверить на всякий случай.
Так что мы тут все в 2019 борщехлебы, кроме разве что гоферов, вот это тру олдскул пацаны.
>>487221
Так, ты очевидно о всяких хаскелях не знаешь даже понаслышке. Я в этом не эксперт, так что объяснить что-то врядли смогу, тебе лучше погуглить то как работает хаскель, какие гарантии и какими средствами он предоставляет, и какая теория за этим стоит.
Там впрочем, насколько мне известно, есть несколько разных подходов к доказательству корректности программного кода.
Самое очевидное, что приходит в голову, это выработать набор условий, нарушение которых будет говорить о некорректно составленной программе, а соблюдение о некой корректности в рамках описанных этими условиями. Ну это как мне кажется. Предлагаю ознакомиться с теорией, и тогда у нас получиться интересный разговор, ты мне сообщишь что-то новое, а я поделюсь своим ценным мнением.
А, и да, выражение
Лишено всякого смысла, анон что это пишет - идиот. Нет никакого "математического понимания" математика это инструмент для описания чего-либо, в ней может быть все что угодно. Математических теорий сотни тысяч, если не миллионы.
Тот анон видимо под математикой понимает школьную математику, дебил короче.
>>487237
Да без разницы насколько хорошо они это делают. Важно что делают как-то, причём выхлоп от этого достаточен для того чтобы в этом инвестировали миллионы человекочасов и баксов.
>Следи за руками
Цирк шапито уехал вон туда ->
>разношу твои аргументы:
>>в вебе не доказывают упадет магазин или нет
Ты не меня цитируешь, прими срочно галопередон.
>Нет, ты==борщехлеб
Ну как скажешь. Как там кстати в 2007? Мемы еще не протухли?
У нас тут в преддверье 2020 всякая функциональщина и иммутабильность даже в джаву вошла, даже в сишарп, даже в небо.
Вон знакомая макачит на автоматизированном тестировании, так там мать его груви какой-то, замыкание на замыкании, предикаты и операторы фильтрации коллекций. Я от офигел пытаясь в этой жути разобраться.
Функциональщина разве что в Си еще не залезла(С++ то давно уже ту-ту), хотя надо бы проверить на всякий случай.
Так что мы тут все в 2019 борщехлебы, кроме разве что гоферов, вот это тру олдскул пацаны.
>>487221
>Рассказывай, каким образом ты будешь доказывать правильность программы. Напишешь на бумажке алгоритм и докажешь математикой? Но потом придется этот алгоритм переводить в инструкции для реального компьютера, как ты докажешь, что инструкции работают как надо?
Так, ты очевидно о всяких хаскелях не знаешь даже понаслышке. Я в этом не эксперт, так что объяснить что-то врядли смогу, тебе лучше погуглить то как работает хаскель, какие гарантии и какими средствами он предоставляет, и какая теория за этим стоит.
Там впрочем, насколько мне известно, есть несколько разных подходов к доказательству корректности программного кода.
Самое очевидное, что приходит в голову, это выработать набор условий, нарушение которых будет говорить о некорректно составленной программе, а соблюдение о некой корректности в рамках описанных этими условиями. Ну это как мне кажется. Предлагаю ознакомиться с теорией, и тогда у нас получиться интересный разговор, ты мне сообщишь что-то новое, а я поделюсь своим ценным мнением.
А, и да, выражение
>в математическом понимании
Лишено всякого смысла, анон что это пишет - идиот. Нет никакого "математического понимания" математика это инструмент для описания чего-либо, в ней может быть все что угодно. Математических теорий сотни тысяч, если не миллионы.
Тот анон видимо под математикой понимает школьную математику, дебил короче.
>>487237
Да без разницы насколько хорошо они это делают. Важно что делают как-то, причём выхлоп от этого достаточен для того чтобы в этом инвестировали миллионы человекочасов и баксов.
>>487471
Это не доказательство корректности, это тестирование или дебаг, но не доказательство. Как написал анон:
>>487237
Из того, что вы выработали набор условий и программа этим условиям соответствует, никак не следует то, что программа верна, поэтому что один из кейсов вы можете просто по недосмотру не покрыть. Доказательство подразумевает, что вам вообще не придется придумывать какие-то условия, ловить баги и т.д., т.к. корректность программы будет следовать логически.
Есть общая математическая культура, в которую входит понимание того, что такое доказательство. У обывателей (в частности, у некоторых программистов) этого понимания нет, для них доказательство это что угодно, тестики работают -- уже доказательство корректности, пипи-пупу уга-буга.
Доказательство корректности подразумевает, что у вас есть специально обученные борщехлебы, которые будут сидеть и с помощью прувера доказывать корректность.
На порядки больше инвестируют человекочасов и баксов в тестирование и отладку, придумывания разных методологий типа TDD, в разработку инструментов для тестирования и отладки. Доказательство подразумевает, что вам ничего не придется тестировать и отлаживать. Иначе это не доказательство.
>выработать набор условий, нарушение которых будет говорить о некорректно составленной программе
Это не доказательство корректности, это тестирование или дебаг, но не доказательство. Как написал анон:
>>487237
>Все эти анализаторы хорошо показывают наличие багов, но отвратительно доказывают их отсутствие.
Из того, что вы выработали набор условий и программа этим условиям соответствует, никак не следует то, что программа верна, поэтому что один из кейсов вы можете просто по недосмотру не покрыть. Доказательство подразумевает, что вам вообще не придется придумывать какие-то условия, ловить баги и т.д., т.к. корректность программы будет следовать логически.
>Нет никакого "математического понимания"
Есть общая математическая культура, в которую входит понимание того, что такое доказательство. У обывателей (в частности, у некоторых программистов) этого понимания нет, для них доказательство это что угодно, тестики работают -- уже доказательство корректности, пипи-пупу уга-буга.
Доказательство корректности подразумевает, что у вас есть специально обученные борщехлебы, которые будут сидеть и с помощью прувера доказывать корректность.
>Важно что делают как-то, причём выхлоп от этого достаточен для того чтобы в этом инвестировали миллионы человекочасов и баксов
На порядки больше инвестируют человекочасов и баксов в тестирование и отладку, придумывания разных методологий типа TDD, в разработку инструментов для тестирования и отладки. Доказательство подразумевает, что вам ничего не придется тестировать и отлаживать. Иначе это не доказательство.
>>487471
Ну понятно дело, ты дебил без понимания базовых вещей, а не эксперт. И еще какого-то хуя мнение имеешь, не стесняясь признавать, что ничего не знаешь по сути? Еще раз - невозможность доказательства теорий - это неотъемлемый элемент науки, изучающей реальный мир. Computer science, внезапно, является как раз такой наукой, потому что программы крутятся в этом самом мире, а не в твоей голове.
>о всяких хаскелях
>Я в этом не эксперт
>Ну это как мне кажется
>Предлагаю ознакомиться с теорией
Ну понятно дело, ты дебил без понимания базовых вещей, а не эксперт. И еще какого-то хуя мнение имеешь, не стесняясь признавать, что ничего не знаешь по сути? Еще раз - невозможность доказательства теорий - это неотъемлемый элемент науки, изучающей реальный мир. Computer science, внезапно, является как раз такой наукой, потому что программы крутятся в этом самом мире, а не в твоей голове.
>>487449
Если ты что-то не понимаешь, есть высокая вероятность, что это ты тупой, а не кто-то несет чушь. То, что формальные доказательства - это вычисления, называется изоморфизмом Карри-Говарда, и в среде борщехлебов это истина настолько банальная, что не знать ее и при этом быть апологетом ФП и рассуждать о доказательствах в хаскеле - это полный пиздец.
И вот как с тобой общаться, если ты в очередной раз проявляешь свою сущность шизика? Алло, ты не самый умный и компетентный здесь, и если какой-то текст тебе кажется абракадаброй, то это потому что ты ньюфаг в окружении серьезных дядек. Веди себя соответствующе. Тогда, возможно, ты будешь получать из общения новые знания, а не ощущение того, что ты вышел из спора победителем, потому что оставил за собой последнее слово. Это просто либо красная, либо синяя таблетка. Либо вежливое общение, либо с тобой будут общаться, как с вечно правым и увереным, что вокруг него одни школьники, шизиком. За сим иди нахуй, общаться со школотроном, про "мрак в голове" ДВУМ людям - неинтересно.
>Ты несёшь чушь.
Если ты что-то не понимаешь, есть высокая вероятность, что это ты тупой, а не кто-то несет чушь. То, что формальные доказательства - это вычисления, называется изоморфизмом Карри-Говарда, и в среде борщехлебов это истина настолько банальная, что не знать ее и при этом быть апологетом ФП и рассуждать о доказательствах в хаскеле - это полный пиздец.
И вот как с тобой общаться, если ты в очередной раз проявляешь свою сущность шизика? Алло, ты не самый умный и компетентный здесь, и если какой-то текст тебе кажется абракадаброй, то это потому что ты ньюфаг в окружении серьезных дядек. Веди себя соответствующе. Тогда, возможно, ты будешь получать из общения новые знания, а не ощущение того, что ты вышел из спора победителем, потому что оставил за собой последнее слово. Это просто либо красная, либо синяя таблетка. Либо вежливое общение, либо с тобой будут общаться, как с вечно правым и увереным, что вокруг него одни школьники, шизиком. За сим иди нахуй, общаться со школотроном, про "мрак в голове" ДВУМ людям - неинтересно.
>>487572
Ради тебя, няша, я переоденусь даже в халат японского нечеткого профессора
Ради тебя, няша, я переоденусь даже в халат японского нечеткого профессора
>>487136
Это фишка конкатенативных языков: в них последовательное указание имён функций чётко отражает ход реальных вычислений. Этакое низкоуровневое ФП. Заманчивая была идея: использовать преимущества ФП на низком уровне с высокой производительностью. Жаль, на это почти забили.
Это фишка конкатенативных языков: в них последовательное указание имён функций чётко отражает ход реальных вычислений. Этакое низкоуровневое ФП. Заманчивая была идея: использовать преимущества ФП на низком уровне с высокой производительностью. Жаль, на это почти забили.
>>487471
Соответственно попрошу завалить ебальник
>мам смотри я шучу про галю!!
>в жабе, сишарпе и даже небе добавили фп
>все жрут говно значит и ты жри
>Я в этом не эксперт
Соответственно попрошу завалить ебальник
>>487194
Любая достаточно сложная программа декомпозируется на тривиальные подпрограммы, корректность которых легко доказывается. Из этих корректных тривиальных подпрограмм составляются новые тривиальные подпрограммы, корректность которых так же легко доказывается. И так до самого верхнего уровня, где у тебя написано что-то типа тривиального Application.Run(Config, IO, InitState).
Опять же разговор не о том, что что-то можно пропустить при проверке - при любой проверке: формальной, в тестах, в хардварных ограничителях и во всем остальном можно допустить ошибку. А важно то, насколько можно снизить вероятность возникновения ошибки. При применении формальных методов ошибки встречаются реже, чем при применении тестов и прочих методах. Тестами все случаи входных-выходных значений покрыть невозможно, если их бесконечное количество. А математическое доказательство работает для таких случаев.
>>487221
Цитата из загугленной википедии:
Что из этого противоречит моим словам?
Вот как раз ты и попался на незнании базовых вещей.
Сначала формулируется гипотеза, затем придумывается эксперимент для её проверки, после чего гипотеза либо выкидывается на свалку, либо превращается в теорию.
>>487506
Совсем поехал? Теория на то и теория, что её уже не надо доказывать. Она подтверждена экспериментально, в отличие от гипотез. Из теории могут вылезать следствия, которые либо подтверждают её, либо накладывают на неё ограничения при экспериментальной проверке.
Кажется, что ты пытаешься говорить о критерии Поппера, но нихуя не понял в чем его смысл.
>>487656
Если что-то выглядит как последовательность инструкций и работает как последовательность инструкций, то это и есть последовательность инструкций, что не есть ФП.
>>487191
Полная чушь. Эксперимент, поставленный в рамках классической механики, не может ей противоречить, а все потому, что классическая механика - уже давно частный случай более общей теории. Вот у более общих теорий пока точные границы неизвестны, но есть следствия, которые кажутся противоречащими известным фактам, но пока недоступные для экспериментальной проверки.
>При условии, что в формальной проверке нет ошибок. А этого ты для достаточно сложной программы гарантировать не можешь.
Любая достаточно сложная программа декомпозируется на тривиальные подпрограммы, корректность которых легко доказывается. Из этих корректных тривиальных подпрограмм составляются новые тривиальные подпрограммы, корректность которых так же легко доказывается. И так до самого верхнего уровня, где у тебя написано что-то типа тривиального Application.Run(Config, IO, InitState).
Опять же разговор не о том, что что-то можно пропустить при проверке - при любой проверке: формальной, в тестах, в хардварных ограничителях и во всем остальном можно допустить ошибку. А важно то, насколько можно снизить вероятность возникновения ошибки. При применении формальных методов ошибки встречаются реже, чем при применении тестов и прочих методах. Тестами все случаи входных-выходных значений покрыть невозможно, если их бесконечное количество. А математическое доказательство работает для таких случаев.
>>487221
>Студентик матфака попался на незнании базовых вещей. Ладно вы не знаете о научном методе, но хотя бы определение теории можно было загуглить.
Цитата из загугленной википедии:
>Теории предшествует гипотеза, получившая воспроизводимое подтверждение.
Что из этого противоречит моим словам?
>И доказать в науке ничего нельзя, можно только поставить эксперимент и сформулировать на его основе теорию, которая будет описывать результаты данного эксперимента.
Вот как раз ты и попался на незнании базовых вещей.
Сначала формулируется гипотеза, затем придумывается эксперимент для её проверки, после чего гипотеза либо выкидывается на свалку, либо превращается в теорию.
>>487506
>невозможность доказательства теорий - это неотъемлемый элемент науки
Совсем поехал? Теория на то и теория, что её уже не надо доказывать. Она подтверждена экспериментально, в отличие от гипотез. Из теории могут вылезать следствия, которые либо подтверждают её, либо накладывают на неё ограничения при экспериментальной проверке.
Кажется, что ты пытаешься говорить о критерии Поппера, но нихуя не понял в чем его смысл.
>>487656
Если что-то выглядит как последовательность инструкций и работает как последовательность инструкций, то это и есть последовательность инструкций, что не есть ФП.
>>487191
>Вот сейчас работает механика Ньютона, а завтра в одном из экспериментов она работать не будет и Ньютон соснет хуйца.
Полная чушь. Эксперимент, поставленный в рамках классической механики, не может ей противоречить, а все потому, что классическая механика - уже давно частный случай более общей теории. Вот у более общих теорий пока точные границы неизвестны, но есть следствия, которые кажутся противоречащими известным фактам, но пока недоступные для экспериментальной проверки.
>>487194
Любая достаточно сложная программа декомпозируется на тривиальные подпрограммы, корректность которых легко доказывается. Из этих корректных тривиальных подпрограмм составляются новые тривиальные подпрограммы, корректность которых так же легко доказывается. И так до самого верхнего уровня, где у тебя написано что-то типа тривиального Application.Run(Config, IO, InitState).
Опять же разговор не о том, что что-то можно пропустить при проверке - при любой проверке: формальной, в тестах, в хардварных ограничителях и во всем остальном можно допустить ошибку. А важно то, насколько можно снизить вероятность возникновения ошибки. При применении формальных методов ошибки встречаются реже, чем при применении тестов и прочих методах. Тестами все случаи входных-выходных значений покрыть невозможно, если их бесконечное количество. А математическое доказательство работает для таких случаев.
>>487221
Цитата из загугленной википедии:
Что из этого противоречит моим словам?
Вот как раз ты и попался на незнании базовых вещей.
Сначала формулируется гипотеза, затем придумывается эксперимент для её проверки, после чего гипотеза либо выкидывается на свалку, либо превращается в теорию.
>>487506
Совсем поехал? Теория на то и теория, что её уже не надо доказывать. Она подтверждена экспериментально, в отличие от гипотез. Из теории могут вылезать следствия, которые либо подтверждают её, либо накладывают на неё ограничения при экспериментальной проверке.
Кажется, что ты пытаешься говорить о критерии Поппера, но нихуя не понял в чем его смысл.
>>487656
Если что-то выглядит как последовательность инструкций и работает как последовательность инструкций, то это и есть последовательность инструкций, что не есть ФП.
>>487191
Полная чушь. Эксперимент, поставленный в рамках классической механики, не может ей противоречить, а все потому, что классическая механика - уже давно частный случай более общей теории. Вот у более общих теорий пока точные границы неизвестны, но есть следствия, которые кажутся противоречащими известным фактам, но пока недоступные для экспериментальной проверки.
>При условии, что в формальной проверке нет ошибок. А этого ты для достаточно сложной программы гарантировать не можешь.
Любая достаточно сложная программа декомпозируется на тривиальные подпрограммы, корректность которых легко доказывается. Из этих корректных тривиальных подпрограмм составляются новые тривиальные подпрограммы, корректность которых так же легко доказывается. И так до самого верхнего уровня, где у тебя написано что-то типа тривиального Application.Run(Config, IO, InitState).
Опять же разговор не о том, что что-то можно пропустить при проверке - при любой проверке: формальной, в тестах, в хардварных ограничителях и во всем остальном можно допустить ошибку. А важно то, насколько можно снизить вероятность возникновения ошибки. При применении формальных методов ошибки встречаются реже, чем при применении тестов и прочих методах. Тестами все случаи входных-выходных значений покрыть невозможно, если их бесконечное количество. А математическое доказательство работает для таких случаев.
>>487221
>Студентик матфака попался на незнании базовых вещей. Ладно вы не знаете о научном методе, но хотя бы определение теории можно было загуглить.
Цитата из загугленной википедии:
>Теории предшествует гипотеза, получившая воспроизводимое подтверждение.
Что из этого противоречит моим словам?
>И доказать в науке ничего нельзя, можно только поставить эксперимент и сформулировать на его основе теорию, которая будет описывать результаты данного эксперимента.
Вот как раз ты и попался на незнании базовых вещей.
Сначала формулируется гипотеза, затем придумывается эксперимент для её проверки, после чего гипотеза либо выкидывается на свалку, либо превращается в теорию.
>>487506
>невозможность доказательства теорий - это неотъемлемый элемент науки
Совсем поехал? Теория на то и теория, что её уже не надо доказывать. Она подтверждена экспериментально, в отличие от гипотез. Из теории могут вылезать следствия, которые либо подтверждают её, либо накладывают на неё ограничения при экспериментальной проверке.
Кажется, что ты пытаешься говорить о критерии Поппера, но нихуя не понял в чем его смысл.
>>487656
Если что-то выглядит как последовательность инструкций и работает как последовательность инструкций, то это и есть последовательность инструкций, что не есть ФП.
>>487191
>Вот сейчас работает механика Ньютона, а завтра в одном из экспериментов она работать не будет и Ньютон соснет хуйца.
Полная чушь. Эксперимент, поставленный в рамках классической механики, не может ей противоречить, а все потому, что классическая механика - уже давно частный случай более общей теории. Вот у более общих теорий пока точные границы неизвестны, но есть следствия, которые кажутся противоречащими известным фактам, но пока недоступные для экспериментальной проверки.
>>487766
ПОСОНЫ!!!
ВЕСЬ ПРОЕКТ НАДО СНАЧАЛА ДОКАЗАТЬ!!!
ВДРУГ ЧО!
РАЗБИТЬ НА ФУНКЦИИ И ДОКАЗАТЬ ЧТО 2 + 2 = 4!!!!
ПОТОМУ ЧТО ВДРУГ НЕ РАВНО
БОГ ПОСМЕЯЛСЯ И ТЕПЕРЬ 2 + 2 = 5
РАЗРАБОТЧИКИ ОТУПЕЛИ И ПОТЕРЯЛИ ЗРЕНИЕ
НЕ ВЕРЬТЕ СЕБЕ!!!!
ДОКАЗЫВАЙТЕ ВСЕ!!!
СОБИРАЙТЕ КОЛЛЕГИЮ УЧЕНЫХ ЧТОБЫ ДОКАЗАТЬ СВОЙ КОД!!!!
ДОКАЗАТЕЛЬСТВА!!! ГРАНТЫ!!! ПОПИЛ!!!
>Любая достаточно сложная программа декомпозируется на тривиальные подпрограммы, корректность которых легко доказывается
ПОСОНЫ!!!
ВЕСЬ ПРОЕКТ НАДО СНАЧАЛА ДОКАЗАТЬ!!!
ВДРУГ ЧО!
РАЗБИТЬ НА ФУНКЦИИ И ДОКАЗАТЬ ЧТО 2 + 2 = 4!!!!
ПОТОМУ ЧТО ВДРУГ НЕ РАВНО
БОГ ПОСМЕЯЛСЯ И ТЕПЕРЬ 2 + 2 = 5
РАЗРАБОТЧИКИ ОТУПЕЛИ И ПОТЕРЯЛИ ЗРЕНИЕ
НЕ ВЕРЬТЕ СЕБЕ!!!!
ДОКАЗЫВАЙТЕ ВСЕ!!!
СОБИРАЙТЕ КОЛЛЕГИЮ УЧЕНЫХ ЧТОБЫ ДОКАЗАТЬ СВОЙ КОД!!!!
ДОКАЗАТЕЛЬСТВА!!! ГРАНТЫ!!! ПОПИЛ!!!
>>487768
i = 5;
i = ++i + ++i;
## TEST SNOULD WORKS!!
print(i == 13);
Довай, без доказательства корректности, а с одним тока тестом это в прод это выпусти.
i = 5;
i = ++i + ++i;
## TEST SNOULD WORKS!!
print(i == 13);
Довай, без доказательства корректности, а с одним тока тестом это в прод это выпусти.
>>487766
Кому не надо? Тебе лично не надо? Или все люди в мире собрались и сказали "да нахуй нам доказывать, давайте просто потусим"? Теорию доказать невозможно.
Подтверждение = доказательство, так и запишем.
>Теория на то и теория, что её уже не надо доказывать
Кому не надо? Тебе лично не надо? Или все люди в мире собрались и сказали "да нахуй нам доказывать, давайте просто потусим"? Теорию доказать невозможно.
>Она подтверждена экспериментально
Подтверждение = доказательство, так и запишем.
>>487766
Ну вот возьмем простую программу: вычисление md5 хэша. Как ты докажешь ее корректность?
>Любая достаточно сложная программа декомпозируется на тривиальные подпрограммы, корректность которых легко доказывается
Ну вот возьмем простую программу: вычисление md5 хэша. Как ты докажешь ее корректность?
>>487766
Последовательность инструкций - это последовательность вызова функций. Ты сейчас пиздишь на языки вроде Joy, функциональная природа которых ясно доказана и обоснована. Функциональный язык можно построить и не на лямбда-исчислении.
>Если что-то выглядит как последовательность инструкций и работает как последовательность инструкций, то это и есть последовательность инструкций, что не есть ФП
Последовательность инструкций - это последовательность вызова функций. Ты сейчас пиздишь на языки вроде Joy, функциональная природа которых ясно доказана и обоснована. Функциональный язык можно построить и не на лямбда-исчислении.
>>487867
Функциональный язык - это язык, программы на котором задаются:
1) применением функций к их аргументам в определённой взаимосвязи, причём в качестве аргумента могут выступать как результаты применения функций, так и другие функции (аппликативный подход)
2) применением функций к неявно заданным аргументам, технически находящимся (упакованным, если угодно) в некой общей подразумеваемой структуре данных, причём конкатенация функций выражает их композицию (конкатенативный подход)
Пишу строго от балды первое пришедшее в голову без всякой строгости формулировок.
Функциональный язык - это язык, программы на котором задаются:
1) применением функций к их аргументам в определённой взаимосвязи, причём в качестве аргумента могут выступать как результаты применения функций, так и другие функции (аппликативный подход)
2) применением функций к неявно заданным аргументам, технически находящимся (упакованным, если угодно) в некой общей подразумеваемой структуре данных, причём конкатенация функций выражает их композицию (конкатенативный подход)
Пишу строго от балды первое пришедшее в голову без всякой строгости формулировок.
>>487885
Забыл добавить.
А так как в конкатенативном язык аргументы явно не указываются и функции применяются к некой общей структуре данных, то последовательность записей функций (слов) отражает реальную последовательность их выполнения на компьютере. Отсюда удобство и эффективность реализации, но трудности с распараллеливанием. Всратый вид программ уже научились фиксить.
Всё, теперь ссы.
Забыл добавить.
А так как в конкатенативном язык аргументы явно не указываются и функции применяются к некой общей структуре данных, то последовательность записей функций (слов) отражает реальную последовательность их выполнения на компьютере. Отсюда удобство и эффективность реализации, но трудности с распараллеливанием. Всратый вид программ уже научились фиксить.
Всё, теперь ссы.
>>487888
Тогда ассемблер конкатенативный функциональный язык, у которого структура данных - озу
Тогда ассемблер конкатенативный функциональный язык, у которого структура данных - озу
>>477327 (OP)
Проиграл. Деды основатели предпочитали иммьютабельные перфокарты. Шах и мат!
>Во-вторых, даже архитектура ПК построена на RANDOM ACCESS MEMORY. То есть наши отцы-основатели, в отличие от (((них))), которые теперь паразитируют на отрасли, предпочитали ПРОИЗВОЛЬНЫЙ ДОСТУП К ОБЪЕКТАМ В ПАМЯТИ.
Проиграл. Деды основатели предпочитали иммьютабельные перфокарты. Шах и мат!
>>487890
Ебать ты в теме шаришь.
Ну расскажи, как "функции" je или mov cx, 10 применяются к оперативной памяти. Ты вообще понимаешь, что такое функция в математике?
Ебать ты в теме шаришь.
Ну расскажи, как "функции" je или mov cx, 10 применяются к оперативной памяти. Ты вообще понимаешь, что такое функция в математике?
>>487902
Ещё как суть.
В конкатенативном языке параметры функций не указываются явно. В языке ассемблера ты обязан явно указать, что к чему. Как ты будешь неявно обращаться к random access memory? Превратить 8 гигабайт ОЗУ в один большой стек?
В конкатенативном языке новые функции описываются конкатенацией. Как ты думаешь, если я составлю "функцию" mov cmp, она будет корректной с точки зрения синтаксиса? Я молчу про то, будет ли это работать.
Так на дваче доказали, что язык ассемблера не является функциональным. Две премии Тьюринга в этот ИТТ тред.
Ещё как суть.
В конкатенативном языке параметры функций не указываются явно. В языке ассемблера ты обязан явно указать, что к чему. Как ты будешь неявно обращаться к random access memory? Превратить 8 гигабайт ОЗУ в один большой стек?
В конкатенативном языке новые функции описываются конкатенацией. Как ты думаешь, если я составлю "функцию" mov cmp, она будет корректной с точки зрения синтаксиса? Я молчу про то, будет ли это работать.
Так на дваче доказали, что язык ассемблера не является функциональным. Две премии Тьюринга в этот ИТТ тред.
>>487914
Только то, что ты утверждаешь, а именно: Java - ФЯП.
Конкатенативные ФЯ не основываются на лямбда-исчислении, от этого они не становятся менее функциональными. Да и лямбды в последнее время к чему только не приделывают, ждём их в Коболе, лол.
Хуюкция. Я с Java почти не знаком, там хоть есть функции высшего порядка? Дело не в том, как что называется, а в том, как это работает. Охуенный ФЯ, в котором оператор присваивания на каждом шагу, ага.
>что тебе еще обосновать?
Только то, что ты утверждаешь, а именно: Java - ФЯП.
>Лямбды там есть
Конкатенативные ФЯ не основываются на лямбда-исчислении, от этого они не становятся менее функциональными. Да и лямбды в последнее время к чему только не приделывают, ждём их в Коболе, лол.
>метод - это функция
Хуюкция. Я с Java почти не знаком, там хоть есть функции высшего порядка? Дело не в том, как что называется, а в том, как это работает. Охуенный ФЯ, в котором оператор присваивания на каждом шагу, ага.
>>487916
Ты чего порвался? В твоем определении не было никаких функций высшего порядка да, прикинь, map filter reduce там есть, вот это неожиданность и то, что лямбдами нищитово, и про оператор присваивания ничего. По твоему определению выше, Java - ФП язык.
Ты чего порвался? В твоем определении не было никаких функций высшего порядка да, прикинь, map filter reduce там есть, вот это неожиданность и то, что лямбдами нищитово, и про оператор присваивания ничего. По твоему определению выше, Java - ФП язык.
>>487921
Рекомендую повернуться к монитору лицом.
И про стек ничего, и про каррирование ничего, и про комбинаторы тоже, представь себе, ничего.
В чистом аппликативном функциональном языке состояние программы хранится в аргументах функций. В чистом конкатенативном функциональном языке состояние программы хранится в общей структуре данных. А теперь вопрос: где хранится состояние в Java-программе?
Язык называется таким-то и таким-то не потому, что в нём есть такие-то фишки, прилепленные сбоку, а потому, что у него есть основа с той или иной сутью. Функции в математическом смысле можно писать и в древнем Фортране. Haskell - это аппликативный язык, хотя конкатенации в нём хоть жопой жуй. Kitten - конкатенативный язык, в котором есть и явные переменные, и инфиксная запись. Так как определить, какой язык к какому типу относится? Просто тыкая в некие признаки наобум? Нет, путём анализа того, какие штуки реализуются через какие механизмы.
Я могу использовать неизменяемые переменные в Java, но тем же механизмом (оператором присваивания) могу по сто раз менять их значение. Я могу написать чистейшую функцию, а могу точно так же написать грязный код. А в Haskell не могу.
>В твоем определении не было никаких функций высшего порядка
>причём в качестве аргумента могут выступать как результаты применения функций, так и другие функции
Рекомендую повернуться к монитору лицом.
>и про оператор присваивания ничего
И про стек ничего, и про каррирование ничего, и про комбинаторы тоже, представь себе, ничего.
В чистом аппликативном функциональном языке состояние программы хранится в аргументах функций. В чистом конкатенативном функциональном языке состояние программы хранится в общей структуре данных. А теперь вопрос: где хранится состояние в Java-программе?
Язык называется таким-то и таким-то не потому, что в нём есть такие-то фишки, прилепленные сбоку, а потому, что у него есть основа с той или иной сутью. Функции в математическом смысле можно писать и в древнем Фортране. Haskell - это аппликативный язык, хотя конкатенации в нём хоть жопой жуй. Kitten - конкатенативный язык, в котором есть и явные переменные, и инфиксная запись. Так как определить, какой язык к какому типу относится? Просто тыкая в некие признаки наобум? Нет, путём анализа того, какие штуки реализуются через какие механизмы.
Я могу использовать неизменяемые переменные в Java, но тем же механизмом (оператором присваивания) могу по сто раз менять их значение. Я могу написать чистейшую функцию, а могу точно так же написать грязный код. А в Haskell не могу.
>>487957
Ты в любом случае получил ответ. 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
Дело в том, что стандартные стримы — это просто некоторая абстракция над итератором. Хоть стримы внешне и кажутся крайне независимыми и мощными, но минусы итераторов никуда не делись."
Замечательный ФЯ, дайте два.
Ты в любом случае получил ответ. 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
Дело в том, что стандартные стримы — это просто некоторая абстракция над итератором. Хоть стримы внешне и кажутся крайне независимыми и мощными, но минусы итераторов никуда не делись."
Замечательный ФЯ, дайте два.
>>487943
Гораздо проще - надо посмотреть, какие программы на этом языке обычно пишут. Если там принято писать функциональные программы, то язык можно назвать функциональным. Если OO программы, то объектно-ориентированным. Только один подъеб, что и функциональщину, и ОО, и процедурную залупу можно комбинировать друг с другом и реализовать кучей разных способов, они никак друг друга не исключают. Ты попытался это сказать, но подобосрался на определении функциональной программы, так что давай заново.
>Так как определить, какой язык к какому типу относится
Гораздо проще - надо посмотреть, какие программы на этом языке обычно пишут. Если там принято писать функциональные программы, то язык можно назвать функциональным. Если OO программы, то объектно-ориентированным. Только один подъеб, что и функциональщину, и ОО, и процедурную залупу можно комбинировать друг с другом и реализовать кучей разных способов, они никак друг друга не исключают. Ты попытался это сказать, но подобосрался на определении функциональной программы, так что давай заново.
>>487989
Сперва надо определить, что к чему привешано: хвост к собаке или собака к хвосту.
Язык называют функциональным не потому, что люди пишут на нём функциональные программы. Люди пишут на нём функциональные программы потому, что это функциональный язык и его механизмы подходят для этого лучше всего. Обычно люди всё-таки предпочитают не одевать штаны через голову.
Сперва надо определить, что к чему привешано: хвост к собаке или собака к хвосту.
Язык называют функциональным не потому, что люди пишут на нём функциональные программы. Люди пишут на нём функциональные программы потому, что это функциональный язык и его механизмы подходят для этого лучше всего. Обычно люди всё-таки предпочитают не одевать штаны через голову.
>>488048
Одно слово для тебя - javascript.
>Люди пишут на нём функциональные программы потому, что это функциональный язык и его механизмы подходят для этого лучше всего
Одно слово для тебя - javascript.
>>488062
Бэкус хорошо заметил, что оператор присваивания в фон неймовских языках как бы расщепляет программирование на два мира: слева и справа от него. Правая часть нередко очень математична и чиста, в последние десятилетия на неё навесили очень много фишек из функционального программирования, что видно в javascript. Да и в древнем Фортране-IV можно было записывать в правой части чистейшую математику. Проблема в том, что есть ещё и левая часть, она никуда не делась.
Поэтому javascript всего лишь императивный в основе язык с кучей фич из ООП и ФП, а Haskell - чистый ФЯ. В нём нет никакого левого мира.
Бэкус хорошо заметил, что оператор присваивания в фон неймовских языках как бы расщепляет программирование на два мира: слева и справа от него. Правая часть нередко очень математична и чиста, в последние десятилетия на неё навесили очень много фишек из функционального программирования, что видно в javascript. Да и в древнем Фортране-IV можно было записывать в правой части чистейшую математику. Проблема в том, что есть ещё и левая часть, она никуда не делась.
Поэтому javascript всего лишь императивный в основе язык с кучей фич из ООП и ФП, а Haskell - чистый ФЯ. В нём нет никакого левого мира.
>>487768
/тхреад
/тхреад
>>487793
Объясните почему этот малолетний дебил ещё не въебал мочи за такую хуйню в тематике.
>мам я троллю /pr/
Объясните почему этот малолетний дебил ещё не въебал мочи за такую хуйню в тематике.
>>488516
Да и файлик с исходным кодом тоже можно изменить после написания. Для пущей иммутабельности пусть вообще всё будет рид-онли, например, файловая система тех, кто продвигает иммутабельность, а то это лицемерие и двойные стандарты получаются. Непорядок!
Да и файлик с исходным кодом тоже можно изменить после написания. Для пущей иммутабельности пусть вообще всё будет рид-онли, например, файловая система тех, кто продвигает иммутабельность, а то это лицемерие и двойные стандарты получаются. Непорядок!
>>487943
Конкатенация в хаскеле? Ой вэй. В Хаскеле всегда аппликация.
Даже кусок кода "put 5 dup mult" не делает язык конкатенативным.
Конкатенация в хаскеле? Ой вэй. В Хаскеле всегда аппликация.
Даже кусок кода "put 5 dup mult" не делает язык конкатенативным.
>>487819
Забавно, что этот пост был проигнорен, потому что вторая половина десятых нам дала новую порцию борщехлебов: диванные борщехлебы. Если старые борщехлебы в принципе умели программировать хоть что-то, то здесь просто пиздеж ради пиздежа.
Забавно, что этот пост был проигнорен, потому что вторая половина десятых нам дала новую порцию борщехлебов: диванные борщехлебы. Если старые борщехлебы в принципе умели программировать хоть что-то, то здесь просто пиздеж ради пиздежа.
>>488584
Сравниваешь алгоритм и код, попутно ищешь языкоспецифичный undefined behavior, что тут сложного?
Сравниваешь алгоритм и код, попутно ищешь языкоспецифичный undefined behavior, что тут сложного?
>>488524
есть две функции от одного аргумента, x и y. Определяем новую функцию: z = x y
Совершенно типичная для Хаскелля возможность определить новую функцию как композицию функций через конкатенацию их имён.
есть две функции от одного аргумента, x и y. Определяем новую функцию: z = x y
Совершенно типичная для Хаскелля возможность определить новую функцию как композицию функций через конкатенацию их имён.
>>488587
Опять же путаешь код и программу. Программа - это запущенный и крутящийся в компьютере код. Как ты докажешь, что она работает корректно?
Опять же путаешь код и программу. Программа - это запущенный и крутящийся в компьютере код. Как ты докажешь, что она работает корректно?
>>488645
Почему это не конкатенация? Определение функции в примере - это конкатенация, то есть буквально текстовая склейка двух имён функций без явного указания их аргумента. Другой вопрос, что в выражениях с этой функцией она будет разворачиваться в последовательность аппликаций, ну так Haskell и есть аппликативный, а не конкатенативный язык.
Почему это не конкатенация? Определение функции в примере - это конкатенация, то есть буквально текстовая склейка двух имён функций без явного указания их аргумента. Другой вопрос, что в выражениях с этой функцией она будет разворачиваться в последовательность аппликаций, ну так Haskell и есть аппликативный, а не конкатенативный язык.
>>488666
Потому что это аппликация.
В данном случае одна функция принимает другую функцию в качестве аргумента, а никакая не склейка имен.
>Почему это не конкатенация?
Потому что это аппликация.
>то есть буквально текстовая склейка двух имён функций без явного указания их аргумента
В данном случае одна функция принимает другую функцию в качестве аргумента, а никакая не склейка имен.
>>488642
Спасибо, анон.
Еще одна порция "блаблабла" от диванного борщехлеба. На этом, собственно, тред можно закрывать. Потому что спорить о терминах хвилосовы могут бесконечно, а вне споров о терминах - сплошное пуканье.
Спасибо, анон.
Еще одна порция "блаблабла" от диванного борщехлеба. На этом, собственно, тред можно закрывать. Потому что спорить о терминах хвилосовы могут бесконечно, а вне споров о терминах - сплошное пуканье.
>>487766
В абсолютно чистом ФП -- может быть и декомпозируется, факт в том, что в чистом ФП никто не пишет, и поведение "тривиальных" подпрограмм зависит от состояния других "тривиальных" подпрограмм. В результате проблема верификации большой программы не разбивается на проблемы верификации маленьких подпрограмм.
Может, если релятивистская механика наебнется вместе с классической, а физики в очередной раз натянуть сову на глобус и придумать более общую теорию не смогут. Эксперименты не могут доказать теорию в принципе, они только опровергают ее. Если теория опровергнута, пилят новую теорию, которая учитывает новые экспериментальные данные (так было с классической механикой, на смену которой пришла релятивистская, и так было с теорией Дарвина, на смену которой пришла Синтетическая теория эволюции). Если бы эксперименты доказывали теорию, новых теорий не появлялось бы, потому что ты не можешь опровергнуть уже доказанный факт, это нонсенс. Тогда не появилось бы той же самой релятивистской механики, ноука же доказала, что Ньютон прав.
Доказательства бывают только в математике, в науке их нет.
>Любая достаточно сложная программа декомпозируется на тривиальные подпрограммы, корректность которых легко доказывается.
В абсолютно чистом ФП -- может быть и декомпозируется, факт в том, что в чистом ФП никто не пишет, и поведение "тривиальных" подпрограмм зависит от состояния других "тривиальных" подпрограмм. В результате проблема верификации большой программы не разбивается на проблемы верификации маленьких подпрограмм.
>Эксперимент, поставленный в рамках классической механики, не может ей противоречить
Может, если релятивистская механика наебнется вместе с классической, а физики в очередной раз натянуть сову на глобус и придумать более общую теорию не смогут. Эксперименты не могут доказать теорию в принципе, они только опровергают ее. Если теория опровергнута, пилят новую теорию, которая учитывает новые экспериментальные данные (так было с классической механикой, на смену которой пришла релятивистская, и так было с теорией Дарвина, на смену которой пришла Синтетическая теория эволюции). Если бы эксперименты доказывали теорию, новых теорий не появлялось бы, потому что ты не можешь опровергнуть уже доказанный факт, это нонсенс. Тогда не появилось бы той же самой релятивистской механики, ноука же доказала, что Ньютон прав.
Доказательства бывают только в математике, в науке их нет.
>>488718
Ты либо тупой, либо тролль, либо тупой тролль.
Во-первых, про твою теорию "всеобщего наебения". Если завтра внезапно перестанет работать гравитация, то тебя мгноенно распылит на атомы или кварки, поэтому нет никакого ПРАКТИЧЕСКОГО смысла в том, чтобы задаваться вопросом "а что, если завтра внезапно перестанет работать гравитация?" То есть, в разрезе ЧЕЛОВЕЧЕСТВА, гравитационные силы будут существовать всегда. Может быть, их определение как-то расширят, может переформулируют, но австралийцы не начнут внезапно падать с Земли.
Во-вторых, про твоё "нет чистого ФП". Скажем, есть у нас некий
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 }
и тогда программа разбивается на тривиальные подпрограммы. Да, это дерьмо требует неебического количества лишних операций, но прошедшая через такое доказательство программа ломается только в том случае, которые никак не интересуют нормальных людей, потому что нормальные люди не суют вилку себе в глаз, надеясь, что там ничего не сломается.
Ты либо тупой, либо тролль, либо тупой тролль.
Во-первых, про твою теорию "всеобщего наебения". Если завтра внезапно перестанет работать гравитация, то тебя мгноенно распылит на атомы или кварки, поэтому нет никакого ПРАКТИЧЕСКОГО смысла в том, чтобы задаваться вопросом "а что, если завтра внезапно перестанет работать гравитация?" То есть, в разрезе ЧЕЛОВЕЧЕСТВА, гравитационные силы будут существовать всегда. Может быть, их определение как-то расширят, может переформулируют, но австралийцы не начнут внезапно падать с Земли.
Во-вторых, про твоё "нет чистого ФП". Скажем, есть у нас некий
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 }
и тогда программа разбивается на тривиальные подпрограммы. Да, это дерьмо требует неебического количества лишних операций, но прошедшая через такое доказательство программа ломается только в том случае, которые никак не интересуют нормальных людей, потому что нормальные люди не суют вилку себе в глаз, надеясь, что там ничего не сломается.
>>488761
Не просто тупой тролль, но еще и двощер.
Это как выиграть в 3 лотереи сразу.
>либо тупой тролль
Не просто тупой тролль, но еще и двощер.
Это как выиграть в 3 лотереи сразу.
>>488784
А там разве говорится, что ты самый тупой?
А там разве говорится, что ты самый тупой?
>>488761
Опять ебаный третьекурсник порвался на простыню, при этом так и не удосужившись понять основы. Еще раз, дебил ебаный, программирование - это не математика, в своей башке и на бумаге ты можешь придумать хоть какой чистый ФП язык и доказывать на нем любые программы(потому что сам и задаешь начальные аксиомы для этих доказательств, прямо как в математике). Но как только ты напишешь эту программу в реальном мире и запустишь на реальном процессоре, она тут же перестанет быть чисто ФПшной и доказуемой. Остальной твой бабах смысла не имеет.
Опять ебаный третьекурсник порвался на простыню, при этом так и не удосужившись понять основы. Еще раз, дебил ебаный, программирование - это не математика, в своей башке и на бумаге ты можешь придумать хоть какой чистый ФП язык и доказывать на нем любые программы(потому что сам и задаешь начальные аксиомы для этих доказательств, прямо как в математике). Но как только ты напишешь эту программу в реальном мире и запустишь на реальном процессоре, она тут же перестанет быть чисто ФПшной и доказуемой. Остальной твой бабах смысла не имеет.
>>488761
Это подмена тезиса, я не говорил, что должна перестать работать гравитация. Если завтра поставят опыт, по расчетам которого выйдет, что ускорение свободного падения не 9.8, а 9.7, и этот опыт повторяем, то теория все равно наебнется, для этого выключение гравитации не потребуется.
В нем действительно нет практического смысла, в этом я с тобой согласен. Это мысленный эксперимент, который я поставил, чтобы показать, что научную теорию невозможно доказать в принципе. Математическую -- можно, научную -- нет.
Не обязательно. Может все поменяться в любой момент таким образом, что человечество не погибнет, но при этом ученые нихуя не смогут объяснить. Твой оптимизм относительно ноуки не основан ни на чем.
Ниже ты вообще какой-то шизоидный бред написал, который к дискуссии не имеет отношения. Как ты собираешься декомпозировать программы в том же Си, где нахуй прямой доступ к памяти, и любая хуйня может поменять любую хуйню в любой момент?-
>Если завтра внезапно перестанет работать гравитация, то тебя мгноенно распылит на атомы или кварки
Это подмена тезиса, я не говорил, что должна перестать работать гравитация. Если завтра поставят опыт, по расчетам которого выйдет, что ускорение свободного падения не 9.8, а 9.7, и этот опыт повторяем, то теория все равно наебнется, для этого выключение гравитации не потребуется.
>поэтому нет никакого ПРАКТИЧЕСКОГО смысла в том, чтобы задаваться вопросом
В нем действительно нет практического смысла, в этом я с тобой согласен. Это мысленный эксперимент, который я поставил, чтобы показать, что научную теорию невозможно доказать в принципе. Математическую -- можно, научную -- нет.
>Может быть, их определение как-то расширят, может переформулируют
Не обязательно. Может все поменяться в любой момент таким образом, что человечество не погибнет, но при этом ученые нихуя не смогут объяснить. Твой оптимизм относительно ноуки не основан ни на чем.
Ниже ты вообще какой-то шизоидный бред написал, который к дискуссии не имеет отношения. Как ты собираешься декомпозировать программы в том же Си, где нахуй прямой доступ к памяти, и любая хуйня может поменять любую хуйню в любой момент?-
>>488789
Логика процессора - это точно такая же программа и к ней применяется все то же самое, что было сказано сверху.
Логика процессора - это точно такая же программа и к ней применяется все то же самое, что было сказано сверху.
>>488787
Окей, это C, не спорю. Но приведи мне пример обычного программирования без всяких private_cast (потому что в функциональном языке такого тупо нет), в котором значение переменной one_to_hundred не находилось бы между 1 и 100. И прочти пост внимательнее, там говорится, что ни одна функция кроме new() не имеет доступа к значению переменной.
>>488793
Серьёзно, это же тупо машинный код, единицы и нули, что там может пойти не так?
Окей, это C, не спорю. Но приведи мне пример обычного программирования без всяких private_cast (потому что в функциональном языке такого тупо нет), в котором значение переменной one_to_hundred не находилось бы между 1 и 100. И прочти пост внимательнее, там говорится, что ни одна функция кроме new() не имеет доступа к значению переменной.
>>488793
> Я не могу доказать логику процессора, а потому и остальные люди — дибилы, и не могут сложить 2 и 2.
Серьёзно, это же тупо машинный код, единицы и нули, что там может пойти не так?
>>488802
Сколько можно повторять дебилу, что есть разница между логикой процессора, написанной(и доказанной) на бумажке, и тем, что крутится в самом процессоре? Ты вообще необучаемый или как?
Сколько можно повторять дебилу, что есть разница между логикой процессора, написанной(и доказанной) на бумажке, и тем, что крутится в самом процессоре? Ты вообще необучаемый или как?
>>488811
То есть, уже много лет там всё крутится как на бумажке, а завтра хуяк! и везде перестанет? Мы, кажется, уже договорились, что нет никакого ПРАКТИЧЕСКОГО смысла предполагать, что завтра австралийцы отвалятся от Земли и улетят в космос?
И да, не вижу разницы между 1+1 на бумажке и 1+1 в процессоре. Так что необучаемый тут скорее ты.
То есть, уже много лет там всё крутится как на бумажке, а завтра хуяк! и везде перестанет? Мы, кажется, уже договорились, что нет никакого ПРАКТИЧЕСКОГО смысла предполагать, что завтра австралийцы отвалятся от Земли и улетят в космос?
И да, не вижу разницы между 1+1 на бумажке и 1+1 в процессоре. Так что необучаемый тут скорее ты.
>>488818
Какой же уебок. Ты доказывал, что therac-25 плох, потому что там предположили, что раз много лет все крутится - значит ошибок нет. А теперь, оказывается, что никаких ФОРМАЛЬНЫХ ПРОВЕРОК не существует, а есть ПРАКТИЧЕСКИЙ СМЫСЛ.
Еще пара лет, с твоим-то IQ, и ты поймешь, что ПРАКТИЧЕСКИЙ СМЫСЛ - это тесты.
>То есть, уже много лет там всё крутится как на бумажке, а завтра хуяк! и везде перестанет
Какой же уебок. Ты доказывал, что therac-25 плох, потому что там предположили, что раз много лет все крутится - значит ошибок нет. А теперь, оказывается, что никаких ФОРМАЛЬНЫХ ПРОВЕРОК не существует, а есть ПРАКТИЧЕСКИЙ СМЫСЛ.
Еще пара лет, с твоим-то IQ, и ты поймешь, что ПРАКТИЧЕСКИЙ СМЫСЛ - это тесты.
>>488820
Всё крутилось в реальном мире, а на бумаге как раз никто ничего не крутил. Так что твои аргументы — это плевок против ветра.
Всё крутилось в реальном мире, а на бумаге как раз никто ничего не крутил. Так что твои аргументы — это плевок против ветра.
>>488818
Речь шла про доказуемость/недоказуемость, если у тебя уже все выветрилось. Но если мы начнем говорить про практичность, то ты и тут соснешь с проглотом, потому что практично - это не доказывать программу на бумажке в тру-функциональном стиле и стараться ее перенести с минимум ошибок-опечаток, а писать тесты на бизнес-логику.
> а завтра хуяк! и везде перестанет?
Речь шла про доказуемость/недоказуемость, если у тебя уже все выветрилось. Но если мы начнем говорить про практичность, то ты и тут соснешь с проглотом, потому что практично - это не доказывать программу на бумажке в тру-функциональном стиле и стараться ее перенести с минимум ошибок-опечаток, а писать тесты на бизнес-логику.
>>488825
Мои аргументы на тебя не работают, потому что ты тупой, и за время существования треда ты не поумнел
Мои аргументы на тебя не работают, потому что ты тупой, и за время существования треда ты не поумнел
>>488761
Ну окей, а теперь более практический пример. md5. С которым ты уже соснул. Ну давай тогда так: конечный автомат протокола TCP.
Ну окей, а теперь более практический пример. md5. С которым ты уже соснул. Ну давай тогда так: конечный автомат протокола TCP.
>>488761
Композиция тривиальных программ не является тривиальной программой.
>и тогда программа разбивается на тривиальные подпрограммы.
Композиция тривиальных программ не является тривиальной программой.
>>488827
А, это действительно выветрилось. Да и ты же не думаешь, что тут один анон за всё ФП отвечает? Ну и про недоказуемость я уже давно согласился, но вот бумажный ФП как раз чисто математический, а отличий бумажного от программного я не вижу, потому что там та же математика, просто аксиомы вроде "1<2" записаны не в общественном договоре между учёными, а в компиляторе. Да, проблемы остаются, но не в самом ФП.
>>488839
Вот смотри, структура Qwe тривиальна, и one_to_hundred не может иметь значения отличного от одного из промежутка 1 - 100, так? И это нам надо доказать только один раз, если мы больше не меняем код именно этой структуры. Потом у нас Ewq; но поскольку мы доказали, что Qwe тривиальна и значение её переменной не выходит за рамки, нам не надо это опять доказывать и для Ewq надо только доказать, что int ewq не выходит за некоторые рамки. Опять тривиальная структура, доказать корректность которой надо только один раз! Так что не так в композиции таких структур, содержащих одна другую?
А, это действительно выветрилось. Да и ты же не думаешь, что тут один анон за всё ФП отвечает? Ну и про недоказуемость я уже давно согласился, но вот бумажный ФП как раз чисто математический, а отличий бумажного от программного я не вижу, потому что там та же математика, просто аксиомы вроде "1<2" записаны не в общественном договоре между учёными, а в компиляторе. Да, проблемы остаются, но не в самом ФП.
>>488839
Вот смотри, структура Qwe тривиальна, и one_to_hundred не может иметь значения отличного от одного из промежутка 1 - 100, так? И это нам надо доказать только один раз, если мы больше не меняем код именно этой структуры. Потом у нас Ewq; но поскольку мы доказали, что Qwe тривиальна и значение её переменной не выходит за рамки, нам не надо это опять доказывать и для Ewq надо только доказать, что int ewq не выходит за некоторые рамки. Опять тривиальная структура, доказать корректность которой надо только один раз! Так что не так в композиции таких структур, содержащих одна другую?
>>488802
В любом языке, где есть состояния (т.е. не чистый ФП), ты столкнешься с теми же проблемами при верификации, что и в Си. Ты не можешь доказать корректность функции отдельно от всего остального, если это не чистая функция, т.к. тебе придется доказывать корректность состояния, в котором эта функция выполняется. В результате вместо декомпозируемой до примитивных функций программа у нас получается один большой связный граф, где одна хуйня зависит от состояния другой хуйни.
Я не говорю, что пруверы не работают, я это пишу к тому, что твой подход "будем разбивать все на подпрограммы, пока корректность не будет самоочевидной" не работает. Будет работать что-то другое, но точно не это.
Что угодно. Если мы говорим о формальном доказательстве того, что программа будет вести себя корректно на реальном компьютере, а не на сферической в вакууме машине Тьюринга, нам как минимум нужны формально верифицированные:
1. ОС
2. Компилятор
3. Процессор
На практике они не то, что оказываются не верифицированными, они имеют кучу недокументированных возможностей, которые невозможно учесть (потому что хуй тебе Интел про них что-то расскажет). ИРЛ австралийцы может и не отвалятся завтра от земли, а вот в x86 и не такая хуйня может произойти в любой момент выполнения твоей уютненькой верифицированной программы.
В любом языке, где есть состояния (т.е. не чистый ФП), ты столкнешься с теми же проблемами при верификации, что и в Си. Ты не можешь доказать корректность функции отдельно от всего остального, если это не чистая функция, т.к. тебе придется доказывать корректность состояния, в котором эта функция выполняется. В результате вместо декомпозируемой до примитивных функций программа у нас получается один большой связный граф, где одна хуйня зависит от состояния другой хуйни.
Я не говорю, что пруверы не работают, я это пишу к тому, что твой подход "будем разбивать все на подпрограммы, пока корректность не будет самоочевидной" не работает. Будет работать что-то другое, но точно не это.
>Серьёзно, это же тупо машинный код, единицы и нули, что там может пойти не так?
Что угодно. Если мы говорим о формальном доказательстве того, что программа будет вести себя корректно на реальном компьютере, а не на сферической в вакууме машине Тьюринга, нам как минимум нужны формально верифицированные:
1. ОС
2. Компилятор
3. Процессор
На практике они не то, что оказываются не верифицированными, они имеют кучу недокументированных возможностей, которые невозможно учесть (потому что хуй тебе Интел про них что-то расскажет). ИРЛ австралийцы может и не отвалятся завтра от земли, а вот в x86 и не такая хуйня может произойти в любой момент выполнения твоей уютненькой верифицированной программы.
>>488856
Так каким образом в языке без private_cast эта хуйня выходит за рамки? Я не говорю, что она не может выйти в экстремальной ситуации, но если у нас не ёбнулась память и ОС не вредоносный анальный перехватчик, который меняет значения твоих переменных, то как оно выйдет за рамки 1-100 промежутка? Да, если ты будешь куда-то передавать указатель на эту переменную, тебе придётся ещё и за ним следить, но ты же не будешь его передавать по условию. Так как?
Ну и верификация ОС, компилятора и процессора — это уже другой вопрос. Потому что те компании, которым нужно чистое ФП и его плюсы, они как раз могут себе позволить верифицировать весь этот список.
> приведи мне пример обычного программирования без всяких private_cast (потому что в функциональном языке такого тупо нет), в котором значение переменной one_to_hundred не находилось бы между 1 и 100
Так каким образом в языке без private_cast эта хуйня выходит за рамки? Я не говорю, что она не может выйти в экстремальной ситуации, но если у нас не ёбнулась память и ОС не вредоносный анальный перехватчик, который меняет значения твоих переменных, то как оно выйдет за рамки 1-100 промежутка? Да, если ты будешь куда-то передавать указатель на эту переменную, тебе придётся ещё и за ним следить, но ты же не будешь его передавать по условию. Так как?
Ну и верификация ОС, компилятора и процессора — это уже другой вопрос. Потому что те компании, которым нужно чистое ФП и его плюсы, они как раз могут себе позволить верифицировать весь этот список.
>>488869
И много ты таких компаний знаешь? Если ты еще раз кинешь ссылку на Haskell in industry, я тебе уебу.
>Потому что те компании, которым нужно чистое ФП и его плюсы, они как раз могут себе позволить верифицировать весь этот список.
И много ты таких компаний знаешь? Если ты еще раз кинешь ссылку на Haskell in industry, я тебе уебу.
>>488848
То, что, например, множество Мандельброта генерируется следующим кодом
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
Код тривиален, а его поведение - нет.
Любой конечный автомат может иметь тривиальные части, которые будут характеризоваться сложнейшим поведением.
>Так что не так в композиции таких структур, содержащих одна другую?
То, что, например, множество Мандельброта генерируется следующим кодом
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
Код тривиален, а его поведение - нет.
Любой конечный автомат может иметь тривиальные части, которые будут характеризоваться сложнейшим поведением.
483 Кб, 1438x939>>488856
Нет, не нужны.
Реальный мир бесконечно сложный, тщетны попытки что-то понять в нем.
Зато сильно упрощённые примитивные мат модели - вполне себе посильны для понимания и доказательства чего-то в рамках этих моделей.
И главное практически полезны.
Так же как ебнутому идиоту шизику с двачей нельзя ничего доказать, так и в реальности ни в чем нельзя быть уверенным, что не отменяет математических моделей(к которым кстати и ЯП относятся).
При этом одни ЯП дают больше гарантий, другие меньше.
Тот факт что в реальности ваще ничего нельзя доказать не отменять практической выгоды от мат моделей в рамках которых что-то доказать можно.
>>488827
Ну объясни это всем тем компаниям что используют хаскель.
Заодно выступи в ООН, сообщи что институты и академическую науку можно упразднить, потому как научный метод теперь заменяет тестирование и бизнес логика. В РФ вон РАН упразднили, впереди планеты всей.
>Если мы говорим о формальном доказательстве того, что программа будет вести себя корректно на реальном компьютере, а не на сферической в вакууме машине Тьюринга, нам как минимум нужны формально верифицированные:
>1. ОС
>2. Компилятор
>3. Процессор
Нет, не нужны.
>На практике они не то, что оказываются не верифицированными, они имеют кучу недокументированных возможностей, которые невозможно учесть
Реальный мир бесконечно сложный, тщетны попытки что-то понять в нем.
Зато сильно упрощённые примитивные мат модели - вполне себе посильны для понимания и доказательства чего-то в рамках этих моделей.
И главное практически полезны.
Так же как ебнутому идиоту шизику с двачей нельзя ничего доказать, так и в реальности ни в чем нельзя быть уверенным, что не отменяет математических моделей(к которым кстати и ЯП относятся).
При этом одни ЯП дают больше гарантий, другие меньше.
Тот факт что в реальности ваще ничего нельзя доказать не отменять практической выгоды от мат моделей в рамках которых что-то доказать можно.
>>488827
>потому что практично - это не доказывать программу на бумажке в тру-функциональном стиле и стараться ее перенести с минимум ошибок-опечаток, а писать тесты на бизнес-логику.
Ну объясни это всем тем компаниям что используют хаскель.
Заодно выступи в ООН, сообщи что институты и академическую науку можно упразднить, потому как научный метод теперь заменяет тестирование и бизнес логика. В РФ вон РАН упразднили, впереди планеты всей.
>>488881
Никто из тех кто использует хаскель не занимается подобной хуйней, которая тебе кажется с дивана
>Ну объясни это всем тем компаниям что используют хаскель.
Никто из тех кто использует хаскель не занимается подобной хуйней, которая тебе кажется с дивана
>>488881
Скорее вредны, т.к. дают ложную уверенность в том, что программа корректна в любых условиях, хотя это не может быть так. Можно доказать, что программа корректно работает на сферической в вакууме машине, но не то, что она работает на физически существующем кудахтере.
Половина списка Haskell in Industry это пиздеж, если не весь список. Прув ми вронг.
>И главное практически полезны.
Скорее вредны, т.к. дают ложную уверенность в том, что программа корректна в любых условиях, хотя это не может быть так. Можно доказать, что программа корректно работает на сферической в вакууме машине, но не то, что она работает на физически существующем кудахтере.
>Ну объясни это всем тем компаниям что используют хаскель.
Половина списка Haskell in Industry это пиздеж, если не весь список. Прув ми вронг.
>>488889
А ты думал я твой одноклассник что ли?
А ты думал я твой одноклассник что ли?
>>488887
Какой хуйней? Ты с кем вообще говоришь?
Хаскель используют только потому что он автоматически доказывает написанный код.
>>488891
Как ты протестируешь явление о существовании которого ты ещё не знаешь?
>Никто из тех кто использует хаскель не занимается подобной хуйней, которая тебе кажется с дивана
Какой хуйней? Ты с кем вообще говоришь?
Хаскель используют только потому что он автоматически доказывает написанный код.
>>488891
>Тестирование это и есть научный метод, дурачок.
Как ты протестируешь явление о существовании которого ты ещё не знаешь?
>>489029
Ебать ты долбаёб. Раз в программе нет синтаксических ошибок и ошибок с типами, то в ней вообще нет ошибок?
> он автоматически доказывает написанный код
Ебать ты долбаёб. Раз в программе нет синтаксических ошибок и ошибок с типами, то в ней вообще нет ошибок?
>>489559
Новый термин - "синтаксический долбаёб".
Новый термин - "синтаксический долбаёб".
>>489559
Речь идёт о формальной корректности в заданных рамках.
Только Богу доступна полная безошибочность.
Дух захватывает от твоего интеллектуального уровня.
Речь идёт о формальной корректности в заданных рамках.
Только Богу доступна полная безошибочность.
>Ебать ты долбаёб
Дух захватывает от твоего интеллектуального уровня.
>>489723
Ебать ты долбаёб. По твоему, факт успешной компиляции программы на той же сишке - это не "формальная корректность в заданных рамках?
Ебать ты долбаёб. По твоему, факт успешной компиляции программы на той же сишке - это не "формальная корректность в заданных рамках?
>>489759
Вы оба долбоебы, поебитесь уже. Где-нибудь подальше от программача.
Вы оба долбоебы, поебитесь уже. Где-нибудь подальше от программача.
>>477418
Нельзя так просто взять, назвать ОПа пидорасом, и послать на хуй. Ты должен создать иммутабельный клон ОПа с атрибутом "пидорас" уже на хую.
Нельзя так просто взять, назвать ОПа пидорасом, и послать на хуй. Ты должен создать иммутабельный клон ОПа с атрибутом "пидорас" уже на хую.
>>490392
Такой пидорас конечно уникален
Такой пидорас конечно уникален
>>477327 (OP)
Да ты заебал, ты когда уже на оптимизирующиу компиляторы код пересадишь? Или ты под целевую платформу императивную низкоуровневую динамикодрисню пишешь?
>Оверхеды.
Да ты заебал, ты когда уже на оптимизирующиу компиляторы код пересадишь? Или ты под целевую платформу императивную низкоуровневую динамикодрисню пишешь?
>>488714
Здесь композиция записана явно применением оператора композиции. Запись идет слева направо, а вычисления справа налево. Так что мимо.
>>488718
Если зацепление сильное, то тривиальные подпрогрммы становятся довольно большими (у которых между собой зацепление слабое). Это бесспорно затрудняет формальную верификацию, как, в прочем, и любую другую верификацию. Но хорошие программисты стараются ослабить зацепление, даже кучу техник в ООП, например, для этого придумали.
Не может. Теория уже не может наебнуться. Гипотезы - сколько угодно, но не теории. Теории могут перестать использоваться, как геоцентрическая модель Птолемея, например, или стать ограниченными, как ньютоновская механика, но неверными уже никогда не станут.
Ты не понимаешь сути экспериментов. Их ставят:
1 Когда есть несколько конкурирующих теорий, чтобы выбрать наиболее подходящуюю, в этом случае эксперимент может доказать правоту какой-то теории.
2 Когда существующая теория плохо описывает некоторые результаты из ее следствий, чтобы выработать новую гипотезу, в этом случае и так понятно, что теория нихуя не работает при некоторых условиях, но при других работает хорошо и может быть использована. Например, доквантовая модель абсолютно черного тела, ньютонова механика и многие другие до сих пор используются, не смотря на то, что есть более лучшие теории.
На самом деле связь между теорией и экспериментом намного более разнообразная и тесная, чем ты себе её представляешь.
Здесь композиция записана явно применением оператора композиции. Запись идет слева направо, а вычисления справа налево. Так что мимо.
>>488718
>и поведение "тривиальных" подпрограмм зависит от состояния других "тривиальных" подпрограмм.
Если зацепление сильное, то тривиальные подпрогрммы становятся довольно большими (у которых между собой зацепление слабое). Это бесспорно затрудняет формальную верификацию, как, в прочем, и любую другую верификацию. Но хорошие программисты стараются ослабить зацепление, даже кучу техник в ООП, например, для этого придумали.
>Может, если релятивистская механика наебнется вместе с классической
Не может. Теория уже не может наебнуться. Гипотезы - сколько угодно, но не теории. Теории могут перестать использоваться, как геоцентрическая модель Птолемея, например, или стать ограниченными, как ньютоновская механика, но неверными уже никогда не станут.
>Эксперименты не могут доказать теорию в принципе
>Если бы эксперименты доказывали теорию, новых теорий не появлялось бы, потому что ты не можешь опровергнуть уже доказанный факт, это нонсенс.
>Если бы эксперименты доказывали теорию
Ты не понимаешь сути экспериментов. Их ставят:
1 Когда есть несколько конкурирующих теорий, чтобы выбрать наиболее подходящуюю, в этом случае эксперимент может доказать правоту какой-то теории.
2 Когда существующая теория плохо описывает некоторые результаты из ее следствий, чтобы выработать новую гипотезу, в этом случае и так понятно, что теория нихуя не работает при некоторых условиях, но при других работает хорошо и может быть использована. Например, доквантовая модель абсолютно черного тела, ньютонова механика и многие другие до сих пор используются, не смотря на то, что есть более лучшие теории.
На самом деле связь между теорией и экспериментом намного более разнообразная и тесная, чем ты себе её представляешь.
>>491077
Никакого помпажа. Просто решил поставить мнительную сойбойную мл-мартышку на место.
Никакого помпажа. Просто решил поставить мнительную сойбойную мл-мартышку на место.
>>491097
Вот, смотри как быстро, уже произошло принятие. Даже не стал отрицать, что ты сойбой и мл-макака. Правильно, нужно смотреть правде в глаза.
Вот, смотри как быстро, уже произошло принятие. Даже не стал отрицать, что ты сойбой и мл-макака. Правильно, нужно смотреть правде в глаза.
>>491098
Нахуя что-то доказывать бордошизику?
Нахуя что-то доказывать бордошизику?
>>491103
Да с тобой уже все понятно. Ваша программа не программа - ваша программа - это электроны в транзисторах.
Да с тобой уже все понятно. Ваша программа не программа - ваша программа - это электроны в транзисторах.
>>491108
Просто напиши: я не способен формально доказать корректность программы на md5. Я же не спрашиваю причину. Я вижу, что ты это сделать не можешь. А ведь там даже тьюринг-полноты не требуется.
Просто напиши: я не способен формально доказать корректность программы на md5. Я же не спрашиваю причину. Я вижу, что ты это сделать не можешь. А ведь там даже тьюринг-полноты не требуется.
>>491131
Бессмысленно доказывать не мне, а бессмысленно спорить со мной, потому что моя точка зрения гораздо более обоснована, чем твоя. Ты говоришь - "разбить на тривиальные подзадачи". Ну вперед - бери https://gist.github.com/creationix/4710780 и разбивай
Бессмысленно доказывать не мне, а бессмысленно спорить со мной, потому что моя точка зрения гораздо более обоснована, чем твоя. Ты говоришь - "разбить на тривиальные подзадачи". Ну вперед - бери https://gist.github.com/creationix/4710780 и разбивай
>>491135
Ты определись сначала что тебе нужно. Разбить, или доказать?
Как доказать - писал выше - проверить на соответствие спецификации и наличие undefined behavior.
Разбить на подпрограммы можно, но нахуя? Код структурирован хорошо и на первый взгляд соответствует RFC.
Ты определись сначала что тебе нужно. Разбить, или доказать?
Как доказать - писал выше - проверить на соответствие спецификации и наличие undefined behavior.
Разбить на подпрограммы можно, но нахуя? Код структурирован хорошо и на первый взгляд соответствует RFC.
>>491081
Ясно, у борщехлебов в маняфантазиях все охуенно, а на практике их гениальная схема времен Декарта "мы разобьем сложную задачу на простые" не работает, потому что простые задачи цепляются друг за друга. Кто бы мог подумать.
Может. Теория делает предсказания относительно опыта. Если опыт поменяется, то теория будет давать ложные предсказания. Как именно должен поменяться опыт в данном случае неважно.
Теория и не может быть верной или неверной, она может быть научной или не научной.
В остальном ты не сказал ничего, что противоречило бы моим словам, попробуй еще раз.
>Это бесспорно затрудняет формальную верификацию <...> Но хорошие программисты стараются ослабить зацепление
Ясно, у борщехлебов в маняфантазиях все охуенно, а на практике их гениальная схема времен Декарта "мы разобьем сложную задачу на простые" не работает, потому что простые задачи цепляются друг за друга. Кто бы мог подумать.
>Не может. Теория уже не может наебнуться.
Может. Теория делает предсказания относительно опыта. Если опыт поменяется, то теория будет давать ложные предсказания. Как именно должен поменяться опыт в данном случае неважно.
>неверными уже никогда не станут.
Теория и не может быть верной или неверной, она может быть научной или не научной.
В остальном ты не сказал ничего, что противоречило бы моим словам, попробуй еще раз.
>>491333
Что ясно-то? Ты же даже не понимаешь о чем я тебе пишу. Уже по кругу уже ходим.
Это вопрос правильного деления задачи на подзадачи. Если не можешь поделить задачи на элементарные, которые хотя бы можно покрыть юнит-тестами, я уж не упоминаю формальное доказательство - вон из профессии.
Опыт поменяться не может в силу своего определения. Можно получить только новый опыт, который данная теория описать не сможет. Старый опыт может прекрасно ей описываться, сколько не повторяй эксперименты из того старого опыта. А новый опыт (незамеченные закономерности, экстремальные случаи итд) может либо её подтверждать, либо накладывать ограничение на применимость теории, что ведет к новым гипотезам, и, в последствии, к обобщающим теориям.
Верна == проходит экспериментальную проверку. Теория всегда верна в рамках своих границ применимости, ибо теория == экспериментально проверенная гипотеза. Про ненаучность я вообще не говорю, т.к., я надеюсь, речь идет исключительно о научных теориях.
>Ясно,
Что ясно-то? Ты же даже не понимаешь о чем я тебе пишу. Уже по кругу уже ходим.
>потому что простые задачи цепляются друг за друга
Это вопрос правильного деления задачи на подзадачи. Если не можешь поделить задачи на элементарные, которые хотя бы можно покрыть юнит-тестами, я уж не упоминаю формальное доказательство - вон из профессии.
>Если опыт поменяется
Опыт поменяться не может в силу своего определения. Можно получить только новый опыт, который данная теория описать не сможет. Старый опыт может прекрасно ей описываться, сколько не повторяй эксперименты из того старого опыта. А новый опыт (незамеченные закономерности, экстремальные случаи итд) может либо её подтверждать, либо накладывать ограничение на применимость теории, что ведет к новым гипотезам, и, в последствии, к обобщающим теориям.
>Теория и не может быть верной или неверной, она может быть научной или не научной
Верна == проходит экспериментальную проверку. Теория всегда верна в рамках своих границ применимости, ибо теория == экспериментально проверенная гипотеза. Про ненаучность я вообще не говорю, т.к., я надеюсь, речь идет исключительно о научных теориях.
>>491555
Эксперимент может быть удачным (для теории) стечением обстоятельств. Поэтому доказать теорию невозможно.
>Верна == проходит экспериментальную проверку.
Эксперимент может быть удачным (для теории) стечением обстоятельств. Поэтому доказать теорию невозможно.
>>491555
Программы в общем случае не являются деревом, это граф с циклами.
Есть такая игра - супер марио. В ней объекты мира - довольно примитивны, типа с вшитым алгоритмом уровня "идти, пока не встретишь край, дальше развернуться". Но количество возможных комбинаций объектов таково, что новые баги открывают то сих пор, через 30 лет после выхода. И это - правило, а не исключение. Любой код, управляемый данными, содержит непредсказуемые комбинации этих самых данных. А это любой код, в котором есть пункт меню "файл-открыть..." .
Маня сдалась и поняла, что в формальные доказательства не может
>Это вопрос правильного деления задачи на подзадачи.
Программы в общем случае не являются деревом, это граф с циклами.
Есть такая игра - супер марио. В ней объекты мира - довольно примитивны, типа с вшитым алгоритмом уровня "идти, пока не встретишь край, дальше развернуться". Но количество возможных комбинаций объектов таково, что новые баги открывают то сих пор, через 30 лет после выхода. И это - правило, а не исключение. Любой код, управляемый данными, содержит непредсказуемые комбинации этих самых данных. А это любой код, в котором есть пункт меню "файл-открыть..." .
>которые хотя бы можно покрыть юнит-тестами
Маня сдалась и поняла, что в формальные доказательства не может
>>491582
Есть такое понятие, как воспроизводимость. Или ты думаешь эксперимент, который поставил один раз один моченый и больше никто не смог, примут в качестве доказательства верности гипотезы, или доказательства следствий из теории?
Если ты не знал, то та же элементарная механика перепроверяется в повседневной жизни инженерами. Доказательство тому - тысячи работающих автомобилей, стоящих зданий, мостов и создание и разработка прочих достижений науки и техники.
Есть такое понятие, как воспроизводимость. Или ты думаешь эксперимент, который поставил один раз один моченый и больше никто не смог, примут в качестве доказательства верности гипотезы, или доказательства следствий из теории?
Если ты не знал, то та же элементарная механика перепроверяется в повседневной жизни инженерами. Доказательство тому - тысячи работающих автомобилей, стоящих зданий, мостов и создание и разработка прочих достижений науки и техники.
>>488787
К слову, g зависит от гравитационной постоянной, массы Земли и радиуса Земли. И от скорости вращения Земли ещё, потому что центростремительная сила.
Если изменится гравитационная постоянная — тебя распидорасит.
Если от Земли оторвётся кусок такого размера, что УСП изменится на 0.1 — тебя распидорасит вместе с планетой.
Если завтра радиус Земли внезапно увеличится на двадцать-тридцать километров — тебя распидорасит. Для сравнения, высота Эвереста над морем — всего девять километров.
И, наконец, если Земля ускорит своё вращение, тебя снова распидорасит. Не сразу, как в случаях до этого, но всё равно.
К слову, g зависит от гравитационной постоянной, массы Земли и радиуса Земли. И от скорости вращения Земли ещё, потому что центростремительная сила.
Если изменится гравитационная постоянная — тебя распидорасит.
Если от Земли оторвётся кусок такого размера, что УСП изменится на 0.1 — тебя распидорасит вместе с планетой.
Если завтра радиус Земли внезапно увеличится на двадцать-тридцать километров — тебя распидорасит. Для сравнения, высота Эвереста над морем — всего девять километров.
И, наконец, если Земля ускорит своё вращение, тебя снова распидорасит. Не сразу, как в случаях до этого, но всё равно.
>>491584
Сынок, блядь, ознакомся с основами современной науки и не неси очевидную хуйню с умным видом.
Сынок, блядь, ознакомся с основами современной науки и не неси очевидную хуйню с умным видом.
>>491585
Хуесли. А еще g зависит от высоты. На высоте МКС g меньше девятки. И где твой пиздежь теперь?
>Если изменится гравитационная постоянная — тебя распидорасит.
>Если от Земли оторвётся кусок такого размера, что УСП изменится на 0.1 — тебя распидорасит вместе с планетой.
>Если завтра радиус Земли внезапно увеличится на двадцать-тридцать километров — тебя распидорасит. Для сравнения, высота Эвереста над морем — всего девять километров.
>И, наконец, если Земля ускорит своё вращение, тебя снова распидорасит. Не сразу, как в случаях до этого, но всё равно.
Хуесли. А еще g зависит от высоты. На высоте МКС g меньше девятки. И где твой пиздежь теперь?
>>491583
И как это мешает осуществить формальное доказательство?
Код управляемый данными - по сути интерпретатор, а данные - программа для него. Очевидно, либо необходимо доказательство корректности данных (т.е. программы), либо доказательство способности интерпретатора отвергнуть некорректную комбинацию данных.
То, что можно покрыть юнит-тестами, является достаточно мелкой подпрограммой и поддается несложному формальному доказательству.
>Программы в общем случае не являются деревом, это граф с циклами.
И как это мешает осуществить формальное доказательство?
>Любой код, управляемый данными, содержит непредсказуемые комбинации этих самых данных.
Код управляемый данными - по сути интерпретатор, а данные - программа для него. Очевидно, либо необходимо доказательство корректности данных (т.е. программы), либо доказательство способности интерпретатора отвергнуть некорректную комбинацию данных.
>Маня сдалась и поняла, что в формальные доказательства не может
То, что можно покрыть юнит-тестами, является достаточно мелкой подпрограммой и поддается несложному формальному доказательству.
>>491649
А это невозможно из-за комбинаторного взрыва.
Нет. Тест дедуктивен, а формальное доказательство индуктивно.
Например, чтобы доказать корректность кода который ты приводил выше тестом, тебе достаточно проверить 3 случая. Чтобы доказать этот же код формально, тебе нужен аппарат зависимых типов (даже если ты будешь доказывать на бумажке - что лично ты сделать не в состоянии, и все твои "формальные доказательства" это детский сад уровня "НУ ЭТО ЖЕ ОЧЕВИДНО ЧТО ТУТ НЕ МОЖЕТ БЫТЬ ОШИБКИ", все равно нужна теория).
>Очевидно, либо необходимо доказательство корректности данных (т.е. программы), либо доказательство способности интерпретатора отвергнуть некорректную комбинацию данных.
А это невозможно из-за комбинаторного взрыва.
>То, что можно покрыть юнит-тестами, является достаточно мелкой подпрограммой и поддается несложному формальному доказательству.
Нет. Тест дедуктивен, а формальное доказательство индуктивно.
Например, чтобы доказать корректность кода который ты приводил выше тестом, тебе достаточно проверить 3 случая. Чтобы доказать этот же код формально, тебе нужен аппарат зависимых типов (даже если ты будешь доказывать на бумажке - что лично ты сделать не в состоянии, и все твои "формальные доказательства" это детский сад уровня "НУ ЭТО ЖЕ ОЧЕВИДНО ЧТО ТУТ НЕ МОЖЕТ БЫТЬ ОШИБКИ", все равно нужна теория).
>>491685
Если перебором, то конечно.
Индуктивный - лишь один из методов доказательства.
>А это невозможно из-за комбинаторного взрыва.
Если перебором, то конечно.
>Нет. Тест дедуктивен, а формальное доказательство индуктивно.
Индуктивный - лишь один из методов доказательства.
>>491649
Юнит-тест - это почти любой тест, написанный программистом для своего кода. Если ты тестируешь какой-то юнит и тот юнит в качестве части своей работы дергает другой юнит(например, чтобы отфильтровать массив), то тест внезапно не становится интеграционным или еще каким. Так что чекай определения.
>То, что можно покрыть юнит-тестами, является достаточно мелкой подпрограммой
Юнит-тест - это почти любой тест, написанный программистом для своего кода. Если ты тестируешь какой-то юнит и тот юнит в качестве части своей работы дергает другой юнит(например, чтобы отфильтровать массив), то тест внезапно не становится интеграционным или еще каким. Так что чекай определения.
Юнит тесты тот еще обман десятилетия.
Нет, конечно, тестирование любого кода реально помогает баги обнаружить, но само юнит тестирование работает нормально только когда у тебя чистые функции, если же нет, то начинается натягивание моков на глобус.
Нет, конечно, тестирование любого кода реально помогает баги обнаружить, но само юнит тестирование работает нормально только когда у тебя чистые функции, если же нет, то начинается натягивание моков на глобус.
>>500412
Моки нужны только для тестирования вещей, над которыми у тебя нет прямого контроля. Например, вызов БД мокать не стоит, потому что ты и так можешь вызвать реальную БД в транзакции и в конце теста эту транзакцию отменить, либо вообще ресетить БД полностью в начале каждого теста, если речь идет о какой-нибудь не поддерживающей транзакции параше уровня монги. И уж тем более не стоит мокать никакой из кусков кода, принадлежащих твоему приложению(это включает себя в том числе и либы). Единственное, где без моков не обойтись - это вызовы сторонних API, которые ты никак не контролируешь. Например, запрос на сторонний сервер или эвент с вебсокет-сервера.
Моки - это инструмент установления тотального контроля над чем-то, и если тебе приходится устанавливать тотальный контроль над своим собственным кодом для тестирования оного, то скорее всего ты что-то делаешь не так. Если хочется повысить скорость выполнения тестов, то это решается не через моки, а через вынесение логики из прожорливых компонентов в более простые и изолированные.
Моки нужны только для тестирования вещей, над которыми у тебя нет прямого контроля. Например, вызов БД мокать не стоит, потому что ты и так можешь вызвать реальную БД в транзакции и в конце теста эту транзакцию отменить, либо вообще ресетить БД полностью в начале каждого теста, если речь идет о какой-нибудь не поддерживающей транзакции параше уровня монги. И уж тем более не стоит мокать никакой из кусков кода, принадлежащих твоему приложению(это включает себя в том числе и либы). Единственное, где без моков не обойтись - это вызовы сторонних API, которые ты никак не контролируешь. Например, запрос на сторонний сервер или эвент с вебсокет-сервера.
Моки - это инструмент установления тотального контроля над чем-то, и если тебе приходится устанавливать тотальный контроль над своим собственным кодом для тестирования оного, то скорее всего ты что-то делаешь не так. Если хочется повысить скорость выполнения тестов, то это решается не через моки, а через вынесение логики из прожорливых компонентов в более простые и изолированные.
>>477327 (OP)
Чувак, у всего есть своя область адекватного применения, прими таблетки и успокойся. Где нужно иммутабельность используется, где не нужно -- не используется. В крайности впадают либо хипстеры, либо долбоебы, что, как правило, одно и то же.
> бугуртит с иммутабельности
> всерьез приводит в пример платформеры требующие по 8 гигов и написанные какими-то дегродами на коленке в качестве примера без пруфов
> также всерьез уверен, что в скомпиленном коде реально будет создан новый объект, а не переиспользован предыдущий по возможности
> нихуя не знает про устройство сборщиков мусора и прочей еботни
> считает каждый байт даже в том случае, когда это явно в ущерб скорости выполнения программы
Чувак, у всего есть своя область адекватного применения, прими таблетки и успокойся. Где нужно иммутабельность используется, где не нужно -- не используется. В крайности впадают либо хипстеры, либо долбоебы, что, как правило, одно и то же.
>>479400
Понятность кода -- вещь весьма и весьма субъективная.
Лично мне понятнее и логичнее кажется функциональный код, но у меня бэкграунд в лямбда-исчислении и теории типов имеется. Императивщина становится намного менее интуитивной, когда пытаешься относительно императивного кода что-то доказать. Тесты не катят, для софта в критических областях именно доказательства корректности программ строят.
Понятность кода -- вещь весьма и весьма субъективная.
Лично мне понятнее и логичнее кажется функциональный код, но у меня бэкграунд в лямбда-исчислении и теории типов имеется. Императивщина становится намного менее интуитивной, когда пытаешься относительно императивного кода что-то доказать. Тесты не катят, для софта в критических областях именно доказательства корректности программ строят.
>>505683
В ФП тоже можно написать непонятный трудночитаемый код. Тут вообще не от парадигмы зависит, а от скила написавшего.
В ФП тоже можно написать непонятный трудночитаемый код. Тут вообще не от парадигмы зависит, а от скила написавшего.
сложно
>>479780
скала норм язык, прост с очень высоким порогом вхождения поэтому средний проект на скале выглядит как говно
скала норм язык, прост с очень высоким порогом вхождения поэтому средний проект на скале выглядит как говно
>>479400
Нет, потому что тебе читая код одной функции/процедуры нужно в голове при этом держать дельту состояния программы после выполнения n строк кода этой функции. Поэтому код разбивают на как можно большее количество функций и процедур, которые вызывают потом друг друга. А ФПбляди такие, хей, а почему бы нам сразу не построить все вокруг функций, а состояние пробрасывать через них?
>>477330
Але блять, это гейдев, там всегда будет подобного рода байтоебство, глупо мерить все ойти по меркам гейдева. Скрипты для emacs ты тоже предлагаешь на крестах писать?
>любая императивщина как раз воспринимается легче и интуитивнее
Нет, потому что тебе читая код одной функции/процедуры нужно в голове при этом держать дельту состояния программы после выполнения n строк кода этой функции. Поэтому код разбивают на как можно большее количество функций и процедур, которые вызывают потом друг друга. А ФПбляди такие, хей, а почему бы нам сразу не построить все вокруг функций, а состояние пробрасывать через них?
>>477330
Але блять, это гейдев, там всегда будет подобного рода байтоебство, глупо мерить все ойти по меркам гейдева. Скрипты для emacs ты тоже предлагаешь на крестах писать?
>>477376
На работе у нас в проекте получается ускорение в полтора раза просто за счет добавление ключика "-mhaswell" в параметры компиляции.
Но у нас код не совсем обычный, со всякими там умножениями матриц 10000х10000
На работе у нас в проекте получается ускорение в полтора раза просто за счет добавление ключика "-mhaswell" в параметры компиляции.
Но у нас код не совсем обычный, со всякими там умножениями матриц 10000х10000
>>511671
Наоборот, только так и нужно мерять. Игры всего лишь требуют больше всего ресурсов, поэтому оптимизация в первых рядах, но это не значит, что в программах не столь требовательных можно хуй забить. хуезабивалово это скользкая дорожка, ведущая к тотальной деградации программирования, которая в итоге и игры уже охватила, и небо и аллаха, и мы сейчас тонем в болоте дерьмософте, когда могли бы лететь к звёздам на том же железе.
>Але блять, это гейдев, там всегда будет подобного рода байтоебство, глупо мерить все ойти по меркам гейдева.
Наоборот, только так и нужно мерять. Игры всего лишь требуют больше всего ресурсов, поэтому оптимизация в первых рядах, но это не значит, что в программах не столь требовательных можно хуй забить. хуезабивалово это скользкая дорожка, ведущая к тотальной деградации программирования, которая в итоге и игры уже охватила, и небо и аллаха, и мы сейчас тонем в болоте дерьмософте, когда могли бы лететь к звёздам на том же железе.
>>511790
Совсем наркоман обкурился, на компьютерах летать хочет
>когда могли бы лететь к звёздам на том же железе.
Совсем наркоман обкурился, на компьютерах летать хочет
>>511790
Игры ничего не требуют, это издатели соревнуются, кто запилит более охуенную графику на слабом железе, поэтому программисты оптимизируют код как могут. Оптимизация -- это не что-то само собой разумеющееся, что вытекает из "правильных" практик программирования, те же хитровыебанные технологии вроде bsp -- это просто оптимизация, чтобы не рисовать каждый раз то, что игрок и так не увидит.
Забивание на оптимизацию не ведет к деградации, оно ведет только к более хуевой графике, что в инди игре в принципе терпимо. В остальном ты только выигрываешь в плане более простого дизайна программы и меньшего количества строк кода, дизайн проще менять и рефакторить.
Деградация происходит из-за каргоархитектуры и того, что кодеры ставят софт скиллы выше хард скиллов, т.е. социальные практики выше технических практик, и в общем то первое прямо вытекает из второго. Макаки не могут годами сделать одну веб страницу с логикой уровня программы на бейсике не из-за того, что они не умеют в оптимизации, с оптимизациями они бы делали страницу не годы, а десятилетия. Послушай, что Джон Блоу говорит на этот счет.
https://www.youtube.com/watch?v=dS6rCaDSwW8
>Игры всего лишь требуют больше всего ресурсов
Игры ничего не требуют, это издатели соревнуются, кто запилит более охуенную графику на слабом железе, поэтому программисты оптимизируют код как могут. Оптимизация -- это не что-то само собой разумеющееся, что вытекает из "правильных" практик программирования, те же хитровыебанные технологии вроде bsp -- это просто оптимизация, чтобы не рисовать каждый раз то, что игрок и так не увидит.
>хуезабивалово это скользкая дорожка, ведущая к тотальной деградации программирования
Забивание на оптимизацию не ведет к деградации, оно ведет только к более хуевой графике, что в инди игре в принципе терпимо. В остальном ты только выигрываешь в плане более простого дизайна программы и меньшего количества строк кода, дизайн проще менять и рефакторить.
Деградация происходит из-за каргоархитектуры и того, что кодеры ставят софт скиллы выше хард скиллов, т.е. социальные практики выше технических практик, и в общем то первое прямо вытекает из второго. Макаки не могут годами сделать одну веб страницу с логикой уровня программы на бейсике не из-за того, что они не умеют в оптимизации, с оптимизациями они бы делали страницу не годы, а десятилетия. Послушай, что Джон Блоу говорит на этот счет.
https://www.youtube.com/watch?v=dS6rCaDSwW8
>>477330
Не туда воюешь, дебил. Современный геймдев душат не программисты на хаскелях и лиспах, а сирешетка-дебилы, которые искренне считают, что хуюнити - это взаправдашний игровой движок.
>Вас, куколдов, сойбоев, педерастов, пассивных пидоров, которые убили блять все программирование. Пидорасы, вы ебаные, жидовье, блять. Иммутабельность они продвигают.
Не туда воюешь, дебил. Современный геймдев душат не программисты на хаскелях и лиспах, а сирешетка-дебилы, которые искренне считают, что хуюнити - это взаправдашний игровой движок.
У меня стойкое ощущение, что здесь почти никто не понимает, о чём пиздит
>>486705
Не получается же
Не получается же
>>511671
Действительно, ведь императивный код никак нельзя разбивать на функции, модули, саб-рутины и прочее. Все пишется в один файл на 10 тыщ строк.
Действительно, ведь императивный код никак нельзя разбивать на функции, модули, саб-рутины и прочее. Все пишется в один файл на 10 тыщ строк.
>>518308
Если бы ты внимательно перечитал мое сообщение, ты бы понял, что я нигде не пишу, что в императивщине нельзя все разбивать на функции, это ты хуйню какую-то в голове себе придумал и сам с ней споришь.
Если бы ты внимательно перечитал мое сообщение, ты бы понял, что я нигде не пишу, что в императивщине нельзя все разбивать на функции, это ты хуйню какую-то в голове себе придумал и сам с ней споришь.
>>518635
Это вот это вот и есть:
вся суть функциональщины
>это ты хуйню какую-то в голове себе придумал и сам с ней споришь.
Это вот это вот и есть:
>ФПбляди такие, хей, а почему бы нам сразу не построить все вокруг функций, а состояние пробрасывать через них?
вся суть функциональщины
>>518756
Пушо есть idea?
Пушо есть idea?
>>518637
Ну толсто ведь
> имплаинг иметь возможность разбивать код на функции и строить все вокруг функций одно и то же
Ну толсто ведь
>>477327 (OP)
Дальше не читал. Очевидно, что у тебя нет никакого опыта. Попробуй вместо рассуждений о теории, писать много кода. Вот тогда и поймешь, почему иммутабельность лучше изменяемого состояния.
>Во-первых, состояния объектов один из самых маленьких источников ошибок.
Дальше не читал. Очевидно, что у тебя нет никакого опыта. Попробуй вместо рассуждений о теории, писать много кода. Вот тогда и поймешь, почему иммутабельность лучше изменяемого состояния.
>>531814
Можно пример, где изменяемое состояние провоцирует ошибку, а иммутабельность спасает?
Можно пример, где изменяемое состояние провоцирует ошибку, а иммутабельность спасает?
>>532122
fn some_not_obvious_name(a: &mut Object) { a = GLOBAL_B; }
fn main() {
let a = Object::new();
some_not_obvious_name(&a);
println!("{:?}", a);
}
fn some_not_obvious_name(a: &mut Object) { a = GLOBAL_B; }
fn main() {
let a = Object::new();
some_not_obvious_name(&a);
println!("{:?}", a);
}
>>531814
Иммутабельность непригодна ИРЛ. Подходит только для примеров кода в борщехлебских бложеках.
Иммутабельность непригодна ИРЛ. Подходит только для примеров кода в борщехлебских бложеках.
Пацаны, го проходить по веткам дерева через цикл! Ух бля!
Я за то, чтобы все ПО УМОЛЧАНИЮ было иммутабельно и константно, и если ты ГОЛОВОЙ понимаешь, что хочешь мутиции объекта/колекции/поля - ставишь какой-нибудь модификатор
>>532122
Любой код где есть переменные, которые в последствии изменяются, уже является злом. Поэтому считается хорошей практикой использовать где только возможно константы. Линтеры ругаются когда используешь переменную, там где можно было использовать константу.
Никакого оверхеда нет. Давно уже разработаны умные компиляторы/интерпретаторы, которые сами следят за памятью. В языке Erlang и многих других, вообще нет переменных как таковых, если назначил имени значение, то потом изменить это уже нельзя, можно только создать новое, а виртуальная машина сама позаботится чтобы все было быстро и память не текла.
Везде сейчас есть иммутабельные структуры данных, даже в не функциональных языках. Не просто так это делается, это необходимость. Когда-то, да и по сей день некоторые непонимающие твердят, что мол функциональные языки дают оверхед, и бла-бла-бла. Полная чепуха это все. Современные компиляторы хорошо оптимизируют все опирации, никакой горе-программист не способен вручную так эффективно управлять памятью. Поэтому его код никогда не будет быстрее.
Любой код где есть переменные, которые в последствии изменяются, уже является злом. Поэтому считается хорошей практикой использовать где только возможно константы. Линтеры ругаются когда используешь переменную, там где можно было использовать константу.
Никакого оверхеда нет. Давно уже разработаны умные компиляторы/интерпретаторы, которые сами следят за памятью. В языке Erlang и многих других, вообще нет переменных как таковых, если назначил имени значение, то потом изменить это уже нельзя, можно только создать новое, а виртуальная машина сама позаботится чтобы все было быстро и память не текла.
Везде сейчас есть иммутабельные структуры данных, даже в не функциональных языках. Не просто так это делается, это необходимость. Когда-то, да и по сей день некоторые непонимающие твердят, что мол функциональные языки дают оверхед, и бла-бла-бла. Полная чепуха это все. Современные компиляторы хорошо оптимизируют все опирации, никакой горе-программист не способен вручную так эффективно управлять памятью. Поэтому его код никогда не будет быстрее.
>>532144
Идейно крепкий речекряк!
Идейно крепкий речекряк!
>>532125
То есть переменная а передается по ссылке в функцию, там ее значение меняется по ошибке. Я правильно понимаю? Ну в обычных языках есть const для этого, а что привносят иммутабельные языки?
То есть переменная а передается по ссылке в функцию, там ее значение меняется по ошибке. Я правильно понимаю? Ну в обычных языках есть const для этого, а что привносят иммутабельные языки?
>>532144
Это не пример, а мантра какая-то.
Это не пример, а мантра какая-то.
>>532137
Есть игровой персонаж. У него позиция, вращение, скорость, здоровье, мана и т.д. Это все должно быть иммутабельным?
Есть игровой персонаж. У него позиция, вращение, скорость, здоровье, мана и т.д. Это все должно быть иммутабельным?
>>532144
а я вот всё не понимаю, а нахуя? я слышал говорили про дебаг, что-то там стейты. а что дебагеры не могут разобрать изменяемые данные на стейты? можете какие-нибудь статьи кинуть, за смысл?
в принципе, в лиспе я понимаю, там код раскладывается в портянку и по идее можно её весело наворачивать как макароны на вилку, при ошибке. но кажется, это просто проще в плане написать такой интерпритатор, чем ещё и дебагер к нему.
а я вот всё не понимаю, а нахуя? я слышал говорили про дебаг, что-то там стейты. а что дебагеры не могут разобрать изменяемые данные на стейты? можете какие-нибудь статьи кинуть, за смысл?
в принципе, в лиспе я понимаю, там код раскладывается в портянку и по идее можно её весело наворачивать как макароны на вилку, при ошибке. но кажется, это просто проще в плане написать такой интерпритатор, чем ещё и дебагер к нему.
>>532268
если что извините что влезаю, наверняка я нихрена не понимаю о чём речь.
если что извините что влезаю, наверняка я нихрена не понимаю о чём речь.
>>532249
В дефолтно иммутабельных, типа раста, — "let" короче "mut let", а в дефолтно мутабельных "const" — опциональный параметр, который долбаёбам лень писать. В расте сделать что-то иммутабельное проще, чем мутабельное, а в крестах — наоборот. Поэтому в расте, если это не какой-то хитрый RefCell<>, проще знать, что там со значением (а конпелятор ещё и ворнинг выдаст на лишний 'mut' в твоём "let mut a". В крестах же ты никогда не узнаешь, изменилась или нет переменная, если писатель кода не будет так любезен проставлять везде "const". И не надо мне тут про "ну, вот рефселл же есть, какая иммутабельность!", потому что в крестах всё ещё хуже — const_cast там хуй определишь, оно даже в типе переменной не отображается.
В дефолтно иммутабельных, типа раста, — "let" короче "mut let", а в дефолтно мутабельных "const" — опциональный параметр, который долбаёбам лень писать. В расте сделать что-то иммутабельное проще, чем мутабельное, а в крестах — наоборот. Поэтому в расте, если это не какой-то хитрый RefCell<>, проще знать, что там со значением (а конпелятор ещё и ворнинг выдаст на лишний 'mut' в твоём "let mut a". В крестах же ты никогда не узнаешь, изменилась или нет переменная, если писатель кода не будет так любезен проставлять везде "const". И не надо мне тут про "ну, вот рефселл же есть, какая иммутабельность!", потому что в крестах всё ещё хуже — const_cast там хуй определишь, оно даже в типе переменной не отображается.
>>532255
Ставишь модификатор типа переменной, тот же "mut" в расте, — получаешь мутабельную переменную. Не ставишь — получаешь иммутабельную. Он же тебе не про анальную иммутабельность говорит, а про дефолтную, но опциональную.
Ставишь модификатор типа переменной, тот же "mut" в расте, — получаешь мутабельную переменную. Не ставишь — получаешь иммутабельную. Он же тебе не про анальную иммутабельность говорит, а про дефолтную, но опциональную.
>>532289
Тогда мне mut придется ставить на 90% переменных. Не проще ли на 10% констант поставить const? Или нужно какое-то иное мышление?
Тогда мне mut придется ставить на 90% переменных. Не проще ли на 10% констант поставить const? Или нужно какое-то иное мышление?
>>532387
Это бы играло роль, если бы программисты набирали код непрерывно, но по факту - очень много времени тратится на чтение кода и на раздумья, а как какать его написать.
Да и на объявление полей не так много времени тратится, как на операции над ними. Поэтому подход, принятый в расте действительно хорош
Это бы играло роль, если бы программисты набирали код непрерывно, но по факту - очень много времени тратится на чтение кода и на раздумья, а как какать его написать.
Да и на объявление полей не так много времени тратится, как на операции над ними. Поэтому подход, принятый в расте действительно хорош
>>532437 (Del)
Поле, которое нигде не меняется лучше определить как константу, по факту.
Дело не в том, что кто-нибудь это сделает, дело в том, что ты можешь сделать это, например, при помощи какой-нибудь функциональной либы, которая совершенно неожиданно для тебя может мутировать твой объект, а не вернуть измененную копию. И узнать это можно не всегда, читать доку к каждому ссаному методу мне вот на хуй не надо
Поле, которое нигде не меняется лучше определить как константу, по факту.
Дело не в том, что кто-нибудь это сделает, дело в том, что ты можешь сделать это, например, при помощи какой-нибудь функциональной либы, которая совершенно неожиданно для тебя может мутировать твой объект, а не вернуть измененную копию. И узнать это можно не всегда, читать доку к каждому ссаному методу мне вот на хуй не надо
Проиграл с мочуха. Чего тебе жопу разорвало, бедняжка жопаскриптерская?
>>532439
Если ты передаешь что-то в стороннюю либу, то в 99% это либо базовая структура языка, либо структура той либы. В обоих случаях никакие константы тебе не помогут.
>>532439
Если ты передаешь что-то в стороннюю либу, то в 99% это либо базовая структура языка, либо структура той либы. В обоих случаях никакие константы тебе не помогут.
>>532451
если бы иммутабельность была по умолчанию, то в подобных либах де факто было бы стандартом делать по две реализации для одного и того же метода аля MutableRever и ImmutableRevert, из названия которых очевидно что они делают.
Особенно неудобно, когда часть библиотечных методов мутируют что-то, а другая часть возвращают измененную копию. И я конечно не гинеколог, но это пизда
если бы иммутабельность была по умолчанию, то в подобных либах де факто было бы стандартом делать по две реализации для одного и того же метода аля MutableRever и ImmutableRevert, из названия которых очевидно что они делают.
Особенно неудобно, когда часть библиотечных методов мутируют что-то, а другая часть возвращают измененную копию. И я конечно не гинеколог, но это пизда
>>532451
Дура, ты не знаешь что ли, что константы есть во всех языках, а не только в Джаваскрипте?
Дура, ты не знаешь что ли, что константы есть во всех языках, а не только в Джаваскрипте?
>>532523
Да там глубоко похуй, как они называются, потому что ты в передаваемом типе видишь, будет эта хуета изменяться, или нет.
fn pohui_name(data: &mut Data) { /.../ } // Изменяется в функции.
fn pizda_name(data: &Data) { /.../ } // Не изменяется.
fn yoba_name(data: Data) { /.../ } // Move semantics; если не Copy примитив (int, uint, char, bool), то съедается функцией и дропается где-то в ней.
Да там глубоко похуй, как они называются, потому что ты в передаваемом типе видишь, будет эта хуета изменяться, или нет.
fn pohui_name(data: &mut Data) { /.../ } // Изменяется в функции.
fn pizda_name(data: &Data) { /.../ } // Не изменяется.
fn yoba_name(data: Data) { /.../ } // Move semantics; если не Copy примитив (int, uint, char, bool), то съедается функцией и дропается где-то в ней.
>>532542
impl Data{
fn foo(&self) {}
fn bar(&mut self) {}
fn foobar(self) {}
fn yaboo() {} // Ошибка, нельзя без "self" вызывать функцию на объект, как раз потому что ты вызываешь её на объект.
// Хочешь просто функцию, пиши её просто в модуль, а не в методы.
}
Те же самые правила, "self" — кейворд для обозначения объекта, на который ты вызываешь эту функцию.
impl Data{
fn foo(&self) {}
fn bar(&mut self) {}
fn foobar(self) {}
fn yaboo() {} // Ошибка, нельзя без "self" вызывать функцию на объект, как раз потому что ты вызываешь её на объект.
// Хочешь просто функцию, пиши её просто в модуль, а не в методы.
}
Те же самые правила, "self" — кейворд для обозначения объекта, на который ты вызываешь эту функцию.
>>532552
Но когда читаешь код, ты этого не видишь, поэтому sort и sorted, чтобы не лезть каждый раз в декларацию
Но когда читаешь код, ты этого не видишь, поэтому sort и sorted, чтобы не лезть каждый раз в декларацию
>>532552
А, стоп, я проебался, можно и без "self" функцию для класса сделать (то есть, та же fn yaboo() сконпелируется), но вызывать её на объект нельзя, вызывается только как обычная функция:
yobalib::Data::yaboo();
let a = Data::default();
a.yaboo(); // Вот тут ошибка, так нельзя!
А, стоп, я проебался, можно и без "self" функцию для класса сделать (то есть, та же fn yaboo() сконпелируется), но вызывать её на объект нельзя, вызывается только как обычная функция:
yobalib::Data::yaboo();
let a = Data::default();
a.yaboo(); // Вот тут ошибка, так нельзя!
>>532567
Когда читаешь без удобных подсветочек, да, не видно нихуя. Но при попытке компиляции оно тебе выдаст "bar() takes &mut self, a ti tuda pihaesh &self" и не сконпелирует. А если ты про что-то другое, то мутабельность смотрится в объявлении:
let a = 0;
let mut b = a.clone();
Когда читаешь без удобных подсветочек, да, не видно нихуя. Но при попытке компиляции оно тебе выдаст "bar() takes &mut self, a ti tuda pihaesh &self" и не сконпелирует. А если ты про что-то другое, то мутабельность смотрится в объявлении:
let a = 0;
let mut b = a.clone();
В этом треде зумеры-растаманы с радостным удивлением открывают для себя мир ключевого слова const, имевшего место в C с одна тысяча девятьсот шестьдесят восьмого года. Дикая природа удивительна.
>>533471
Речь ведь как раз в том, что это самое const может быть по дефолту, а mut опционально, и это делает программирование менее рискованным, ведь ничего измениться без твоего желания просто не может.
Речь ведь как раз в том, что это самое const может быть по дефолту, а mut опционально, и это делает программирование менее рискованным, ведь ничего измениться без твоего желания просто не может.
>>533471
ритчи с томпсоном, кстати, добавили const в язык только под давлением общественности и сильно не хотели этого делать
ритчи с томпсоном, кстати, добавили const в язык только под давлением общественности и сильно не хотели этого делать
>>533548
Кстати, да, не шарили. Но "не шарили" — старая проблема, родилась прямо с человечеством. Тот же Эйнштейн — гений. Но неужели было так сложно сделать то, что сделал он? Опять проблема "не шарили". Но даже ОТО этого безумного учёного скоро подвинут, потому что квантмех говорит, что ОТО — хуета с ограниченной областью применения, как классическая механика, а квантмеху верят больше.
Кстати, да, не шарили. Но "не шарили" — старая проблема, родилась прямо с человечеством. Тот же Эйнштейн — гений. Но неужели было так сложно сделать то, что сделал он? Опять проблема "не шарили". Но даже ОТО этого безумного учёного скоро подвинут, потому что квантмех говорит, что ОТО — хуета с ограниченной областью применения, как классическая механика, а квантмеху верят больше.
>>533548
Они не шарили, потому что императивщики, наследие ассемблера и фортрана. Кстати, ни один императивный язык не привнес ничего нового ни в языки, ни в компиляторы/интерпретаторы. Все крутые фичи привнесли функциональные языки. Сборка мусора, метапрограммирование, и т.д. и т.п. И по сей день так происходит.
Они не шарили, потому что императивщики, наследие ассемблера и фортрана. Кстати, ни один императивный язык не привнес ничего нового ни в языки, ни в компиляторы/интерпретаторы. Все крутые фичи привнесли функциональные языки. Сборка мусора, метапрограммирование, и т.д. и т.п. И по сей день так происходит.
>>533590
Вся суть тупости мамкиных функциональных шизиков. И ведь этот дурачок всерьез.
Вся суть тупости мамкиных функциональных шизиков. И ведь этот дурачок всерьез.
>>533595
Дура, матчасть подтяни. Впервые сборщик мусора появился не в Джаве, как тебе в школе сказали, а в Лиспе, в далеких 50-60-хх годах. Тормоз пля.
Дура, матчасть подтяни. Впервые сборщик мусора появился не в Джаве, как тебе в школе сказали, а в Лиспе, в далеких 50-60-хх годах. Тормоз пля.
>>533595
(вы находитесь здесь)
> спиздить из лиспа в мейнстрим условный оператор с блоками кода в плечах вместо goto
> спиздить из лиспа в мейнстрим рекурсивные вызовы
> спиздить из лиспа в мейнстрим динамическую типизацию
> спиздить из лиспа в мейнстрим сборку мусора
> спиздить из лиспа в мейнстрим первоклассные функции
> спиздить из лиспа в мейнстрим keyword-аргументы (Гвидо, про тебя речь)
> спиздить из лиспа в мейнстрим ООП с дженериками
> спиздить из лиспа в мейнстрим just-in-time компиляцию
(вы находитесь здесь)
> спиздить из лиспа в мейнстрим тотальную рефлексию среды выполнения
> спиздить из лиспа в мейнстрим концепт образа рантайма
> спиздить из лиспа в мейнстрим код, состоящий исключительно из выражений
> спиздить из лиспа в мейнстрим символьный тип данных
> спиздить из лиспа в мейнстрим гомоиконность
> спиздить из лиспа в мейнстрим макросы
>>533793
Покажи на кукле, в каком месте злые императивщики трогали твой лисп.
Покажи на кукле, в каком месте злые императивщики трогали твой лисп.
>>533913
Где там оверхед, в чем заключается? Тесты есть или что? В Эрланге вообще все неизменяемое, даже идентификаторы (аналог переменной). При том он может держать миллионы соединений, не нужно никакого прогрева как в джаве, виртуальная машина стартует за миллисекунды.
Где там оверхед, в чем заключается? Тесты есть или что? В Эрланге вообще все неизменяемое, даже идентификаторы (аналог переменной). При том он может держать миллионы соединений, не нужно никакого прогрева как в джаве, виртуальная машина стартует за миллисекунды.
>>477327 (OP)
ты просто не писал в крупной проекте с 5 людьми, мутабельность нахуй не нужна
все должно быть имутабельным.
современные компы уже давно готовы к имутабельности
ты просто не писал в крупной проекте с 5 людьми, мутабельность нахуй не нужна
все должно быть имутабельным.
современные компы уже давно готовы к имутабельности
>>534122
Полностью согласен. Даже иммутабельный стрейт жопаскриптерского редакса работает нормально и вполне себе успешно умудряется переезжать на андроид.
Полностью согласен. Даже иммутабельный стрейт жопаскриптерского редакса работает нормально и вполне себе успешно умудряется переезжать на андроид.
>>534122
В нормальных конторах компы вообще не включают, чтобы 100% было иммутабельно.
В нормальных конторах компы вообще не включают, чтобы 100% было иммутабельно.
>>534047
Есть.
И хорошо.
Ну молодец, пусть держит.
Ну пусть стартует.
Динамическая типизация, проверка всего и вся на то является ли переданный параметр интом стрингой или массивом. При каждой самой мелкой операции.
Очистка мусора.
Интепритация байткода, вот это всё. Ну ты что, такой тупенький что сам не знаешь?
>Тесты есть или что?
Есть.
>В Эрланге вообще все неизменяемое
И хорошо.
>При том он может держать миллионы соединений
Ну молодец, пусть держит.
>Виртуальная машина стартует за миллисекунды.
Ну пусть стартует.
>Где там оверхед, в чем заключается?
Динамическая типизация, проверка всего и вся на то является ли переданный параметр интом стрингой или массивом. При каждой самой мелкой операции.
Очистка мусора.
Интепритация байткода, вот это всё. Ну ты что, такой тупенький что сам не знаешь?
>>477329
Ты видимо не в курсе, но switch по енаму в джавке таку юже табличку генерирует.
Алсо многое из этой хуйни вырезаются на этапе сборки приложения.
Ты видимо не в курсе, но switch по енаму в джавке таку юже табличку генерирует.
Алсо многое из этой хуйни вырезаются на этапе сборки приложения.
>>534662
Сразу видно статикодебила, который не знает, зачем придумали динамическую типизацию и в чем ее главные преимущества. Если функция получает аргумент, с интерфейсом которого не может работать, то она просто выкидывает рантайм ошибку. Не хочешь рантайм ошибок? Тестируй код. Никто не чекает тип входных аргументов, если это не юзер дата или не супер-популярная либа, где пытаются помочь ньюфагам информативными ошибками. Но в эти два случая требуют ручных проверок абсолютно в любом языке. Не говоря уже про то, что в эрланге типизация есть и ты можешь хоть обдрочиться, указывая тип на каждый пук и чекая это диалайзером.
>проверка всего и вся на то является ли переданный параметр интом стрингой или массивом
Сразу видно статикодебила, который не знает, зачем придумали динамическую типизацию и в чем ее главные преимущества. Если функция получает аргумент, с интерфейсом которого не может работать, то она просто выкидывает рантайм ошибку. Не хочешь рантайм ошибок? Тестируй код. Никто не чекает тип входных аргументов, если это не юзер дата или не супер-популярная либа, где пытаются помочь ньюфагам информативными ошибками. Но в эти два случая требуют ручных проверок абсолютно в любом языке. Не говоря уже про то, что в эрланге типизация есть и ты можешь хоть обдрочиться, указывая тип на каждый пук и чекая это диалайзером.
>>534662
Выкладывай или переобуешься?
Очередной вскукарек диллетанта. Эрланг в вебе в лидерах по производительности. При этом жрет не много ресурсов. И код на нем очень короткий, потому что почти нет синтаксиса. То есть на нем можно писать быстрее даже чем на Руби или Питоне, а производительность выше в разы.
>Есть.
Выкладывай или переобуешься?
>Динамическая типизация, проверка всего и вся на то является ли переданный параметр интом стрингой или массивом. При каждой самой мелкой операции.
>Очистка мусора.
>Интепритация байткода, вот это всё. Ну ты что, такой тупенький что сам не знаешь?
Очередной вскукарек диллетанта. Эрланг в вебе в лидерах по производительности. При этом жрет не много ресурсов. И код на нем очень короткий, потому что почти нет синтаксиса. То есть на нем можно писать быстрее даже чем на Руби или Питоне, а производительность выше в разы.
>>534698
А откуда твой интерпретатор узнает, совпадают ли типы, байты-то везде одинаково выглядят? Так что не пизди, что там проверок нет, любая динамическая типизация — это как минимум if(type == given_type), а как максимум — switch или match по типам.
А откуда твой интерпретатор узнает, совпадают ли типы, байты-то везде одинаково выглядят? Так что не пизди, что там проверок нет, любая динамическая типизация — это как минимум if(type == given_type), а как максимум — switch или match по типам.
>>534777
Диалайзер - это не интерпретатор, а статический анализатор кода. Узнает оттуда же, откуда узнает и любой компилятор - из объявлений типов.
Разве что в воспаленном сознании студента, который ни на чем толком не писал, кроме си крест крест.
>А откуда твой интерпретатор узнает, совпадают ли типы
Диалайзер - это не интерпретатор, а статический анализатор кода. Узнает оттуда же, откуда узнает и любой компилятор - из объявлений типов.
>любая динамическая типизация — это как минимум if(type == given_type)
Разве что в воспаленном сознании студента, который ни на чем толком не писал, кроме си крест крест.
>>534805
Статический анализатор это прекрасно
Но мы же о РАНТАЙМЕ говорим.
Рантайм как ошибку выкидывает?
Статический анализатор это прекрасно
Но мы же о РАНТАЙМЕ говорим.
Рантайм как ошибку выкидывает?
84 Кб, mp4,320x180, 0:03
>>534726
С PHP сравниваешь?
Сам ищи, дебила кусок )))
Ведеорелейтед
>. Эрланг в вебе в лидерах по производительности.
С PHP сравниваешь?
>Выкладывай или переобуешься?
Сам ищи, дебила кусок )))
> есть на нем можно писать быстрее даже чем на Руби или Питоне
Ведеорелейтед
>>534828
Я думал ты просто долбоеб, который считает, что без ручных проверок на типы нельзя писать на динамике, а ты оказывается еще и шизик-байтоеб, у которого рантайм чек интерфейса на уровне языка ощутимо влияет на производительность. Проснись, 80-е уже прошли.
Я думал ты просто долбоеб, который считает, что без ручных проверок на типы нельзя писать на динамике, а ты оказывается еще и шизик-байтоеб, у которого рантайм чек интерфейса на уровне языка ощутимо влияет на производительность. Проснись, 80-е уже прошли.
>>534856
ГОВОРЮ, ЧТО ПРОВЕРОК НЕТ
@
МНЕ ДОКАЗАЛИ ОБРАТНОЕ
@
"ПРОСНИСЬ, МАНЯ, МЫ НЕ В 80-Х, ГДЕ ИФЫ, ВЫЗЫВАЕМЫЕ НА ЛЮБОЕ ДЕЙСТВИЕ, ЗАМЕДЛЯЛИ РАНТАЙМ; В 2К19 ОНИ БЕСПЛАТНЫЕ, МЫ ЖЕ ПРИПЛЫЛИ В БУДУЩЕЕ, ТУТ КОМПЫ РАБОТАЮТ НА МАГИИ, А НЕ НА БАЙТАХ"
ГОВОРЮ, ЧТО ПРОВЕРОК НЕТ
@
МНЕ ДОКАЗАЛИ ОБРАТНОЕ
@
"ПРОСНИСЬ, МАНЯ, МЫ НЕ В 80-Х, ГДЕ ИФЫ, ВЫЗЫВАЕМЫЕ НА ЛЮБОЕ ДЕЙСТВИЕ, ЗАМЕДЛЯЛИ РАНТАЙМ; В 2К19 ОНИ БЕСПЛАТНЫЕ, МЫ ЖЕ ПРИПЛЫЛИ В БУДУЩЕЕ, ТУТ КОМПЫ РАБОТАЮТ НА МАГИИ, А НЕ НА БАЙТАХ"
>>534872
Считатель битов, иди кушать, у тебя там борщ стынет.
Считатель битов, иди кушать, у тебя там борщ стынет.
>>534872
Может быть ты в жабе int вместо Integer юзаешь, а? И new int[] заместо new ArrayList()?
Может быть ты в жабе int вместо Integer юзаешь, а? И new int[] заместо new ArrayList()?
25,5 Мб, mp4,524x360, 8:00
>>534856
У тебя острый бред.
Я что-то писал про ОЩУЩЕНИЯ?
>у которого рантайм чек интерфейса на уровне языка
>рантайм
>на уровне языка
У тебя острый бред.
>ощутимо влияет на производительность
Я что-то писал про ОЩУЩЕНИЯ?
>>534939
бля, когда еще работал на работах, там был программист один
и он точно так же улыбался, скулы с этой улыбки у него наверное были железные
и еще он, сучка, сильно злой был на окружающий мир
но кодер был охуенный, да
бля, когда еще работал на работах, там был программист один
и он точно так же улыбался, скулы с этой улыбки у него наверное были железные
и еще он, сучка, сильно злой был на окружающий мир
но кодер был охуенный, да
>>534968
Рабочая лошадка так сказать.
Злой от тяжёлой работы очевидно, понимания иммутабельности на уровне проверок интерфейса языка в рантайме, вот этого всего.
Рабочая лошадка так сказать.
Злой от тяжёлой работы очевидно, понимания иммутабельности на уровне проверок интерфейса языка в рантайме, вот этого всего.
>>535172
Я знаю, что сравнение типов — это сравнение констант, лежащих на самой вершине стэка, которое выполняется очень быстро, почти мгновенно. Но ты же утверждал, что там вообще нет проверок, а теперь вдруг оказывается, что есть. Ты уже обосрался, но пытаешься доказать, что маленький жиденький пук — это не обосранные труселя.
Я знаю, что сравнение типов — это сравнение констант, лежащих на самой вершине стэка, которое выполняется очень быстро, почти мгновенно. Но ты же утверждал, что там вообще нет проверок, а теперь вдруг оказывается, что есть. Ты уже обосрался, но пытаешься доказать, что маленький жиденький пук — это не обосранные труселя.
>>535187
Ну-ка быстро показал, где он такое сказал? Он сказал, что 80е прошли и такие проверки на современном железе ничего не значат
Ну-ка быстро показал, где он такое сказал? Он сказал, что 80е прошли и такие проверки на современном железе ничего не значат
>>535197
Еще как значат.
Кроме банального оверхеда по памяти, и доп операций, есть множество нетривиальных нюансов связанных с этим говном.
Например выравнивание памяти, и прочая жуть.
>>535172
Хочешь сказать там даже jmpов нету? А как же тогда рантайм ошибка выбрасывается?
Ты уже с ног до головы в дерьме весь вымазался, и продолжаешь серить.
Еще как значат.
Кроме банального оверхеда по памяти, и доп операций, есть множество нетривиальных нюансов связанных с этим говном.
Например выравнивание памяти, и прочая жуть.
>>535172
>это один xor и один cmp,
Хочешь сказать там даже jmpов нету? А как же тогда рантайм ошибка выбрасывается?
Ты уже с ног до головы в дерьме весь вымазался, и продолжаешь серить.
>>536312
Разумеется, есть, нахуя тогда cmp, если после него нет j*? Флаги туда-сюда подрочить?
Я тебе ещё раз говорю, я не он. Я не утверждаю, что у проверок типов в динамических языках нулевой оверхед, я утверждаю, что он околонулевой. Обосрался здесь только ты со своим незнанием стоимости низкоуровневых операций.
> Хочешь сказать там даже jmpов нету?
Разумеется, есть, нахуя тогда cmp, если после него нет j*? Флаги туда-сюда подрочить?
> Ты уже с ног до головы в дерьме весь вымазался, и продолжаешь серить.
Я тебе ещё раз говорю, я не он. Я не утверждаю, что у проверок типов в динамических языках нулевой оверхед, я утверждаю, что он околонулевой. Обосрался здесь только ты со своим незнанием стоимости низкоуровневых операций.
293 Кб, 742x652>>536397
Ты мне первый раз что-то такое говоришь.
Тогда приводи методику подсчёта.
Например какой оверхед на операцию ++ в процентах от самой операции. По памяти, по времени ЦП, по энергопотреблению.
И например чего-то такого:
(for i=0 i<10 i++){x=i*5}
В чем конкретно?
В чем оно выражается?
>Я тебе ещё раз говорю
Ты мне первый раз что-то такое говоришь.
>я утверждаю, что он околонулевой.
Тогда приводи методику подсчёта.
Например какой оверхед на операцию ++ в процентах от самой операции. По памяти, по времени ЦП, по энергопотреблению.
И например чего-то такого:
(for i=0 i<10 i++){x=i*5}
>Обосрался здесь только ты
В чем конкретно?
>со своим незнанием стоимости низкоуровневых операций.
В чем оно выражается?
>>536857
>>536263
Оверхед от операции на операцию? Проснись, ты обосрался.
В следующем:
Уж не говоря об
Я Erlang не знаю, я за Common Lisp топлю, и в нём при (declaim (optimize (speed 3))) компилятор агрессивно выводит типы и выкидывает все проверки типов, какие только может, а когда не может, например, когда нужно передать значение в generic библиотечную функцию (и, как следствие, для этого значения нужен боксинг) выдаёт warning, что, мол, doing float to pointer coercion. Друг, я тебе искренне советую расширять кругозор и не верить стереотипам, а то так и помрёшь, думая, что динамика = медленно.
> Ты мне первый раз что-то такое говоришь.
>>536263
> Например какой оверхед на операцию ++ в процентах от самой операции
Оверхед от операции на операцию? Проснись, ты обосрался.
>>Обосрался здесь только ты
>В чем конкретно?
>>со своим незнанием стоимости низкоуровневых операций.
>В чем оно выражается?
В следующем:
> Динамическая типизация, проверка всего и вся на то является ли переданный параметр интом стрингой или массивом.
Уж не говоря об
> При каждой самой мелкой операции.
Я Erlang не знаю, я за Common Lisp топлю, и в нём при (declaim (optimize (speed 3))) компилятор агрессивно выводит типы и выкидывает все проверки типов, какие только может, а когда не может, например, когда нужно передать значение в generic библиотечную функцию (и, как следствие, для этого значения нужен боксинг) выдаёт warning, что, мол, doing float to pointer coercion. Друг, я тебе искренне советую расширять кругозор и не верить стереотипам, а то так и помрёшь, думая, что динамика = медленно.
>>537979
Ты путаешь динамическую типизацию, и автомтаический вывод типов.
Это понятия из разных логических категорий.
Одно частично может решать проблему другого, но не устранять её принципиально.
И не решает проблемы оверхеда по памяти.
Пахнет? Так ты свои штаны проверь.
В чем конкретно проблема?
Есть операция а сишечке, и есть операия в жаве, проверяем простое выражение x++.
Средствами самого языка это может быть и не очень просто сделать допустим, заменим на вычисление ряда фибоначи, допустим.
Для тебя это что-то необычное, и за гранью понимания?
Вот этом коммон лисп например, создаём список из 10 млн структур (обосеря знач-итн знч-флот знач-байт), и то же делаем в сишечке, а потом смотрим сколько список в памяти занял места?
>а то так и помрёшь, думая, что динамика = медленно.
>компилятор агрессивно выводит типы и выкидывает все проверки типов, какие только может
Ты путаешь динамическую типизацию, и автомтаический вывод типов.
Это понятия из разных логических категорий.
Одно частично может решать проблему другого, но не устранять её принципиально.
И не решает проблемы оверхеда по памяти.
>Оверхед от операции на операцию? Проснись, ты обосрался.
Пахнет? Так ты свои штаны проверь.
В чем конкретно проблема?
Есть операция а сишечке, и есть операия в жаве, проверяем простое выражение x++.
Средствами самого языка это может быть и не очень просто сделать допустим, заменим на вычисление ряда фибоначи, допустим.
Для тебя это что-то необычное, и за гранью понимания?
Вот этом коммон лисп например, создаём список из 10 млн структур (обосеря знач-итн знч-флот знач-байт), и то же делаем в сишечке, а потом смотрим сколько список в памяти занял места?
>>477327 (OP)
Иммутабельность это возможность многопоточной коммуникации без значительного оверхеда и без сериализаций. Просто в котлине, судя по всему, пытаются сделать верблюда из камаза. Что-то вроде монад на питоне. Ненужное ненужно.
Иммутабельность это возможность многопоточной коммуникации без значительного оверхеда и без сериализаций. Просто в котлине, судя по всему, пытаются сделать верблюда из камаза. Что-то вроде монад на питоне. Ненужное ненужно.
>>538488
Я их не путаю, я тебе говорю, что хороший вывод типов частично устраняет оверхед от проверок типов в рантайме.
То ты кукарекал про жуткие тормоза от проверок типов, а теперь трёшь за потребление памяти. Найс виляния жопой, но окей, мне самому интересно стало, смотри пикрелейтед. Итог немножко предсказуем: 115M у сишного варианта против (190-112)=78M у CL-ного.
> операия
Друг, да не торопись ты так, всё хорошо будет.
> Ты путаешь динамическую типизацию, и автомтаический вывод типов.
> Это понятия из разных логических категорий.
> Одно частично может решать проблему другого, но не устранять её принципиально.
Я их не путаю, я тебе говорю, что хороший вывод типов частично устраняет оверхед от проверок типов в рантайме.
> Вот этом коммон лисп например, создаём список из 10 млн структур (обосеря знач-итн знч-флот знач-байт), и то же делаем в сишечке, а потом смотрим сколько список в памяти занял места?
То ты кукарекал про жуткие тормоза от проверок типов, а теперь трёшь за потребление памяти. Найс виляния жопой, но окей, мне самому интересно стало, смотри пикрелейтед. Итог немножко предсказуем: 115M у сишного варианта против (190-112)=78M у CL-ного.
> операия
Друг, да не торопись ты так, всё хорошо будет.
>>538898
Ты использовал статическую типизацию в лиспе. Давай без объявления типов. Мы о динамической типизации говорим. И не массив, а, СПИСОК. И добавь код проверяющий тип элементов.
Ты использовал статическую типизацию в лиспе. Давай без объявления типов. Мы о динамической типизации говорим. И не массив, а, СПИСОК. И добавь код проверяющий тип элементов.
>>538922
В лиспе динамическая типизация, засеря.
Динамическая типизация != отсутствие деклараций типов. Динамическая типизация - это когда тип является артибутом значения, а не атрибутом переменной. Друг, у тебя и правда с кругозором всё худо.
Зачем его проверять, если и я, и компилятор точно знаем тип?
> Ты использовал статическую типизацию в лиспе.
В лиспе динамическая типизация, засеря.
> Давай без объявления типов. Мы о динамической типизации говорим.
Динамическая типизация != отсутствие деклараций типов. Динамическая типизация - это когда тип является артибутом значения, а не атрибутом переменной. Друг, у тебя и правда с кругозором всё худо.
> И добавь код проверяющий тип элементов.
Зачем его проверять, если и я, и компилятор точно знаем тип?
>>538898
1358M у цлного, нет?
Или что ты хочешь сказать, в твоём волшебном лиспе байт занимает меньше 8ми бит?
>Итог немножко предсказуем: 115M у сишного варианта против (190-112)=78M у CL-ного.
1358M у цлного, нет?
Или что ты хочешь сказать, в твоём волшебном лиспе байт занимает меньше 8ми бит?
>>538924
Где тогда динамическая типизация? Покажи её.
>Зачем его проверять, если и я, и компилятор точно знаем тип?
Где тогда динамическая типизация? Покажи её.
>>538926
Не ебись в глаза, это колонка VIRT. Нас же реальное потребление памяти интересует, поэтому смотрим в следующую колонку, RSS.
>>538929
Друг, для тебя ничего не жалко: https://ru.wikipedia.org/wiki/Динамическая_типизация
Не ебись в глаза, это колонка VIRT. Нас же реальное потребление памяти интересует, поэтому смотрим в следующую колонку, RSS.
>>538929
> Где тогда динамическая типизация? Покажи её.
Друг, для тебя ничего не жалко: https://ru.wikipedia.org/wiki/Динамическая_типизация
>>538898
сишная структура выравнивается по умолчанию, итого будет занимать 12 байт, поэтому и 117 мбайт по итогу массив занимает
что странно, дак это то, что, по видимому, эта реализация lisp не делает такого выравнивания, упаковывая все плотно, за счет этого и достигается экономия по памяти
но ведь это сильно снижает производительность
сишная структура выравнивается по умолчанию, итого будет занимать 12 байт, поэтому и 117 мбайт по итогу массив занимает
что странно, дак это то, что, по видимому, эта реализация lisp не делает такого выравнивания, упаковывая все плотно, за счет этого и достигается экономия по памяти
но ведь это сильно снижает производительность
>>537979
это, наверно, все же относится к особенностям реализации конкретного компилятора, но не самого стандарта
или все же в самом стандарте прописываются требования к таким оптимизациям?
>я за Common Lisp топлю, и в нём при (declaim (optimize (speed 3))) компилятор агрессивно выводит типы и выкидывает все проверки типов, какие только может, а когда не может, например, когда нужно передать значение в generic библиотечную функцию (и, как следствие, для этого значения нужен боксинг) выдаёт warning, что, мол, doing float to pointer coercion
это, наверно, все же относится к особенностям реализации конкретного компилятора, но не самого стандарта
или все же в самом стандарте прописываются требования к таким оптимизациям?
119 Кб, 640x960>>538931
Уныло троллишь. В программе твоей она где?
Компилятор у тебя использует декларацию типов и генерирует статически типизированный код.
У нас речь шла о динамической типизации.
Если ты не можешь запросить тип элемента, или записать в свой массив элемент другого типа, в чем блядь динамическая типизация в твоём коде заключается, где она?
>Друг, для тебя ничего не жалко: https://ru.wikipedia.org/wiki/Динамическая_типизация
Уныло троллишь. В программе твоей она где?
Компилятор у тебя использует декларацию типов и генерирует статически типизированный код.
У нас речь шла о динамической типизации.
Если ты не можешь запросить тип элемента, или записать в свой массив элемент другого типа, в чем блядь динамическая типизация в твоём коде заключается, где она?
>>538976
Да нет, нельзя просто ёбнуть такую хуету, это проёб века будет. Скорее лисп из контекста понимает, что можно сделать три массива, каждый под свой тип, вместо одного под структуру, а всю структуру доставать по одинаковому индексу.
Да нет, нельзя просто ёбнуть такую хуету, это проёб века будет. Скорее лисп из контекста понимает, что можно сделать три массива, каждый под свой тип, вместо одного под структуру, а всю структуру доставать по одинаковому индексу.
>>538972
Двач образовательный. https://ru.wikipedia.org/wiki/Виртуальная_память
>>538998
Нет, переупаковки aos в soa там не происходит, этот >>538976 прав, там просто плотная упаковка. И да, в некоторых юз-кейсах при записи этого поля действительно будет некоторая просадка по производительности, но если тебя интересуют такие тонкие машиноспецифичные оптимизации, то ничто не мешает определить структуру и функции для работы с ней на сишке и дёргать их в лиспе через CFFI.
>>538983
Вообще да, в стандарте не сказано, что информацию о типах нужно использовать для оптимизации, просто в SBCL исторически хороший вывод типов, ещё с тех времён, когда он был CMU CL. Может, в каких-нибудь коммерческих компиляторах типа Franz так же, не знаю, не пользовался.
Двач образовательный. https://ru.wikipedia.org/wiki/Виртуальная_память
>>538998
Нет, переупаковки aos в soa там не происходит, этот >>538976 прав, там просто плотная упаковка. И да, в некоторых юз-кейсах при записи этого поля действительно будет некоторая просадка по производительности, но если тебя интересуют такие тонкие машиноспецифичные оптимизации, то ничто не мешает определить структуру и функции для работы с ней на сишке и дёргать их в лиспе через CFFI.
>>538983
Вообще да, в стандарте не сказано, что информацию о типах нужно использовать для оптимизации, просто в SBCL исторически хороший вывод типов, ещё с тех времён, когда он был CMU CL. Может, в каких-нибудь коммерческих компиляторах типа Franz так же, не знаю, не пользовался.
>>539012
не "некоторая" а значительная
по крайней мере в языке си работа с невыровненными данными может просаживать производительность на некоторых платформах (в том числе и x86 в первую очередь) аж в несколько раз
>юз-кейсах при записи этого поля действительно будет некоторая просадка по производительности
не "некоторая" а значительная
по крайней мере в языке си работа с невыровненными данными может просаживать производительность на некоторых платформах (в том числе и x86 в первую очередь) аж в несколько раз
>>539012
хм, ожидается что таки компиляторы лиспа таки должны по умолчанию делать выравнивание структур и массивов, иначе это было бы очень странно
>но если тебя интересуют такие тонкие машиноспецифичные оптимизации, то ничто не мешает определить структуру и функции для работы с ней на сишке и дёргать их в лиспе через CFFI.
хм, ожидается что таки компиляторы лиспа таки должны по умолчанию делать выравнивание структур и массивов, иначе это было бы очень странно
>>539049
Ничего другого и нет. Современные процы оптимизированы под выполнение Си кода. По крайней мере риски всякие и х86(который тот-же риск но в соусе из сладкого хлебушка).
>по крайней мере в языке си
Ничего другого и нет. Современные процы оптимизированы под выполнение Си кода. По крайней мере риски всякие и х86(который тот-же риск но в соусе из сладкого хлебушка).
>>538998
кстати, в си этот прием тоже активно используется (часто в библиотеках для интенсивных численных вычислений, к примеру), подход этот унаследован с фортрана
то есть не берут структуру с тремя полями (для примера), а делают три массива
и работают потом не с указателями, а со смещениями в массиве
>Да нет, нельзя просто ёбнуть такую хуету, это проёб века будет. Скорее лисп из контекста понимает, что можно сделать три массива, каждый под свой тип, вместо одного под структуру, а всю структуру доставать по одинаковому индексу.
кстати, в си этот прием тоже активно используется (часто в библиотеках для интенсивных численных вычислений, к примеру), подход этот унаследован с фортрана
то есть не берут структуру с тремя полями (для примера), а делают три массива
и работают потом не с указателями, а со смещениями в массиве
>>539060
хм, скорее си-компиляторы способны генерировать эффективный машинный код..
что не отменяет того что (в контекте данного треда) и те же компиляторы lisp могут генерировать не менее эффективный машинный код (будьто "на лету", либо в виде объектного кода, "запакованного" в исполняемый файл)
>Современные процы оптимизированы под выполнение Си кода.
хм, скорее си-компиляторы способны генерировать эффективный машинный код..
что не отменяет того что (в контекте данного треда) и те же компиляторы lisp могут генерировать не менее эффективный машинный код (будьто "на лету", либо в виде объектного кода, "запакованного" в исполняемый файл)
>>477327 (OP)
А у меня вопрос не по теме ОП-поста, но связанный с его стилистикой и настроением.
Много ли альт-райтов, NRx или правых акселерационистов в IT-сфере? Молдбага и Ника Ланда кто-нибудь читает?
А у меня вопрос не по теме ОП-поста, но связанный с его стилистикой и настроением.
Много ли альт-райтов, NRx или правых акселерационистов в IT-сфере? Молдбага и Ника Ланда кто-нибудь читает?
>>539075
Если в лиспе дефолтным считается создание структуры без выравния (или хотя бы автоматически оптимизированного выравния, как в расте), то компиляторы лиспа могут только хуйца соснуть по сравнению с языками общего назначения.
Если в лиспе дефолтным считается создание структуры без выравния (или хотя бы автоматически оптимизированного выравния, как в расте), то компиляторы лиспа могут только хуйца соснуть по сравнению с языками общего назначения.
Шел 2019-ый год
Еще были дебилы верящие, что память работает в Random Access
Тред не читал, но осуждаю
Еще были дебилы верящие, что память работает в Random Access
Тред не читал, но осуждаю
>>539085
Я подробно вопрос выравнивания в CL-ных структурах не изучал, но если тебе охота побайтоёбствовать, всегда можно в структуре определить у поля тип, выровненный по длине на нужное количество вместо актуального типа, например, сделать вместо usnigned-byte (1 байт) fixnum (машинное слово, на хуй86-64 - 8 байт) и пользоваться им, помня, что у тебя там на самом деле 1 байт.
Я подробно вопрос выравнивания в CL-ных структурах не изучал, но если тебе охота побайтоёбствовать, всегда можно в структуре определить у поля тип, выровненный по длине на нужное количество вместо актуального типа, например, сделать вместо usnigned-byte (1 байт) fixnum (машинное слово, на хуй86-64 - 8 байт) и пользоваться им, помня, что у тебя там на самом деле 1 байт.
>>539076
ай-ти деполитизирована тем что в нем (по крайней мере для программистов) осуществляется жесткий отбор по способностям к программированию в первую очередь, к инженерному или математическому бэкграунду (которые осталяют мало времени на формирование каких то политических предпочтений, не до этого)
не вина сообщества в том что в нем оказываются в основном белые (с добавкой желтых азиатов) мужики, можно сказать что это естественный отбор
но следует сказать, что в последнее время, ай-ти сообществу навязывается со стороны некие странные нормы толерантности (типа терпеть пидоров, коих в ай-тишной тусовке всегда было 1-1,5% в отличие от стандартных 7%) типа что должны быть бабы-кодеры (если справляешься - велком, но никаких не должно же поблажек, а сейчас не так), типа черные тоже должны быть в айти (то же самое что и с бабами), потом если ты типа кодер, то ты значит продвинутый, а значит либерал (хотя кодеры всегда были консервативны)
ай-ти деполитизирована тем что в нем (по крайней мере для программистов) осуществляется жесткий отбор по способностям к программированию в первую очередь, к инженерному или математическому бэкграунду (которые осталяют мало времени на формирование каких то политических предпочтений, не до этого)
не вина сообщества в том что в нем оказываются в основном белые (с добавкой желтых азиатов) мужики, можно сказать что это естественный отбор
но следует сказать, что в последнее время, ай-ти сообществу навязывается со стороны некие странные нормы толерантности (типа терпеть пидоров, коих в ай-тишной тусовке всегда было 1-1,5% в отличие от стандартных 7%) типа что должны быть бабы-кодеры (если справляешься - велком, но никаких не должно же поблажек, а сейчас не так), типа черные тоже должны быть в айти (то же самое что и с бабами), потом если ты типа кодер, то ты значит продвинутый, а значит либерал (хотя кодеры всегда были консервативны)
>>539106
речь о том, делает ли выравнивание структур компилятор той реализации лиспа, которую ты используешь
в си, к примеру, по умолчанию делается выравнивание
причем посредством нехитрого переупорядочивания и, опционально, добавления паддинг-поля в конец структуры, можно добится более плотной упаковки структуры, но которая будет продолжать быть выровненной
с другой стороны, выравнивание структуры (посредством директивы компилятору) можно отключить, и тогда поля ее будут идти в памяти одна за другой - это нужно для прямого чтения (накладыванием структуры на область памяти) различных бинарных форматов или протоколов, где данные идут один за другим
но, скорей всего, компилятор лиспа делает оптимизацию такую - а именно раскидывает эту структуру по массивам, как вот этот человек сказал >>538998
речь о том, делает ли выравнивание структур компилятор той реализации лиспа, которую ты используешь
в си, к примеру, по умолчанию делается выравнивание
причем посредством нехитрого переупорядочивания и, опционально, добавления паддинг-поля в конец структуры, можно добится более плотной упаковки структуры, но которая будет продолжать быть выровненной
с другой стороны, выравнивание структуры (посредством директивы компилятору) можно отключить, и тогда поля ее будут идти в памяти одна за другой - это нужно для прямого чтения (накладыванием структуры на область памяти) различных бинарных форматов или протоколов, где данные идут один за другим
но, скорей всего, компилятор лиспа делает оптимизацию такую - а именно раскидывает эту структуру по массивам, как вот этот человек сказал >>538998
>>539099
Кстати, а почему нет? Меня немного удивляет то как реализованные эти ДДР и контроллеры памяти.
В смысле что, вместо одной 128 битной шины можно было бы сделать 4 32 битных или 16 однобайтных. В чем сакральный смысл 2хканальной памяти мне непонятно?
Кстати, а почему нет? Меня немного удивляет то как реализованные эти ДДР и контроллеры памяти.
В смысле что, вместо одной 128 битной шины можно было бы сделать 4 32 битных или 16 однобайтных. В чем сакральный смысл 2хканальной памяти мне непонятно?
>>539118
Ебать ты выпал из жизни, дедушка. Просто посмотри вот на этот безобидный твит, а потом почитай комменты к нему. Такого количества рвущихся левацких снежинок я не видел даже в твиттере трампа.
https://twitter.com/unclebobmartin/status/1200074140637642754
>ай-ти деполитизирована
Ебать ты выпал из жизни, дедушка. Просто посмотри вот на этот безобидный твит, а потом почитай комменты к нему. Такого количества рвущихся левацких снежинок я не видел даже в твиттере трампа.
https://twitter.com/unclebobmartin/status/1200074140637642754
>>539140
Random Access - это иллюзия, бро
http://www.1024cores.net/home/in-russian/ram---ne-ram-ili-cache-conscious-data-structures
Random Access - это иллюзия, бро
http://www.1024cores.net/home/in-russian/ram---ne-ram-ili-cache-conscious-data-structures
>>539129
Кстати да, ты прав. Когда не лень будет, посмотрю чо там другие CCL делают.
Не, точно нет по крайней мере в SBCL. Я дизассемблерные выхлопы смотрел у функций, работающих с массивами структур, там совершенно честный array-of-structs, чтобы сделать soa, нужно это делать явно - я это делаю через хитровыебанные макросы, из-за которых описание выглядит почти как обычная структура, но является soa.
> речь о том, делает ли выравнивание структур компилятор той реализации лиспа, которую ты используешь
Кстати да, ты прав. Когда не лень будет, посмотрю чо там другие CCL делают.
> но, скорей всего, компилятор лиспа делает оптимизацию такую - а именно раскидывает эту структуру по массивам
Не, точно нет по крайней мере в SBCL. Я дизассемблерные выхлопы смотрел у функций, работающих с массивами структур, там совершенно честный array-of-structs, чтобы сделать soa, нужно это делать явно - я это делаю через хитровыебанные макросы, из-за которых описание выглядит почти как обычная структура, но является soa.
>>539178
Мде мда. Пиздос какой-то.
Особенно
Охуеть теперь.
Пиздец просто пиздец, еще и об этом говне теперь волноваться. Нет, ненужно, унеси свою статью. Забуду это пока не поздно.
>Random Access - это иллюзия, бро
>
>http://www.1024cores.net/home/in-russian/ram---ne-ram-ili-cache-conscious-data-structures
Мде мда. Пиздос какой-то.
Особенно
>Вкратце рецепт такой — по массивам надо проходить последовательно;
Охуеть теперь.
Пиздец просто пиздец, еще и об этом говне теперь волноваться. Нет, ненужно, унеси свою статью. Забуду это пока не поздно.
>>539075
Нет, х86 специально был разработан для выполнения Си кода.
Как и РИСК архитектура.
Маркетологи интела всем уши просто проссали в своё время о том что у них процы "универсальные", но это совсем ваще не так.
Насколько я помню историю, их IEE вынудила выпустить С проц.
Язык Си, требовал в своей время, и ничего не поменялось, очень специфичных архитектурных решений, конкретного набора конкретных регистров, модель адресации памяти при которой программе видно всю память, и прочее.
Альтернативой в свое время был ЦП интела же заточенный под паскаль, с разными крутыми фишками безопасности. Интел стёрла о нем почти все упоминания в итоге.
>хм, скорее си-компиляторы способны генерировать эффективный машинный код..
Нет, х86 специально был разработан для выполнения Си кода.
Как и РИСК архитектура.
Маркетологи интела всем уши просто проссали в своё время о том что у них процы "универсальные", но это совсем ваще не так.
Насколько я помню историю, их IEE вынудила выпустить С проц.
Язык Си, требовал в своей время, и ничего не поменялось, очень специфичных архитектурных решений, конкретного набора конкретных регистров, модель адресации памяти при которой программе видно всю память, и прочее.
Альтернативой в свое время был ЦП интела же заточенный под паскаль, с разными крутыми фишками безопасности. Интел стёрла о нем почти все упоминания в итоге.
>>539118
Ну я не про политику внутри IT, а про скорее про политические взгляды айтишников, которые могут и не отражаться в их технической деятельности.
Ну я не про политику внутри IT, а про скорее про политические взгляды айтишников, которые могут и не отражаться в их технической деятельности.
>>539418
это где ты вычитал такое? что x86 подгоняли под язык си?
это где ты вычитал такое? что x86 подгоняли под язык си?
>>539642
Нахуй иди.
Нахуй иди.
Тред утонул или удален.
Это копия, сохраненная 16 января 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 16 января 2020 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.