Это понятно, про аббревиатуру я написал просто, чтобы подчеркнуть насколько давно на практике используется этот способ загрузки страницы. Ну а то, что его не патентовали… так что ж теперь каждый алгоритм патентовать?
А как им удалось это запатентовать то? Этой технологии уже 100 лет в обед… статья 2011 года, статья 2009 года и скорее всего и более ранние упоминания можно найти, ещё тех времён, когда аббревиатура AJAX в употребление ещё не вошла.
А кто говорил про остановку разработки… какая связь…
У вас если у провайдера авария и интернет отключился, то программисты домой уходят вместо того, чтобы продолжать работать? Если да, то вот это уже точно можно считать п-цом.
Вообще, я невнимательно прочитал комментарий Lertmind… и по сути ответил на цитату из ЖЖ, что не имело особого смысла.
Просто меня удивляют подобные формулировки… типа, если Github закроется (допустим не роскомнадзором, а сам по себе), то пи**ец всей отрасли… программисты работать сразу не смогут. Это ведь неправда.
И что? Вы каждый день обновляете/добавляете зависимости в проект?
Документация обычно ещё и локально сохраняется при установке пакетов.
Понятно, что ряд неудобств это несёт, но пару дней поработать даже без интернета вполне можно и вполне эффективно. А у минусующих, видимо, сильная гитхабозависимость и это повод задуматься…
Это тоже. Когда уже знаешь несколько языков, наступает момент, когда читать в очередной раз про float vs double или про видимость методов и т.д. становится невыносимо скучно )
Серия «для нетерпеливых» уже лучше, но если оценивать «Scala for the Impatient», которую я недавно читал, то там тоже банальщины выше крыши.
Впрочем, есть и более хардкорные способы изучения, например: Learn X in Y minutes + документация по стандартной библиотеке (читать не целиком, а по мере необходимости).
Для новичков как раз нужны книги для новичков («за 21 день», «на примерах» и т.д.).
Сложно представить, что кто-то может научиться программировать по толстому учебнику, приправив его ещё чтением стандарта и справочника по библиотеке.
Имхо, так можно учить 3-й, 4-й язык (я сам так C# когда-то давно изучал по 2 книгам Шилдта + стандарт), но не первый.
Работа многих программистов в России парализована, увы.
При всей неприятности ситуации, вы всё-таки сгущаете краски… Это ж основное преимущество git перед svn, что доступ к центральному репозиторию не нужен для полноценной работы. Так что парализовать работу не должно даже отключение интернета на пару дней )))
Остаётся только повторить, так в чём уникальность и неповторимость FP? Оно чуть удобнее в какой-то области задач? Подобное можно про каждую парадигму программирования сказать.
В принципе да, поэтому чем больше парадигм знаешь, тем лучше. Императивную хотя бы частично (процедурную, структурную, объектно-ориентированную на классах) знают все, декларативную — пока немногие.
По-моему глупо рассчитывать, что все задачи можно решить в рамках какой-то единственной парадигмы и при этом ни разу не загнать себя в дикие извращения. У каждой есть своя сфера применимости.
1) Практические преимущества есть и без 100% чистоты… она не является самоцелью. Хотя может в Haskell и в Clean и является, я не в курсе, но в других функциональных языках с ней точно не носятся как с хрустальной вазой.
2) Необходимость использовать FFI на практике возникает крайне редко. И ничто не мешает скопировать аргументы и изменять in-place их копию, что вполне себе сэмулирует чистоту на уровне абстракции самой программы: «вызвали функцию, она вернула результат, никак не повлияв на свои аргументы». Все преимущества чистоты следуют сугубо из того, как это работает на верхнем уровне абстракции, а не из того, как это достигается на уровне ассемблера.
Везде свои компромиссы. Увеличение алгоритмической сложности некоторых алгоритмов не делает задачи не решаемыми, но показывает, что для таких алгоритмов есть более подходящие инструменты. Да и FFI никто не отменял, всегда можно дёрнуть реализацию алгоритма на C, если именно это является узким местом. Только задач, которые упираются в это, на практике встречается не так уж много. Ну а тем, у кого практический опыт другой и подобные задачи сплошь и рядом, лучше всё писать на С/С++.
Другими словами, абстрактный выбор между функциональными и императивными языками — это бессмысленный холивар. Язык надо выбирать исходя из своих конкретных задач.
Но это ничуть не меняет дело, и большинство проектов пишутся в императивно-оопшном стиле.
К чему эти обобщения на всю индустрию на основе своего личного опыта? На мой взгляд выбор между ФП и ООП — это совершенно бесполезное словоблудие (аля эта статья) вне контекста конкретной области программирования (а в идеале конкретного проекта). Ни то, ни другое не является лучшим выбором для 100% задач.
Вы разве не поняли, что я в верхнем посте именно это и имел в виду касательно quicksort?
Так а в чём смысл обсуждать quicksort в контексте ФП? То, что алгоритмы, основанные на in-place модификации данных, нельзя реализовать в рамках ФП, по-моему, вполне очевидно. Не понимаю, чем это Вас разочаровало…
Ахах, чего ж Вы так нервничаете, сами просили ООП в рамках ФП посмотреть, а как увидели, так сразу за лозунги уровня первого курса )))
Во-первых «наследование-инкапсуляция-полиморфизм» никогда не было определением ООП. Во-вторых, все бенефиты этой триады не зависят от объектно-ориентированности языка.
Наследование прекрасно заменяется композицией и примесями, что и в рамках классового ООП давно и активно применяется для борьбы с антипаттернами наследования. Инкапсуляция по факту только с иммутабельными данными возможна, пока Вы можете менять аргументы метода по ссылке, можно только притворяться, что есть инкапсуляция. Полиморфизм спокойно реализуется через duck-typing и typespecs (аля интерфейсы), в том числе и во многих ООЯП.
И да, Вы упорно путаете ФП и ФЯП. Поддержка ФП в какой-то мере уже включена почти во все популярные нефунциональные языки программирования. И с каждым годом всё больше языков расширяют эту поддержку… посмотрите хотя бы на C# и Java, на эти оплоты ООП, первый уже давно насквозь пронизан ФП, а второй окончательно признал популярность ФП 2 года назад.
P.S. Ну а на тему quicksort, это алгоритм на базе мутабельного массива. Имхо, совершенно очедичный факт, что он не может быть реализован в функциональном стиле вообще никак. Те эмуляции, которые Вы видели, никакого отношения к реализации quicksort не имеют.
не совсем «ортогональны», если «дополняют друг друга»?
Ну, вот была у Вас одна ось X и линейное мышление, а потом Вы добавили ортогональную ось Y, на которой тоже можно линейно мыслить. Но если Вы знаете про обе оси (дополнили одну другой), то у вас уже есть плоскость, а не линия. Так понятнее?
Чем больше парадигм Вы освоите, тем объёмнее станет мышление, а пытаясь кому-то доказать, что одной парадигмы достаточно для всего — Вы добровольно надеваете себе шоры.
А Вы сами то понимаете о чём спор?
Вы передёрнули факты «Мне кажется, ООП — более высокий уровень абстракции, и оно может существовать и с ФП «под капотом»», Вас протроллили в ответ зеркальным передёргиванием «Мне кажется, ФП — более высокий уровень абстракции, и оно может существовать и с ООП «под капотом»».
Теперь Вы скатились до истерики функции vs объекты, что совсем не то же самое, что ФП vs ООП, надеюсь, хоть это очевидный факт.
Ну а истина как всегда где-то посередине, ФП не конфликтует с ООП, они вообще ортогональны и взаимодополняют друг друга.
Зачем вспоминать акторы Scala, я не понял, это ведь частичная калька с Erlang. И да, ООП на базе акторов — это ООП в рамках ФП, которое Вы так жаждали увидеть.
в 99.99% случаев ООП — это-таки наследование-инкапсуляция-полиморфизм
ну, если Вам легче живётся с этой аффирмацией, то, пожалуйста, никто у Вас её не отнимает
По-моему Вы слегка путаете мутабельность данных с изменением состояния.
Мутабельность данных означает, что Вы можете полностью перезаписать значение переменной в ОЗУ и все переменные, указывающие на этот же адрес в памяти, также получат новое значение. Именно мутабельности данных нет в ФП, а состояние изменяется без проблем, просто оно не разделяемое, а по-настоящему инкапсулировано в лучших традициях ООП )))
Подумайте, знаете ли Вы хоть один императивный язык, поддерживающий инкапсуляцию в полной мере? Или метод одного объекта может вызвать метод другого объекта и передать ему часть своего состояния по ссылке? А ведь это прямое нарушение инкапсуляции, т.к. другой объект может спокойно и без каких-либо разрешений или уведомлений изменить значение по этой ссылке.
пруф
статья 2011 года, статья 2009 года и скорее всего и более ранние упоминания можно найти, ещё тех времён, когда аббревиатура AJAX в употребление ещё не вошла.
У вас если у провайдера авария и интернет отключился, то программисты домой уходят вместо того, чтобы продолжать работать? Если да, то вот это уже точно можно считать п-цом.
Просто меня удивляют подобные формулировки… типа, если Github закроется (допустим не роскомнадзором, а сам по себе), то пи**ец всей отрасли… программисты работать сразу не смогут. Это ведь неправда.
Документация обычно ещё и локально сохраняется при установке пакетов.
Понятно, что ряд неудобств это несёт, но пару дней поработать даже без интернета вполне можно и вполне эффективно. А у минусующих, видимо, сильная гитхабозависимость и это повод задуматься…
По сути я написал то же самое :-)
Серия «для нетерпеливых» уже лучше, но если оценивать «Scala for the Impatient», которую я недавно читал, то там тоже банальщины выше крыши.
Впрочем, есть и более хардкорные способы изучения, например: Learn X in Y minutes + документация по стандартной библиотеке (читать не целиком, а по мере необходимости).
Сложно представить, что кто-то может научиться программировать по толстому учебнику, приправив его ещё чтением стандарта и справочника по библиотеке.
Имхо, так можно учить 3-й, 4-й язык (я сам так C# когда-то давно изучал по 2 книгам Шилдта + стандарт), но не первый.
По-моему глупо рассчитывать, что все задачи можно решить в рамках какой-то единственной парадигмы и при этом ни разу не загнать себя в дикие извращения. У каждой есть своя сфера применимости.
2) Необходимость использовать FFI на практике возникает крайне редко. И ничто не мешает скопировать аргументы и изменять in-place их копию, что вполне себе сэмулирует чистоту на уровне абстракции самой программы: «вызвали функцию, она вернула результат, никак не повлияв на свои аргументы». Все преимущества чистоты следуют сугубо из того, как это работает на верхнем уровне абстракции, а не из того, как это достигается на уровне ассемблера.
Другими словами, абстрактный выбор между функциональными и императивными языками — это бессмысленный холивар. Язык надо выбирать исходя из своих конкретных задач.
Так а в чём смысл обсуждать quicksort в контексте ФП? То, что алгоритмы, основанные на in-place модификации данных, нельзя реализовать в рамках ФП, по-моему, вполне очевидно. Не понимаю, чем это Вас разочаровало…
Во-первых «наследование-инкапсуляция-полиморфизм» никогда не было определением ООП. Во-вторых, все бенефиты этой триады не зависят от объектно-ориентированности языка.
Наследование прекрасно заменяется композицией и примесями, что и в рамках классового ООП давно и активно применяется для борьбы с антипаттернами наследования. Инкапсуляция по факту только с иммутабельными данными возможна, пока Вы можете менять аргументы метода по ссылке, можно только притворяться, что есть инкапсуляция. Полиморфизм спокойно реализуется через duck-typing и typespecs (аля интерфейсы), в том числе и во многих ООЯП.
И да, Вы упорно путаете ФП и ФЯП. Поддержка ФП в какой-то мере уже включена почти во все популярные нефунциональные языки программирования. И с каждым годом всё больше языков расширяют эту поддержку… посмотрите хотя бы на C# и Java, на эти оплоты ООП, первый уже давно насквозь пронизан ФП, а второй окончательно признал популярность ФП 2 года назад.
P.S. Ну а на тему quicksort, это алгоритм на базе мутабельного массива. Имхо, совершенно очедичный факт, что он не может быть реализован в функциональном стиле вообще никак. Те эмуляции, которые Вы видели, никакого отношения к реализации quicksort не имеют.
Чем больше парадигм Вы освоите, тем объёмнее станет мышление, а пытаясь кому-то доказать, что одной парадигмы достаточно для всего — Вы добровольно надеваете себе шоры.
Вы передёрнули факты «Мне кажется, ООП — более высокий уровень абстракции, и оно может существовать и с ФП «под капотом»», Вас протроллили в ответ зеркальным передёргиванием «Мне кажется, ФП — более высокий уровень абстракции, и оно может существовать и с ООП «под капотом»».
Теперь Вы скатились до истерики функции vs объекты, что совсем не то же самое, что ФП vs ООП, надеюсь, хоть это очевидный факт.
Ну а истина как всегда где-то посередине, ФП не конфликтует с ООП, они вообще ортогональны и взаимодополняют друг друга.
Зачем вспоминать акторы Scala, я не понял, это ведь частичная калька с Erlang. И да, ООП на базе акторов — это ООП в рамках ФП, которое Вы так жаждали увидеть.
ну, если Вам легче живётся с этой аффирмацией, то, пожалуйста, никто у Вас её не отнимает
По-моему Вы слегка путаете мутабельность данных с изменением состояния.
Мутабельность данных означает, что Вы можете полностью перезаписать значение переменной в ОЗУ и все переменные, указывающие на этот же адрес в памяти, также получат новое значение. Именно мутабельности данных нет в ФП, а состояние изменяется без проблем, просто оно не разделяемое, а по-настоящему инкапсулировано в лучших традициях ООП )))
Подумайте, знаете ли Вы хоть один императивный язык, поддерживающий инкапсуляцию в полной мере? Или метод одного объекта может вызвать метод другого объекта и передать ему часть своего состояния по ссылке? А ведь это прямое нарушение инкапсуляции, т.к. другой объект может спокойно и без каких-либо разрешений или уведомлений изменить значение по этой ссылке.