Мне кажется не совсем справедливым то, что в одном случае вы сжимаете данные уже загруженные в память (byte[]), а в другом — работаете с ФС в процессе компрессии.
Может быть лучше было бы использовать ByteArray(Input/Output)Stream для потоковых алгоритмов.
Очень неплохо, но все-таки более ограничено чем в Erlang/Scala/Haskell. И это все-таки не средство самого языка, а следствие его гибкости, позволяющей делать такие вещи.
Недавно проскакивала статья-перевод, про Scala и CLojure и отказ от ООП, чем мне показалась немного каламбурной.)
Чем именно?
Автор той статьи продолжает использовать объекты JVM, но подход, который он описывает действительно больше похож на ФП, чем на ООП. И объектов в смысле ООП у него там действительно практически нет, похоже.
Про доскональное изучение ТК чтобы разобраться в Haskell — мне кажется, что так до самого языка можно и не дойти =) Мне, например, проще углублять знания итеративно — чуть теории — чуть Haskell — поглубже в теорию — поглубже в язык и так далее. Хотя сама ТК у меня достаточно тяжело идет, если честно.
Ну расширяемость классов тоже к функциональным языкам не относится, я не упомянул ее потому, что в тексте это и не утверждалось.
Я не готов оценивать удобство или неудобство отсутствие перегрузки в Ocaml, поскольку не писал на нем ничего. Но в Haskell перегрузка операторов (через определение операторов в классах типов) прекрасно соседствует с аналогичным по мощности выводом типов.
А разве в Python есть паттерн-матчинг? Я знаю только про list/tuple unpacking, который является его очень частным случаем.
Неплохой обзор возможностей современных JVM-языков. Но от функциональных языков все дальше и дальше, как мне кажется.
В частности, ни одна из двух затронутых здесь тем к функциональным ЯП не относится.
Общая возможность функциональный языков программирования это перегрузка операторов
А кроме того, это возможность таких языков, как: C++, Фортран 90, Ада
А есть функциональные без перегрузки операторов, например Ocaml
Ну и про перегрузку в Лиспе (и соответственно Clojure) можно поспорить (начиная с того, что вообще считать там операторами)
Our drag-and-drop gameplay designer pays homage to the successful MIT Scratch project. We extend Scratch's simple block-snapping interface with new functionality and hundreds of ready-to-use blocks, including special blocks for native iOS features.
По поводу поиска — если сценарии использования вашего приложения включают поиск по полям — используйте те средства, которые позволяют его просто реализовать. Например, БД. Или Сфинкс. Или ДокуВики (интересно как там это сделано, не знал про нее).
Если не включают — вы можете использовать что-то более простое.
В случае «сайтов на которых есть только набор статических страниц», пользователю не нужен поиск по полям, ему нужен поиск страниц — с этим прекрасно справляется какой-нибудь Google Site Search.
Разумеется, если вы пишите сайт магазина или социальную сеть — хранение в файлах это совсем не самое лучшее решение, и я не знаю как тут обойтись без БД.
Просто используйте те инструменты, которые подходят к вашей конкретной задаче.
Да, безусловно когда количество таких моментов растет, готовое решение будет явно лучше. Возможно, что это будет именно БД.
Но, из того, что вы указали преимуществом БД является вообще говоря только одновременный доступ.
Все остальные проблемы (валидация, квотирование, сериализация) решаются или библиотекой работы с БД или кодом в вашем приложении, который с ней взаимодействует.
Точно так же вы можете решать их стандартными средствами и без БД. Например, сериализуя данные в JSON/YAML, для чего сейчас практически везде есть стандартные средства.
Много кода это очевидно хуже чем мало, да. Поэтому, где это возможно лучше использовать готовые средства. Но БД не является единственным таким средством. Например, в руби есть такая штука как PStore, он кстати и проблемы одновременного доступа решает используя атомарные переименования.
Вот когда БД вам действительно нужна — это несколько серверов, работающих с одним набором даннымх. Ну или если вы делаете какие-то выборки кроме как по ключу, конечно.
Но, если вернуться к началу ветки — я все-таки писал о «большинстве современных сайтов на которых есть только набор статических страниц». Мне кажется, что 90% их потребностей покрывают готовые средства вроде Jekyll или PulseCms. И писать строки кода, решающие описанные проблемы там не нужно ни при использовании БД ни без нее.
Я не являюсь противником использования БД. Они крайне полезны во многих случаях. Но мне кажется, что стоит использовать простые решения когда задача это позволяет.
Разумеется, писать вручную часто дольше чем использовать готовый компонент. Всегда нужен какой-то компромисс.
Но вы смотрели, нету ли каких-то уже готовых решений которые в некоторых задачах могут заменить БД не уменьшив ни эффективности разработки ни эффективности решения?
Я, например, упоминал Jekyll. На нем построены GitHub Pages, которыми пользуются достаточно многие, для сайтов проектов, блогов и т.п. И там совсем не надо писать 200 строк сохранение/загрузки. Более того, там не надо писать даже 5 строк. Есть еще некоторое количество менее известных утилит, делающих приблизительно то же самое.
Но, конечно, иногда необходим чтобы клиент мог редактировать контент в браузере и все такое. Для таких случае есть например pulsecms.com/
P.S. Действительно ли сохранение/загрузка файла на диск требует в 40 раз больше кода, чем выполнение запроса к БД?
Мне кажется, что автор писал не о том, чтобы абстрагироваться от БД, а вообще не рассматривать БД как обязательный элемент.
Например, большинство современных сайтов на которых есть только набор статических страниц зачем-то тянут за собой БД. Там как раз не нужно ни хитрых выборок, ни отчетов. Прекрасно можно обойтись просто файловой системой.
На самом деле в таких случаях не нужно даже PHP/Ruby/Python для обработки каждого запроса. Можно все так же удобно сделать через генераторы вроде Jekyll. Но это уже оффтоп, конечно.
Полностью согласен. Кроме казусов и глюков еще чаще бывает неэффективное использование — например многие БД имеют полезные особенности, не доступные через слой абстракции.
Ну и стоит вспомнить еще и о законе текучих абстракций:
Может быть лучше было бы использовать ByteArray(Input/Output)Stream для потоковых алгоритмов.
Очень неплохо, но все-таки более ограничено чем в Erlang/Scala/Haskell. И это все-таки не средство самого языка, а следствие его гибкости, позволяющей делать такие вещи.
Чем именно?
Автор той статьи продолжает использовать объекты JVM, но подход, который он описывает действительно больше похож на ФП, чем на ООП. И объектов в смысле ООП у него там действительно практически нет, похоже.
Про доскональное изучение ТК чтобы разобраться в Haskell — мне кажется, что так до самого языка можно и не дойти =) Мне, например, проще углублять знания итеративно — чуть теории — чуть Haskell — поглубже в теорию — поглубже в язык и так далее. Хотя сама ТК у меня достаточно тяжело идет, если честно.
Я не готов оценивать удобство или неудобство отсутствие перегрузки в Ocaml, поскольку не писал на нем ничего. Но в Haskell перегрузка операторов (через определение операторов в классах типов) прекрасно соседствует с аналогичным по мощности выводом типов.
А разве в Python есть паттерн-матчинг? Я знаю только про list/tuple unpacking, который является его очень частным случаем.
В частности, ни одна из двух затронутых здесь тем к функциональным ЯП не относится.
А кроме того, это возможность таких языков, как: C++, Фортран 90, Ада
А есть функциональные без перегрузки операторов, например Ocaml
Ну и про перегрузку в Лиспе (и соответственно Clojure) можно поспорить (начиная с того, что вообще считать там операторами)
Инструмент нужно выбирать с соответствии с решаемыми задачами.
if not A then B else C == if A then C else B
По поводу поиска — если сценарии использования вашего приложения включают поиск по полям — используйте те средства, которые позволяют его просто реализовать. Например, БД. Или Сфинкс. Или ДокуВики (интересно как там это сделано, не знал про нее).
Если не включают — вы можете использовать что-то более простое.
В случае «сайтов на которых есть только набор статических страниц», пользователю не нужен поиск по полям, ему нужен поиск страниц — с этим прекрасно справляется какой-нибудь Google Site Search.
Разумеется, если вы пишите сайт магазина или социальную сеть — хранение в файлах это совсем не самое лучшее решение, и я не знаю как тут обойтись без БД.
Просто используйте те инструменты, которые подходят к вашей конкретной задаче.
Но, из того, что вы указали преимуществом БД является вообще говоря только одновременный доступ.
Все остальные проблемы (валидация, квотирование, сериализация) решаются или библиотекой работы с БД или кодом в вашем приложении, который с ней взаимодействует.
Точно так же вы можете решать их стандартными средствами и без БД. Например, сериализуя данные в JSON/YAML, для чего сейчас практически везде есть стандартные средства.
Много кода это очевидно хуже чем мало, да. Поэтому, где это возможно лучше использовать готовые средства. Но БД не является единственным таким средством. Например, в руби есть такая штука как PStore, он кстати и проблемы одновременного доступа решает используя атомарные переименования.
Вот когда БД вам действительно нужна — это несколько серверов, работающих с одним набором даннымх. Ну или если вы делаете какие-то выборки кроме как по ключу, конечно.
Но, если вернуться к началу ветки — я все-таки писал о «большинстве современных сайтов на которых есть только набор статических страниц». Мне кажется, что 90% их потребностей покрывают готовые средства вроде Jekyll или PulseCms. И писать строки кода, решающие описанные проблемы там не нужно ни при использовании БД ни без нее.
Я не являюсь противником использования БД. Они крайне полезны во многих случаях. Но мне кажется, что стоит использовать простые решения когда задача это позволяет.
Но вы смотрели, нету ли каких-то уже готовых решений которые в некоторых задачах могут заменить БД не уменьшив ни эффективности разработки ни эффективности решения?
Я, например, упоминал Jekyll. На нем построены GitHub Pages, которыми пользуются достаточно многие, для сайтов проектов, блогов и т.п. И там совсем не надо писать 200 строк сохранение/загрузки. Более того, там не надо писать даже 5 строк. Есть еще некоторое количество менее известных утилит, делающих приблизительно то же самое.
Но, конечно, иногда необходим чтобы клиент мог редактировать контент в браузере и все такое. Для таких случае есть например pulsecms.com/
P.S. Действительно ли сохранение/загрузка файла на диск требует в 40 раз больше кода, чем выполнение запроса к БД?
Ruby:
PHP:
Плюс — не надо подсоединяться к БД, создавать там схему и все такое.
Например, большинство современных сайтов на которых есть только набор статических страниц зачем-то тянут за собой БД. Там как раз не нужно ни хитрых выборок, ни отчетов. Прекрасно можно обойтись просто файловой системой.
На самом деле в таких случаях не нужно даже PHP/Ruby/Python для обработки каждого запроса. Можно все так же удобно сделать через генераторы вроде Jekyll. Но это уже оффтоп, конечно.
Ну и стоит вспомнить еще и о законе текучих абстракций:
www.joelonsoftware.com/articles/LeakyAbstractions.html
Тут суть в том, чтобы скомпилировать приложения использовав все вкусности x64, но при этом 32-битные указатели.