LukinB Nov 27 2016 at 17:16

7 самых неприятных проблем в программировании

8 min

53K

Information Security*Cryptography*Programming*

Translation

+24

Comments 91

FirsofMaxim Nov 27 2016 at 17:34

В Swift для замыканий ввели типы аргументов — weak/unowned, внутри при доступе к вызываемому контексту требуется написать self, тем самым среда как бы говорит — «ага! self написал — утечку осознал!» (здесь я имею ввиду что если в замыкании используется self без типа аргумента weak/unowned — привет утечка)

storoj Nov 27 2016 at 18:53

ничего и не утечка

FirsofMaxim Nov 27 2016 at 19:05

а вот и утечка если:
1) замыкание
2) внутри self
3) self не указан как weak/unowned
Немного хелпа тут

self связывается как strong ссылка если не указано иное.

storoj Nov 27 2016 at 19:22

dispatch_async({ print(self) }) – тоже утечка?

FirsofMaxim Nov 28 2016 at 03:35

Если ссылка на очередь нигде не сохраняется, то конечно утечки нет, но все меняется если пробовать вызвать код в main очереди, например (Swift3):

Запустите в Playground этот код:

class A {
    init(){
        print("A init")
    }
    
    deinit {
        print("A deinit")
    }
    
    public func fooBar(){
        print("A.fooBar")
    }
    
    public func fooBarAsync(){
        print("A.fooBarAsync")
        DispatchQueue.main.async {
            self.fooBar()
        }
        
    }
}


func testCase(){
    let a = A()
    a.fooBar()
    a.fooBarAsync()
}


testCase()

##########
A init
A.fooBar
A.fooBarAsync
Ухты! Где deinit растак его?!

Делаем так:

public func fooBarAsync(){
        print("A.fooBarAsync")
        DispatchQueue.main.async { [ unowned self] in 
            self.fooBar()
        }
        
    }

##########
A init
A.fooBar
A.fooBarAsync
A deinit
Оуе детка! Я тебя вижу :)

storoj Nov 28 2016 at 12:31

Рекомендую добавить это в начало:

import PlaygroundSupport

PlaygroundPage.current.needsIndefiniteExecution = true

А в последнем примере по коду разве не должен был быть ещё один A.foobar после deinit? Может быть его нет потому что всё благополучно упало?

FirsofMaxim Nov 28 2016 at 16:30

Все работает без падений, попробуйте.

VovanZ Nov 27 2016 at 17:45

Не нашёл в списке инвалидации кэша и придумывания названий для вещей. Разочарован.

Envek Nov 27 2016 at 18:49

А ещё Unicode и работы с временем. Вот где драконы роятся!

neit_kas Nov 27 2016 at 21:07

Unicode обобщил бы на кодировки в целом.

DistortNeo Nov 28 2016 at 00:26

Кодировки сами по себе — это ерунда по сравнению с обработкой юникода со всеми экзотическии случаями. Например, «й» может представляться как одним кодпоинтом, так и комбинацией символов «и» и кратки.

neit_kas Nov 28 2016 at 03:41

Ещё UTF8 радует разной длинной символов. Но среди однобайтных тоже треш есть: встречались редакторы, которые при опознании путали Win1251 с какими-то другими (уже не помню с кем).

grossws Nov 29 2016 at 13:00

Проблема, что однобайтные кодировки часто приходится угадывать, если кодировка явно не указана в метаданных, а это процесс вероятностный. На коротких текстах, например, cp1251 может быть опознан как mac-cyrillic.

neit_kas Dec 1 2016 at 20:38

У меня notepad-qq опознаёт её как iso8859-1. При этом notepad++ опознавал по-другому: какая-то очень похожая на 1251, отличия были буквально в паре букв. Точно помню 'й' и вроде 'я' страдали.

grossws Dec 1 2016 at 21:34

