как раз и являются «моральным обязательством». Не юридическим, разумеется, но моральным — вполне. Поэтому лицемерие тут очевидно. Любовь — это именно бескорыстное такое стремление, чтобы отдавать и не требовать взамен, но у них что-то не очень действия согласуются со словами. Отдают не особо нужный кусочек или нечто сугубо по расчёту. Как по мне, это ни фига любовью назвать нельзя. Претензии же чисто к риторике, а не к тому, что они что-то там обещают или нарушают.
Так я как раз к тому, что передёргивать не надо. Да, всё можно решить на ассемблере, всё так же можно решить с помощью ФП. Но эффективность (по различным критериям, замечу) обоих подходов в каждом конкретном случае может различаться на порядки. Где-то важнее производительность, где-то читабельность, где-то близость к матаппарату. И далеко не в каждой задаче этот матаппарат необходим повсеместно.
Представьте, что вы пишете игру. У вас есть граф сцены в виде дерева, у каждого элемента есть список дочерних узлов. На сцене появляется монстр, его нужно добавить в этот граф. Но так как у вас функциональный подход, дерево не мутабельно, т.е. вам нужно сделать копию с добавленным в граф новым объектом. Конечно, тут могут быть всякие оптимизации со стороны компилятора, который заметит, что вы не используете и не сохраняете нигде предыдущее состояние дерева, поэтому можно схитрить и мутировать структуру, но полагаться на это, пожалуй, наивно. Потому что если вы вдруг где-то всё же сохраните старое состояние, оптимизация сломается, и производительность просядет дичайше. Поправьте, если я что-то не так понимаю, но в таких ситуациях, упрощённо, математически некорректное x = x + 1 работает проще, быстрее и очевиднее, чем return x + 1 в некой рекурсивной функции.
Пример с софтом — это частный случай, который не подтверждает намного более сильное утверждение, что ФП прямо всегда и везде лучше ИП. Был плохой код на одном языке, стал хороший код на другом языке, таких примеров можно найти массу, и необязательно они связаны со сменой парадигмы программирования. Иначе игры бы тоже писали на хаскеле или лиспе, но что-то пока даже близко не видно такого тренда.
Сказать можно больше, ФП справляется с такими задачи намного лучше императивного подхода. ФП идеально подходит для любой задачи, итеративный подход почти везде это грабли.
Я бы не стал так идеализировать. ФП такой же подход к решению задач, как и любой другой, со своими плюсами и минусами. Из описанных свойств персистентности следует повышенная нагрузка на GC, например, при итерации по очереди будут создаваться и практически сразу удаляться временные объекты Tuple/Queue, тогда как при обычном for будет меняться лишь одна переменная-указатель (или индекс). Я не вижу, почему первый вариант будет производительнее второго и уж тем более читабельнее.
Безусловно, для параллельных вычислений функциональная чистота полезна, такой код писать и поддерживать будет скорее всего проще, чем императивный, и это будет важнее потерь производительности. Но это опять же доказывает, что все случаи индивидуальны, и стричь все задачи под одну функциональную гребёнку неразумно. Также, не будем забывать, что сами процессоры работают очень императивно и мутабельно, поэтому абстракции поверх этой логики всегда будут нести накладные расходы (дополнительные аллокации памяти как минимум). Но изначально функциональные языки типа Haskell, насколько я знаю, оптимизируются под такую логику работы, поэтому там оверхед должен быть меньше, чем в изначально императивной Java.
Ещё есть фундаментально грязные функции — работа с любым I/O, т.к. при этом меняется внешнее состояние, тут ничего не поделать. Без очень сильного колдунства не получится представить файлы, например, в виде иммутабельной структуры. Придётся хранить отдельную копию файла на каждое изменение или применять снапшоты/CoW, причём, всё это в большинстве случаев без особой практической необходимости, чисто ради поддержания идеологии.
При всём при этом, мне нравится ФП, и я его иногда применяю именно в сочетании с императивным подходом. В Java с помощью Optional и Stream можно достаточно элегантно и надёжно описывать логику, которая иначе вырождается в кучу проверок на null и обработку различных исключений. Просто не думаю, что стоит ударяться в крайности, от этого чаще всего страдает качество конечного продукта.
Я прекрасно знаю, как устроен UTF-16. Но я не понимаю, как связана сборка Java с помощью G++ и хранение строк в UTF-16 внутри Java. Это несколько разные области, и одна никак не обязывает другую поддерживать какие-то возможности. Никто ведь не требует, чтобы в GCC был garbage collector, верно?
Так она вроде собирается с помощью G++, не? Не очень понимаю, как это относится к теме. Я сам поддерживаю UTF-8, да и не только я, вот сайт хороший есть о ней. Но что поделаешь, в джаве UTF-16, придётся жить с этим.
Да вот не знают, потому что никогда не упоминают. Нужен он затем, что полностью бесплатен и свободен, я предпочитаю, чтобы инструменты были доступны всем и всегда, а не за деньги и от одного поставщика. С играми ситуация другая, они не так важны, а вот инструмент должен быть свободен. Причём, финансовый вопрос мне лично не так важен, давно настроил ежемесячный донат в Eclipse, и по подсчётам денег туда уже ушло больше, чем стоят лицензии IntelliJ. Мне просто не нравится идеевская бизнес-модель с пейволлом, предпочитаю спонсировать по мере сил компанию, которая приносит пользу всему миру, а не только собственным клиентам.
Вот да, xrandr хорош. С двойными мониторами и на Windows бывают проблемы при запуске игр — запускается не на том, где хочется. Я-то думал, это чисто линуксовое, часто читал, что люди плевались. Сам раньше решал запуском Big Picture на ТВ на вторых иксах, но, внезапно, оказалось очень сложно сделать активным только второй выход (через xorg.conf), тогда как первичный должен отключаться. В какой-то момент это всё сломалось и перестало работать как надо, и тогда я сделал простой трюк с xrandr, который выключает DVI, включает HDMI выход и запускает Steam в Big Picture, т.о. десктоп перепрыгивает на ТВ, а монитор просто отключается. И игры гарантированно запускаются на ТВ, им больше негде.
Все знают про CLion, но никто не знает про Eclipse CDT. Это как GIMP и Krita практически. Очень обидно, что хорошие и по-настоящему (no strings attached) свободные инструменты неизвестны для большинства.
Как правило, дальнейшая стабильность линукса напрямую зависит от того, кто его устанавливает и настраивает. Систему надо изучать, тут ничего не поделаешь, но всё окупается сторицей. И да, это не «бесплатная винда», это совсем другая система, кто этого не понимает, те обычно и страдают.
Вставка выделенного нажатием на колесо, Compose key, типографская раскладка из коробки, переключение раскладок Caps Lock'ом, смена языка всей системы и любых программ одной строчкой, управление окнами с клавиатуры (тайловые WM) — да всё это не нужно!
Ну вообще-то
как раз и являются «моральным обязательством». Не юридическим, разумеется, но моральным — вполне. Поэтому лицемерие тут очевидно. Любовь — это именно бескорыстное такое стремление, чтобы отдавать и не требовать взамен, но у них что-то не очень действия согласуются со словами. Отдают не особо нужный кусочек или нечто сугубо по расчёту. Как по мне, это ни фига любовью назвать нельзя. Претензии же чисто к риторике, а не к тому, что они что-то там обещают или нарушают.
Потому что это не влияло на выживаемость отдельных особей.
Так я как раз к тому, что передёргивать не надо. Да, всё можно решить на ассемблере, всё так же можно решить с помощью ФП. Но эффективность (по различным критериям, замечу) обоих подходов в каждом конкретном случае может различаться на порядки. Где-то важнее производительность, где-то читабельность, где-то близость к матаппарату. И далеко не в каждой задаче этот матаппарат необходим повсеместно.
Представьте, что вы пишете игру. У вас есть граф сцены в виде дерева, у каждого элемента есть список дочерних узлов. На сцене появляется монстр, его нужно добавить в этот граф. Но так как у вас функциональный подход, дерево не мутабельно, т.е. вам нужно сделать копию с добавленным в граф новым объектом. Конечно, тут могут быть всякие оптимизации со стороны компилятора, который заметит, что вы не используете и не сохраняете нигде предыдущее состояние дерева, поэтому можно схитрить и мутировать структуру, но полагаться на это, пожалуй, наивно. Потому что если вы вдруг где-то всё же сохраните старое состояние, оптимизация сломается, и производительность просядет дичайше. Поправьте, если я что-то не так понимаю, но в таких ситуациях, упрощённо, математически некорректное
x = x + 1работает проще, быстрее и очевиднее, чемreturn x + 1в некой рекурсивной функции.Пример с софтом — это частный случай, который не подтверждает намного более сильное утверждение, что ФП прямо всегда и везде лучше ИП. Был плохой код на одном языке, стал хороший код на другом языке, таких примеров можно найти массу, и необязательно они связаны со сменой парадигмы программирования. Иначе игры бы тоже писали на хаскеле или лиспе, но что-то пока даже близко не видно такого тренда.
Я бы не стал так идеализировать. ФП такой же подход к решению задач, как и любой другой, со своими плюсами и минусами. Из описанных свойств персистентности следует повышенная нагрузка на GC, например, при итерации по очереди будут создаваться и практически сразу удаляться временные объекты Tuple/Queue, тогда как при обычном for будет меняться лишь одна переменная-указатель (или индекс). Я не вижу, почему первый вариант будет производительнее второго и уж тем более читабельнее.
Безусловно, для параллельных вычислений функциональная чистота полезна, такой код писать и поддерживать будет скорее всего проще, чем императивный, и это будет важнее потерь производительности. Но это опять же доказывает, что все случаи индивидуальны, и стричь все задачи под одну функциональную гребёнку неразумно. Также, не будем забывать, что сами процессоры работают очень императивно и мутабельно, поэтому абстракции поверх этой логики всегда будут нести накладные расходы (дополнительные аллокации памяти как минимум). Но изначально функциональные языки типа Haskell, насколько я знаю, оптимизируются под такую логику работы, поэтому там оверхед должен быть меньше, чем в изначально императивной Java.
Ещё есть фундаментально грязные функции — работа с любым I/O, т.к. при этом меняется внешнее состояние, тут ничего не поделать. Без очень сильного колдунства не получится представить файлы, например, в виде иммутабельной структуры. Придётся хранить отдельную копию файла на каждое изменение или применять снапшоты/CoW, причём, всё это в большинстве случаев без особой практической необходимости, чисто ради поддержания идеологии.
При всём при этом, мне нравится ФП, и я его иногда применяю именно в сочетании с императивным подходом. В Java с помощью Optional и Stream можно достаточно элегантно и надёжно описывать логику, которая иначе вырождается в кучу проверок на null и обработку различных исключений. Просто не думаю, что стоит ударяться в крайности, от этого чаще всего страдает качество конечного продукта.
Я бы почитал про стратегию диверсификации, которая позволяет обогнать индекс. Потому что иначе какой в этом смысл?
Я прекрасно знаю, как устроен UTF-16. Но я не понимаю, как связана сборка Java с помощью G++ и хранение строк в UTF-16 внутри Java. Это несколько разные области, и одна никак не обязывает другую поддерживать какие-то возможности. Никто ведь не требует, чтобы в GCC был garbage collector, верно?
Так она вроде собирается с помощью G++, не? Не очень понимаю, как это относится к теме. Я сам поддерживаю UTF-8, да и не только я, вот сайт хороший есть о ней. Но что поделаешь, в джаве UTF-16, придётся жить с этим.
Внутри Java строки представлены именно в UTF-16.
Почти так:
Так она и пишет «Мой компьютер», был бы он ваш, писалось бы «Ваш компьютер».
Да вот не знают, потому что никогда не упоминают. Нужен он затем, что полностью бесплатен и свободен, я предпочитаю, чтобы инструменты были доступны всем и всегда, а не за деньги и от одного поставщика. С играми ситуация другая, они не так важны, а вот инструмент должен быть свободен. Причём, финансовый вопрос мне лично не так важен, давно настроил ежемесячный донат в Eclipse, и по подсчётам денег туда уже ушло больше, чем стоят лицензии IntelliJ. Мне просто не нравится идеевская бизнес-модель с пейволлом, предпочитаю спонсировать по мере сил компанию, которая приносит пользу всему миру, а не только собственным клиентам.
Ну вот оверкоммита памяти нет, файловых систем поддерживается всего 2.5, и они не очень. Прибитый к ядру гуй меня лично не радует, но это дело вкуса.
Этот процент и так не был ЦА Valve и Steam, так что можно не переживать о них особо.
Я тоже не знаю про Shift+Alt+F7. Что это за комбинация?
Вот да, xrandr хорош. С двойными мониторами и на Windows бывают проблемы при запуске игр — запускается не на том, где хочется. Я-то думал, это чисто линуксовое, часто читал, что люди плевались. Сам раньше решал запуском Big Picture на ТВ на вторых иксах, но, внезапно, оказалось очень сложно сделать активным только второй выход (через xorg.conf), тогда как первичный должен отключаться. В какой-то момент это всё сломалось и перестало работать как надо, и тогда я сделал простой трюк с xrandr, который выключает DVI, включает HDMI выход и запускает Steam в Big Picture, т.о. десктоп перепрыгивает на ТВ, а монитор просто отключается. И игры гарантированно запускаются на ТВ, им больше негде.
Все знают про CLion, но никто не знает про Eclipse CDT. Это как GIMP и Krita практически. Очень обидно, что хорошие и по-настоящему (no strings attached) свободные инструменты неизвестны для большинства.
Ну обычно я так и делаю, в tty1 логинюсь, останавливаю lightdm, ставлю драйвер, запускаю lightdm.
Как правило, дальнейшая стабильность линукса напрямую зависит от того, кто его устанавливает и настраивает. Систему надо изучать, тут ничего не поделаешь, но всё окупается сторицей. И да, это не «бесплатная винда», это совсем другая система, кто этого не понимает, те обычно и страдают.
Вставка выделенного нажатием на колесо, Compose key, типографская раскладка из коробки, переключение раскладок Caps Lock'ом, смена языка всей системы и любых программ одной строчкой, управление окнами с клавиатуры (тайловые WM) — да всё это не нужно!