LINUX.ORG.RU

привычное vs прогрессивное апи


0

3

Шняжку можно реализовать либо на 1) scala+play+mongo, либо на 2) java+spring+hibernate+mysql

Не касаясь надежности и «ынтерпрайзности» (тупая нетребовательная автоматизация - прохавает что угодно), чисто по красоте и удобству с точки зрения кодера

Первый вариант - новые крутые технологии, позволяющие делать красивую магию. Но незнакомые, не всегда легко изучаемые, и местами сырые. Как гоночная феррари.

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

Какой инстинкт у вас сильнее: дух исследования или домашние тапочки?

Какой вариант привлечет больше новых кодеров?

★★★★☆

Java и жигули - некорректное сравнение, имхо.

А по сабжу - я бы сказал, что зависит от того, насколько это важный проект. Новые штуки - это интересно, но если в результате пострадает качество...

solovey ★★
()

Какой вариант предложить рынку: тот, который валяется на каждом углу и уже всех достал, или тот, который претендует на хоть какую-то новизну? Воистину, тяжелый выбор!

jerk-of-all-trades
()
Ответ на: комментарий от ArturK

Гляди в чем неоднозначность.
Пришел человек домой после работы и решил покодить Just for fun.
Открывает код, вроде бы жава, «да не совсем жава».
И все бы хорошо, но внезапно оказывается, что вот конкретно в этом месте использовать циклы можно, но так неудобно, что хоть вешайся.
Что приводит его к необходимости загуглить мануал по Скале и прочитать конвенции, «зачем сделано так».
А там не просто конвенции, а скажем, целое эссе на двадцать страниц о рефакторинге циклов, объяснение хвостовой оптимизации итп. С одной стороны, можно попробовать принять конвенцию на веру, но тогда следование Вере будет самой меньшей из возникающих проблем.
И это уже серьезная нагрузка на моск. Пока человек продирается сквозь дебри, весь for fun может уже выветриться.
Ну, на работе-то такой проблемы нет, fun, не-fun, Господин сказал кодить под скалу - будешь кодить под скалу, куда ты денешься с подводной лодки.
Но в линуксе-то другая совсем система, люди именно что занимаются днем своей ненужной работой, а вечерами кодят for fun на остатках сил когда уже ничего не хочется.
И по идее, Java как раз отлично сдизайнена для такого применения, даже сквозь прости б-же, спринг, можно продраться на автодополнении в IDE и на копипасте из интернетов, вообще не прилагая интеллектуальных усилий на саму платформу (а направляя их на нечто более важное, типа смысла того, что ты кодишь)

stevejobs ★★★★☆
() автор топика

Выбор делается на основании задачи, а не личных предпочтений (хотя, в соло это важнее). Например, если взять вместо мускла постгрес, то как монго решит с кривым саппортом хранимых процедур часть задач, которые удобно решаются именно таким способом? Далее по монге, как скоро ты задолбаешься писать map/reduce при выборках из нескольких коллекций сразу? Ах, у тебя памяти дофига и места на жестком диске бесконечное: дублицируй все и никакого геммора, как только выйдешь за предел в 16мб (или уже 32мб?) на запись, тогда ты подумаешь о гридфс, ага.

ЯП не играет в данном случае никакой роли, ибо оба строятся на VM. Другое дело C/C++ vs Java/Scala, или Haskell vs Java.

gh0stwizard ★★★★★
()

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

f1xmAn ★★★★★
()

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

unt1tled ★★★★
()
Ответ на: комментарий от gh0stwizard

или Haskell vs Java

в чем разница между haskell vs scala в плане апи (а не научных вычислений)? То, что в хаскеле ленивость более естественна? Да и на скале легко все это запилить, если совсем уж не офигивать, типа специально писать бесконечные циклы которые каким-то образом «не цепляются» и поэтому прога работаепт якобы-корректно на хацкеле и повиснет на чем-то другом

stevejobs ★★★★☆
() автор топика
Последнее исправление: stevejobs (всего исправлений: 1)

ИМХО креативность надо вкладывать в проект, а не в исследование инструментов. Понимаю конечно что жаба это неуклюжее нечто.

Absurd ★★★
()
Ответ на: комментарий от stevejobs

Никакой неоднозначности нет.

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

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

jerk-of-all-trades
()
Ответ на: комментарий от jerk-of-all-trades

И предлагая вакансию скала-разработчика

имеется в виду free/opensource community, кодящее линукс в свободное от работы дворником либо ночным сторожем время, а не fulltime job для узких корпоративных специалистов

stevejobs ★★★★☆
() автор топика

привычное vs прогрессивное апи

Я бы не стал противопоставлять. Так называемое «прогрессивное» очень часто оказывается таким отстоем. Я не говорю конкретно. Просто общее наблюдение.

dave ★★★★★
()
Ответ на: комментарий от stevejobs

Так все еще проще: получать фан от разработки на джаве могут только редкие мазохисты, которые и так работают явистами. Много ли среди них двойных мазохистов, желающих и после работы заниматься тем же самым? Сомневаюсь.

Редкие же языки подходят в качестве отдыха и разминки для мозга, так что привлечь кодеров проектом на скале/хаскелле/эрланге более реально.

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

jerk-of-all-trades
()
Ответ на: комментарий от stevejobs

в чем разница между haskell vs scala в плане апи (а не научных вычислений)?

Я не об апи. А о том, что создавались языки для разных целей. И если scala это компонентно-ориентированный язык, то хаскель это чистая функциональщина. Конечно, типовые задачи решаются одинаково, но узкоспециализированные решаются особенностями ЯП. Вот для примера сравнение Haskell vs F# vs Scala.

gh0stwizard ★★★★★
()

mongo