Как раз в mac cyrillic есть эта проблема. Например 0xff там ¤, а не я, вместо Э -> Ё, Ю -> ё, Я -> я и т. п. Ну и остальные заглавные должны страдать.

vikarti Nov 28 2016 at 12:29

Причем даже крупные компании — не всегда корректно это обрабатывают.
Пример: скопируем из ЛК мегафона какую то сумму со знаком рубля (новым) в буфер обмена а потом попробуем ее вставить в создаваемый там же тикет поддержки. Она вставится. Только вот при попытке отправить будет сообщение что ошибка (без указания деталей). если заменить символ на просто Р — все отправляется.

DistortNeo Nov 28 2016 at 12:42

Мне встречался случай, когда я не мог отправить сообщение (не помню куда), содержащее в теле слово «select» — вот такая доморощенная защита от sql injection.

0x9d8e Nov 28 2016 at 15:10

Вконтакте в 2008-2009 такое творил. Точнее просто вырезал всё, что ему казалось похожим на SQL.

neit_kas Nov 27 2016 at 21:11

Ещё добавил бы:
3 угла треугольника: скорость выполнения, затрачиваемая память и поддерживаемость кода (поиск золотой середины).
Архитектура ПО: когда заранее не в курсе, куда занесёт и, следовательно, какую архитектуру построить.

ababo Nov 28 2016 at 08:12

Вот с именованием иногда просто беда, как бы это глупо не звучало. Порой так мучительно придумывать имя как для отдельных сущностей, так и для проекта в целом.

Pakos Dec 1 2016 at 07:12

Я придумал имя для проекта, его не поддержали… и дали следующему проекту (оказалось что ему оно подходит даже больше). Бывает и такое.

Labunsky Nov 27 2016 at 18:49

>Если бы вы нашли способ подслушивать каждый разговор и проникать в любой банк, вы бы сразу сообщили об этом всему миру, что помочь заделать дыры?

Один человек в масштабах планеты особой угрозы не несет. А надежность хранения тайны группой лиц стремится к нулю при увеличении размера группы, так что не стоит пока беспокоиться о ненадежности шифрования. Во всяком случае не больше, чем о рептилоидах

a1111exe Nov 27 2016 at 21:22

Один человек в масштабах планеты особой угрозы не несет.

Ой ли? А если реинкарнация злодея Гитлера и гения Канта в одном лице, усугублённая современным высшим образованием и отсутствием внятных моральных ориентиров?

poxvuibr Nov 28 2016 at 09:01

А если реинкарнация злодея Гитлера и гения Канта в одном лице

Хотел написать какую-нибудь ядовитую шутку про то, что ничего гениального Канта не сделал, но передумал. Лучше спрошу вопрос.

Смог бы злодей типа Гитлера сделать что-нибудь, если б он не пользовался поддержкой такого количества окружающих его людей. И, смог бы он добиться этой поддержки, если бы они не были соответствующим образом подготовлены предшествующими обстоятельствами?

И что может сделать гений, если он даже толком коллегу подсидеть зачастую не способен?

UFO landed and left these words here

poxvuibr Nov 28 2016 at 14:42

Для того, чтобы взорвать ядерный реактор надо получить туда доступ и иметь возможность обойти все уровни защит от того, кто может обидеться на весь мир. Эта задача гораздо ближе к "подсидеть коллегу", чем к тому, чем занимается среднестатистический гений.

Alexeyslav Nov 28 2016 at 14:45

А как насчет внести небольшие изменения в систему управления чтобы накопившаяся ошибка через месяц-другой привела к аварии?

poxvuibr Nov 28 2016 at 15:48

К системе управления надо получить доступ, потом надо молиться, что никто из контролёров этих ошибок не заметит.

UFO landed and left these words here

poxvuibr Nov 28 2016 at 15:48

А потом вы перевели разговор на ядерный реактор :)

a1111exe Dec 1 2016 at 19:29

