В целом понятно. Просто идет цепочка вызовов функций. Но неужели это удобно использовать.
Абсолютно неудобно и непонятно. Поэтому и придумали ООП. Однако приверженцы ФП яро отвергают классы, поэтому придумали всевозможные классозаменители - контейнеры с условными вызовами.
Например, вместо connect(createSocket('TCP'),ip, port)
можно написать
.
Впрочем, это всего лишь попытки приблизиться к хранимому состоянию (читайте классам), которое запрещено в ФП. В итоге ярые приверженцы ФП начинают использовать такие псевдоклассы как монады, глобальные переменные, хранилища и т.п. и говорят, что это мол просто ФП с небольшими практическими расширениями, но мы то с вами понимаем...
В чем фишка всего этого ФП, не до конца понимаю
Фишка в том, что программа является не графом данных, а графом функций. Учитывая чистые функции и отсутствие внешних эффектов, получаем автоматическое распараллеливание и оптимизацию программы + универсальность вне зависимости от входных данных. Проблемы наступают только тогда, когда оказывается, что эти самые данные надо где-то хранить, а не только преобразовывать.
Плохой не пример, а сам язык и браузер. Функциональный стиль в принципе сложно подвязать под DOM, потому что это одна большая глобальная переменная (класс, ещё и с событиями).
Звучит так, что ФП это какая то мутная тема
Это очень мутная тема. Большинство прикольных функциональных фишек JS уже успел себе забрать, например map, reduce, промисы... Вот и осталась одна муть.
moki198, улучшить визуал, сделать удобное управление и всё подобное, реализовать продуманные интересные механики, отказаться от гринда в пользу сюжета.
romaro, рекомендую сформировать своё собственное мнение о программировании, а вдохновение черпать из ПО с открытым исходным кодом. В противном случае получится как с SOLID или TDD - якобы истино правильные принципы ПО будущего, но почему-то никто никогда их не использует.
Vamp, не нужно ничего складывать, нужно прочитать ссылку на OSI. Тогда сразу станет понятна абсурдность вопроса.
вы как-то путано отвечаете - то "нельзя", то "можно".
То, что нельзя реализовать одним способом, можно реализовать другим. Здесь нет никакого противоречия, просто разные контексты дают разные взгляды на одну и ту же проблему. Но если вы хотите конкретный ответ, то передавать tcp внутри udp нельзя. Хотя, вы всегда можете лично это проверить на своём собственном компьютере, раз мне не доверяете.
romaro,
1) Книга - это прежде всего второсортно или третьесортно переваренная документация, напоминает испорченный телефон.
2) Книги в магазинах существуют для того, чтобы их покупали. Если бы их цель была помочь вам изучить шарп, то книги лежали бы в открытом доступе.
3) Книга несравнимо ограничена. В документации есть и версия, и платформа. В документации можно посмотреть исходный код, перевод. В документации есть онлайн-компилятор, живые примеры, ссылки и огромное количество дополнительной информации.
4) В документации присутствуют видео уроки, уроки разных уровней, различные мануалы и руководства. В книге вы видите исключительн однобокую точку зрения автора, который, скорее всего, 10 лет уже не программирует сам, а просто читает лекции и пишет книги.
Vamp, нет, нельзя понижать уровень OSI. Данные передаются посредством инкапсуляции, т.е. снизу вверх. Поскольку L3 не ниже L3, то L3 нельзя инкапсулировать в L3, но можно инкапсулировать дополнительный виртуальный стек/VPN (поверх уже текущего VPN), в который в свою очередь инкапсулировать L3. В случае L2, можно напрямую инкапсулировать L3 в него без дополнительного слоя.
Здесь можно прочитать подробнее о протоколах и API.
romaro, книги, разумеется, полезны, но несравнимо более полезна официальная документация. Потому что книги пишут для зарабатывания денег, если вдруг вы не знали.
Абсолютно неудобно и непонятно. Поэтому и придумали ООП. Однако приверженцы ФП яро отвергают классы, поэтому придумали всевозможные классозаменители - контейнеры с условными вызовами.
Например, вместо
connect(createSocket('TCP'),ip, port)
можно написать
.
Впрочем, это всего лишь попытки приблизиться к хранимому состоянию (читайте классам), которое запрещено в ФП. В итоге ярые приверженцы ФП начинают использовать такие псевдоклассы как монады, глобальные переменные, хранилища и т.п. и говорят, что это мол просто ФП с небольшими практическими расширениями, но мы то с вами понимаем...
Фишка в том, что программа является не графом данных, а графом функций. Учитывая чистые функции и отсутствие внешних эффектов, получаем автоматическое распараллеливание и оптимизацию программы + универсальность вне зависимости от входных данных. Проблемы наступают только тогда, когда оказывается, что эти самые данные надо где-то хранить, а не только преобразовывать.
Виталий Першин,
Плохой не пример, а сам язык и браузер. Функциональный стиль в принципе сложно подвязать под DOM, потому что это одна большая глобальная переменная (класс, ещё и с событиями).
Это очень мутная тема. Большинство прикольных функциональных фишек JS уже успел себе забрать, например map, reduce, промисы... Вот и осталась одна муть.