Как можно юзать в качестве основной БД штуку, где нету никаких механизмов обеспечения целостности базы?

provaton ★★★★★
()
Ответ на: комментарий от stevejobs

Так-то оно так, но как же мы получим развитие, если никто не будет продвигть новые технологии? Как раз таки большинство нового привносит коммерческая разработка, а не for fun.

Без серьёзной заинтресованности разработчиков линукс так и будет топтаться на месте. Человек либо должен хотеть заработать и поэтому будет учиться, либо быть фанатиком и опять же учиться. Только так возможен прогресс.

ArturK
()

позволяющие делать красивую магию.

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

true_admin ★★★★★
()
Ответ на: комментарий от stevejobs

какие еще есть претензии к mongo?

стрёмный язык запросов :) Эдакий лисп для SQL.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Под этим подразумеваются транзакции?

Не только. Хотя бы банальный NOT NULL там есть? Отслеживание foreign key? Каскадное удаление? Триггера?

provaton ★★★★★
()

Какой вариант привлечет больше новых кодеров?

Тут следует поднять еще другой вопрос - в каком варианте кодеры будут грамотными специалистами, а не формошлепами, продирающимися сквозь Spring на автодополнении?

rand
()
Ответ на: комментарий от stevejobs

Да в принципе никаких претензий у меня больше нет. Просто как-то привык хранить структурированные данные в чем-то, что хоть как-то может гарантировать сохранность их структуры. А монго, получается, просто свалка json-документов произвольной структуры.

provaton ★★★★★
()
Ответ на: комментарий от provaton

Хотя бы банальный NOT NULL там есть? Отслеживание foreign key? Каскадное удаление? Триггера?

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

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

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

а кому нужно хранилище без транзакций и триггеров

Я сказал не так, а «кому нужно такое хранилище в качестве основной БД». Хотя надо было сказать не «основной», а «единственной». Я вполне за то, чтоб использовать несколько СУБД в одном проекте, разделяя четко структурированные табличные данные, и данные к которым не предъявляются такие жесткие требования по структуре.

provaton ★★★★★
()

Шняжку можно реализовать

...да на чем угодно - всем пофиг.

tailgunner ★★★★★
()
Ответ на: комментарий от provaton

ну если взять искаробочный линукс, то у нас вообще конфиги хранятся плейнтекстом в /etc/**.conf в непонятном формате, какой уж тут acid

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от stevejobs

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

У монго безусловно есть своя ниша. Просто я б ее юзал все-таки второстепенной БД для оптимизации, а не основной. Хотя, с удовольствием бы послушал аргументированные мнения, отличные от моего.

provaton ★★★★★
()
Ответ на: комментарий от stevejobs

у нас вообще конфиги хранятся плейнтекстом в /etc/**.conf в непонятном формате

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

Это не то же самое что потерять платёжную информацию, например, когда юзер в одной вкладке жмёт «оплатить», а в другой «очистить корзину» :)

true_admin ★★★★★
()
Ответ на: комментарий от provaton

Вот, например: http://habrahabr.ru/post/149047/

Лично меня даже больше волнует не консистентность данных силами ДБ, а как их не потерять в случае того что свет моргнёт/сервер повиснет или вообще сдохнет.

true_admin ★★★★★
()

Лучше бери кложуру - это модно, молодежно, прогрессивно.

alienclaster ★★★
()
Ответ на: комментарий от true_admin

Ну вот оттуда цитата:

Всегда будьте готовы к нецелостной информации.

А дальше там идет предложение написать собственные костыли для обеспечения целостности. Зачем, если они уже один раз реализованы и отлажены в реляционных СУБД?

provaton ★★★★★
()
Последнее исправление: provaton (всего исправлений: 1)
Ответ на: комментарий от provaton

Угу. Конкретно mondodb не обладает развитыми средствами обеспечения консистентности. Это не значит nosql == «no transactions». Гугловая база (big table или то что поверх), например, транзакционна.

Но в целом, имхо, надо менять подход к проектированию. Вот тут есть некоторые мысли: http://stackoverflow.com/questions/2212230/transactions-in-nosql

Впрочем, например, я наблюдал неконсистентность данных и в mysql (возможно, результат падения) и postgres (тут уже могли программисты намудрить, проект был ппц).

true_admin ★★★★★
()
Ответ на: комментарий от buddhist

ты точно не путаешь с clojure? ))))))) ((там в скобках можно потеряться)). Какие конкретно претензии к скале? (олсо, ты, надеюсь юзаешь IDE, а не блокнот? В блокноте действительно тяжко, но блокнотоюзеры должны страдать :-)

stevejobs ★★★★☆
() автор топика
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от kovrik

У монго особенность - она лочит всю бд целиком при записи. Раньше лочился весь сервер.

кто нибудь терял в производительности из за этого?

OxiD ★★★★
()
Последнее исправление: OxiD (всего исправлений: 1)

А я писал тебе в гугл+, а ты проигнорил. А еще координаты в профиле оставил, как приличный.

cdshines ★★★★★
()

Пиши на скале, у них ржачный чятик. Вот уже полчаса сидят и пинают чатбота по поводу выражений в xml: https://dl.dropboxusercontent.com/u/12869350/snapshot93.png

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

cdshines ★★★★★
()
Ответ на: комментарий от cdshines

Ээээ знаешь, я даже на сотовый не отвечаю уже недели две) И почту не читаю - вначале автоматически жал «отметить всё как прочитанное», потому понял, что ее можно просто не открывать. И скайп в инвизе, итп. Не обижайся, пожалуйста.

stevejobs ★★★★☆
() автор топика

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

amomymous ★★★
()

Довольно странно, что у вас нереляционная и реляционная базы взаимозаменяемы.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.