Было написано «один человек в масштабах планеты особой угрозы не несёт». Мой тезис: технически возможно одному человеку угрожать благополучию всего мира. И я привёл пример, в котором человек наделён властью (Гитлер был наделён властью), умён и аморален. Такое невозможно? Серьёзно?

P.S. Позвольте спросить, чем Вам не угодил Кант?

Nordicx86 Nov 28 2016 at 07:26

как вам сказать «коды» пуска ядерных ракет — в курсе ТОЧНО группа лиц,, но они хранятся вполне и вполне надежно.
тут ТОЖЕ САМОЕ — реально методы взлома существуют(«непознаное незнаю»), но их вам ни кто не озвучит пока вы сами не попадете в условия когда сохранение тайны станет вашим непосредственным, я бы даже добавил ЖИЗНЕННО важным интересом… ДУМАЙТЕ…

Alexeyslav Nov 28 2016 at 08:21

Надёжно они хранятся потому что сменяются чаще чем происходит вероятная утечка. Кроме того, с недавних пор некоторые пусковые коды известны всем поскольку военные признали проблему что при необходимости осуществить реальный пуск в сжатые сроки ввести сложный код с первой попытки нереально, поэтому пусковые коды непосредственно на местах играют роль щеколды на деревянной двери. Поэтому однократная утечка кодов не страшна, есть и другие эшелоны защиты от несанкционированного запуска.

vikarti Nov 28 2016 at 12:44

А один человеке который патриот своей страны и сообщил метод соответствующей разведке, веря что те не использует его во вред стране? Зависит ли ответ от того — какая именно страна у сообщившего и какая страна и политические взгляды у того, кто оценивает ущерб

А если никому не сообщил но выложил в багтрекер мозиллы сертификат для mozilla.org, подписанный SubCA с CN='Klingon Empire', в свою очередь подписанный VeriSign + тоже самое но в качестве RootCA — использован допустим CNNIC и с комментарием что никто VeriSign/CNNIC не взламывал, просто современные протоколы ЭЦП — ненадежны… без указания деталей. Это вообще — угроза или предупреждение об уязвимости?

Vjatcheslav3345 Nov 27 2016 at 19:14

В любом случае доступ открыт, но только через «червоточину» в континууме данные-время — странном механизме сдвига во времени, который, должно быть, навеян научно-фантастическими сериалами.

Кажется я теперь знаю, как понятно объяснять своей девушке проблему замыканий: "Знаешь, начнём с того, что это чем то похоже на наиновейшие теории пространства-времени, которые мы с таким удовольствием вчера обсуждали в гостях у Маньки-соседки. Давай рассмотрим [беру её за руку] такую простенькую вещь как обыкновенная «червоточина» в пространстве-времени..."

Zonzen Nov 27 2016 at 19:40

Статью следует назвать — «семь самых частых ошибок некомпетентных программистов».

third112 Nov 27 2016 at 19:50

Верно. Не понятна адресация. М.б. это попытка популярной статьи для начальников, которые сами программировать не умеют? :)

third112 Nov 28 2016 at 09:27

Ура! Статья нашла своего читателя: прибежали некомпетентные минусаторы, которым нечего возразить словами, зато минусы раздали :)) -«Аргументация» на уровне статьи!

aon24 Nov 28 2016 at 10:07

Согласен с Вами, но не судите автора строго: он наберется опыта и поймет, что главный дракон любого программиста (любого человека) — это некомпетентность, и ее не вылечишь советами типа «нельзя создавать путаницы».

third112 Nov 28 2016 at 10:36

Ok. Я бы еще добавил, что некомпетентность зачастую вызывает завышенную самооценку, а это совсем плохо, когда человек не считает нужным что-то узнать и чему-то научиться, просто посоветоваться. Такие горе-программисты могут быть очень разрушительны для проекта, особенно, если их несколько объединились, и если их начальник сам не сильно компетентный.

aon24 Nov 28 2016 at 11:19

Не согласен с Вами. Некомпетентность не вызывает завышенную самооценку. На мой взгляд завышенная самооценка формируется при работе в слабом коллективе. Короля создает свита.

third112 Nov 28 2016 at 11:50

Вспомните, нпр., «болезнь» многих первокурсников: студент чуть успел проучиться, и ему начинает казаться, что он почти специалист… Посмотрите на разных форумах в сетке — самые нетерпимые, самые убежденные в своей правоте форумчане — это недоучившиеся студенты. Причем, чем ниже курс студента — тем он больше убежден в своей правоте.

aon24 Nov 28 2016 at 13:09

Я не случайно написал «наберется опыта и поймет...».
Я сам по юности лет, получив в Питере хорошее образование и поработав пару лет программистом, был послан в Уфу в качестве гуру поучать местных спецов (интернет только зарождался). Через пару часов общения я понял, что мои башкирские ровесники разбираются в проблеме и в программировании лучше меня :)
Пришлось самооценку скорректировать.

Alexey_Sarychev Nov 27 2016 at 21:22

Можно и сильнее округлить. Давайте уж сразу — «семь самых частых ошибок некомпетентных людей».
Если боксер побьет плавца, значит пловец плохой спортсмен. Точка.

Незнание одной области не делает программиста некомпетентным.

Учитывая самодурство некоторых руководителей, я могу запросто представить ситуацию, когда программисту дадут многопоточную задачу, даже если он никогда с этим не сталкивался.

Zonzen Nov 28 2016 at 05:57

Незнание одной области не делает программиста некомпетентным.

По вашей логике, незнание, например, доктором биологических наук ядерной физики, не делает его некомпетентным в области этой самой ядерной физики.

Alexey_Sarychev Nov 28 2016 at 06:09

Я как раз написал автору комментария тоже самое — обобщение не верно.

Если программист не умеет работать с многопоточностью, это не делает из него плохого программиста, если он, к примеру, веб-программист.

Если применить мою мысль на ваш пример, то я утверждаю, что доктор все еще будет компетентным биологом.

Zonzen Nov 28 2016 at 06:18

В этих вопросах важно не стать заложником терминологии, да, и веб-программист и системный программист несут в названиях своих специализаций слово «программист», но это абсолютно разные специальности, разные уровни компетенции и ответственности. Что то вроде сравнения дальнобойщика и пилота «формулы-1».
Следовательно, Ваша фраза

Если программист не умеет работать с многопоточностью, это не делает из него плохого программиста, если он, к примеру веб-программист.

не имеет никакого смысла.

Alexey_Sarychev Nov 28 2016 at 06:34

Согласен с вами, насчет терминологи. Все зависит от того, как определять множества. Поэтому поясню более формально.

Если есть множество «программист», и оно содержит подмножества «системный программист» и «веб программист», то, если объект не является системным программистом, он все еще имеет шанс прибывать в множестве программистов.

Исходя из того, что шифрование, замыкания, NP-полные задачи и многопоточность не относятся к одной конкретной областям программирования, я сделал вывод, что множество «программист» все-таки определено.

third112 Nov 28 2016 at 09:47

Учитывая самодурство некоторых руководителей, я могу запросто представить ситуацию, когда программисту дадут многопоточную задачу, даже если он никогда с этим не сталкивался.

Все когда-то с чем-то сталкиваются впервые. Когда появились широкодоступные многоядерные CPU спецов по многопоточному программированию было мало. И вполне нормальный начальник мог сказать своим программистам: осваивайте новую технологию. Очень многим программистам периодически приходится заниматься самообразованием, советоваться с более опытными в возникающих вопросах коллегами в том числе и по сетке. Если у программиста хорошие базовые знания и он не лентяй, то он справляется. От начальника требуется реальная оценка трудозатрат и реальные сроки.

a1111exe Nov 27 2016 at 21:40

Рискую предположить, что намного больше 50% кода в настоящее время пишется программистами, которых Вы бы назвали некомпетентными. И это реальность, которой безразлично, что кому-то из компетентных гуру-программистов она не нравится. Имхо, единственный выход — культивация сообществ наподобие Хабра, где регулярно появляются материалы, призванные тем или иным образом ликвидировать ту или иную некомпетентность. Ибо книги и университеты, увы, не охватывают всё многообразие продакшена.

P.S. В идеальном мире, где все программисты компетентны, никто ни у кого ничему не может научиться. И никто никого ничему не может научить. И хуже всего в таком мире пришлось бы программистам-снобам, которым некого было бы ткнуть носом в его возмутительную некомпетентность.

maxpsyhos Nov 28 2016 at 01:42

Никогда все не будут компетентными, потому что компетентность — это понятие относительное. В любом сообществе всегда будет кто-то лучше, а кто-то хуже среднестатистического уровня. Особенно с учётом того, что количество дисциплин всё временно растёт, и гуру многопоточных числодробилок может оказаться полным днищем в написании даже простейших интерактивных интерфейсов.

a1111exe Dec 1 2016 at 19:36

Подпишусь под каждым словом.

Zonzen Nov 28 2016 at 05:52

намного больше 50% кода в настоящее время пишется программистами, которых Вы бы назвали некомпетентными.

И это видно невооруженным глазом, софт с каждым годом становится хуже. А эти «намного больше 50%» должны элементарно уйти из профессии.

Pakos Nov 28 2016 at 08:02

Софта станет на 50% меньше, но станет ли он лучше? Если оставшиеся программисты «размажутся» по направлениям и получится что кто-то попадёт в область своей некомпетентности и снова окажется «плохого софта 50%» и снова надо уходить половину из профессии. Повторить. Или если каждый окажется на прежнем месте, то будет вариант «мы тут сделали, но это бесполезно — наши данные никому не нужны, т.к. их некуда применять».

third112 Nov 28 2016 at 09:59

ИМХО из того факта, что «софт с каждым годом становится хуже» логически не следует, что программисты стали хуже. Если хорошему программисту дать слишком сжатые сроки — он либо не выполнит задачу, либо схалтурит. Во многом виновата сетка: когда появилась возможность каждодневных автоматических обновлений, многие фирмы решили, что им выгоднее выбрасывать на рынок сырые продукты — главное опередить конкурентов. Мы живем в мире непрочных вещей и сырого софта, культура этого мира — потребительская: «покупайте как можно чаще».

Zonzen Nov 28 2016 at 15:19

taujavarob Nov 28 2016 at 19:03

Мы живем в мире непрочных вещей и сырого софта, культура этого мира — потребительская: «покупайте как можно чаще».

Мир спасёт постоянная подписка.

На всё. На пользование (и обновление, конечно) софта, авто, дома…

«покупайте как можно чаще»? — Нет, это устарело — «не покупай! — подпишись на сервис, плати и живи.»

Сервис — это предоставление (когда нужно тебе) софта, авто, дома, еды, отдыха.

Иначе говоря — "Перестань владеть вещами и программами — подпишись на сервис и живи!" (С)

P.S. Пример — платная подписка на то, что новый айфон ты получишь взамен старого, как только новая модель айфона начнёт производиться. — "Подпишись и используй, пока жив". (С)

a1111exe Dec 1 2016 at 19:47

Все джуниоры тоже? Они по определению некомпетентны.

Увы, реальность такова, что наше мнение о том, кто что кому в этом мире должен, на регулярной основе реальностью игнорируется. Короче, имхо, в подобных негативных мнениях нет ничего конструктивного, т.е., они практически бесполезны. Если человек вцепился в специальность программиста, пишет говнокод, и его такое положение дел устраивает, то можно предположить следующее:

1) человеку нравится кодить (или делать что-то из того, что включает в себя этот процесс);
2) его начальству (или заказчикам в случае фриланса) текущее качество его кода безразлично, и другие подходы ему не знакомы.

Как бы нам это не нравилось, усердный говнокодер всегда найдёт работу. И если он с накоплением опыта продолжает писать говнокод, то существенная часть вины лежит и на сообществе (от его рабочего окружения и до статей на Хабре), которое не смогло или не (достаточно) захотело мотивировать его на развитие. Не думаю, что существует много чёрно-белых ситуаций.

UFO landed and left these words here

third112 Nov 27 2016 at 19:47

ИМХО про многопоточность в принципе верно сказано. Действительно не быстро и не охотно внедряется. Но очень полезная (и зачастую необходимая) вещь, когда грамотно использована. Стоило бы CUDA упомянуть…

Про «Слишком большие данные» — очевидно. И как-то слишком примитивно. Есть разные способы сжатия данных, в одной статье не перечислить, но хоть сказать, что есть — было бы не вредно.

Про NP сказано много слишком таинственного, конспирологичного. Тут ИМХО автор пытается сесть между двух стульев: для популярного объяснения слишком непонятно, а для спецов, достаточно простого упоминания, что
P =? NP пока остается открытой проблемой.

third112 Nov 27 2016 at 19:56

PS Про «червоточину» в континууме данные-время у меня слов не нашлось :)

Dum_spiro_spero Nov 28 2016 at 06:27

Скорее всего это проблема нынешнего обучения программированию. Преподаватели учат тому, чему учили их.
Надо СРАЗУ со школы учить концепции многопоточности.
Как сейчас помню — э… «напишите алгоритм мытья окна». А надо так — есть четыре брата — им надо помыть окно, при этом не переругаться и не выбить это окно нафиг. Жизненный опыт подсказывает, что две последние задачи могут оказаться существенно сложнее чем первая.

Scratch Nov 27 2016 at 19:52

Я как раз работаю над тем, чтобы у программистов было меньше косяков при работе с крипторафией) Это одна из задач нашей компании

lgorSL Nov 27 2016 at 21:25

del

lgorSL Nov 27 2016 at 21:26

NP-полная задача

Существует целая куча задач, которые проблематично вычислить без всякой np-полноты (Особенно если использовать "слишком большие данные"). Автор почему-то их не упомянул.

IIvana Nov 28 2016 at 00:40

Не понял сложностей с замыканиями. Джаваскрипт/свифт не курил, но на примере Scheme не мог бы кто показать драконов с ними? В тепличных условиях однопоточности и отсутствия всяких континюэйшен-пассингов.

Suvitruf Nov 28 2016 at 05:38

Часто встречал, когда в цикле используется замыкание, при этом не делая локальной копии переменной, из-за чего косяки всплывают. В C# проектах, как правило.

vanxant Nov 28 2016 at 07:29

Не знаю схему, но одна из проблем — утечки в языках с управляемой памятью (сборщиком мусора).
Допустим, вы случайно утащили в замыкание ссылку на какой-нибудь крупный объект. Допустим, на коллекцию, хотя из всей коллекции вам фактически нужен один элемент. И передали это замыкание куда-нибудь дальше, допустим, как обработчик клика по кнопке.
Ну и все. Коллекция, может, уже протухла, и ее давно пора сжечь, но сборщик мусора сделать этого не может, так как к ней есть путь ссылок от кнопки.

IIvana Nov 28 2016 at 11:51

Ну это имхо условная проблема. Конечно замыкание замыкает все что видит снаружи, даже если оно ему не нужно для работы. И сборщик мусора не почистит. Но во-первых, если замыкание динамически изменяемое, то бывшее ненужное внезапно может оказаться нужным. А во-вторых, если жалко держать большой ненужный объект в памяти, переменную, с ним связанную можно (в тех языках, с которыми я сталкивался) пересетить на ноль или вообще заандефить (отбиндить или как это сказать — в общем удалить связь имя-значение в словаре связей окружения). По-русски говоря — почистить за собой мусор вручную :) Хотя, с натяжкой это наверное можно записать в драконы языков с GC.

Juraseg Nov 28 2016 at 09:09

Проблема с mutability. Пример на Python:

fns = []
for i in [1, 2, 3]:
    def inner():
        return i
    fns.append(inner)

На первый взгляд список «fns» должен содержать функции, которые возвращают 1, 2 и 3. Но на самом деле все три функции будут возвращать 3. В Javascript та же печенька. А в Scheme в такую ловушку попасть сложнее, потому что изменение переменное очевидно — с помощью функции set!, и достаточно редко. А в Python или Javscript переменные меняются повсеместно явно и неявно.

UFO landed and left these words here

alex4321 Nov 29 2016 at 12:08

А теперь — запусти их отложенно и увидишь [3,3,3]. Вроде бы.
А чтобы выкрутиться — понадобится что-то типа

rng=[1,2,3]
fns=[]
for i in fns:
  def generator(counter):
    def func():
      return counter
    return func
  fns.append(generator(i))

UFO landed and left these words here

discopalevo Nov 28 2016 at 12:54

а теперь поменяй во втором цикле i на j, в js область видимости у переменных это функция а не блок.

UFO landed and left these words here

poxvuibr Nov 28 2016 at 15:52

Сколько не учи матчасть — простор для создания ошибок — огромный. А если вместо целого i передавать объект — станет ещё непонятнее.

UFO landed and left these words here

Fedcomp Nov 28 2016 at 06:37

> Многопоточность
Неплохо работает в Rust.

Zerthimon Nov 28 2016 at 08:10

off by one?

EvilArcher Nov 28 2016 at 11:02

Больше всего драконов там, где заказчику нужно быстро, желательно еще вчера, сделать мега-фичу за небольшой бюджет.

MrFrizzy Nov 28 2016 at 11:24

Имхо не некомпетентность, а специализация :)

potan Nov 28 2016 at 11:29

Замыкания при использовании иммутабельности ни каких проблем не создают.

UFO landed and left these words here

DistortNeo Nov 28 2016 at 12:39

Проблема в том, что железо императивно.

UFO landed and left these words here

maxpsyhos Nov 29 2016 at 01:36

С ФП тоже не всё так просто. Конечно, дерево вызовов в одной функции оно распараллелит. Но это не совсем о то, о чём была речь. Каким образом ФП поможет разделить доступ к ресурсу, который используется из нескольких независимых потоков? Например, чтобы один подключенный клиент мог читать файл, а другой в это же самое время писать его?

Dark_Daiver Nov 29 2016 at 06:02

Ды, никак.
Идея чистых функций в том, что они не меняют состояние. Нет изменяемого состояния — можно параллелить сколько угодно вызовов функций, они не смогут друг другу «навредить» by design.
Запись в файл который кто-то читает, это уже изменение состояния. Как это разрулить в рамках ФП я, к сожалению, не знаю =)

sbagan Nov 28 2016 at 12:46

NP-полная задача != NP задача, NP-полная — любую NP задачу можно к ней свести(например задача коммивояжера — NP-полная), определение которое тут написано — просто задача из класса NP, к тому же практической ценности в NP не так много(хотел бы посмотреть как будут масштабировать n^100, это же из P задача:)

grossws Nov 29 2016 at 12:57

Когда машина выходит за пределы ОЗУ, то она обращается к т.н. виртуальной памяти, которая действует на чрезвычайно медленном (по сравнению с ОЗУ) жёстком диске или твердотельном накопителе. Это, конечно, лучше, чем полная остановка или завершение задания, но работа замедляется в любом случае.

Гнать ссаными тряпками. КГ/АМ, в общем, если выражаться прямо.

Виртуальная память у него на hdd/ssd. А к оперативке он, видимо, доступ не через MMU получает, а через libastral.