Scala vs Clojure - чья возьмет?

s/Clojure/Scala/ и, за исключением "wants to be a Lisp" истинность фразы не нарушается

в каком месте скала динамический язык?

скобочный синтаксис. та же ниша что и лисп со схемой - в массы не пойдет.

Aaaaaaand! The wiinnner iiis! SCALA!

>У Scala синтаксис нечитабельный.

Фигурных скобок мало? В каком месте у нее синтаксис нечитабельный?

Клохуре - это по испански.

>>> Клохуре - это по испански.

как лодку назовешь...а название гаденькое все-таки :)

>Aaaaaaand! The wiinnner iiis! SCALA!
>r

r - я не поклонник жабатеча, но и не дурак - понимаю что под неё много всего и много кого :-\

Я бы тоже выбрал scala. После явы - уже хоть что то! Пожалуй даже можно уже писать, не содрагаясь всем телом над тупостью езыга :)

Интересно - на scala есть ли какая "нетленка"? Типа рельсов для ребе? Любопытно было бы взглянуть на потуги на "боевое" применение ....

> Интересно - на scala есть ли какая "нетленка"? Типа рельсов для ребе?

Типа lift http://liftweb.net/. Но я не пользуюсь - мне не для веба, ли для веба такого, что рельсы явно нетуда ведут.

дык groovy ускоряют активно:

http://chanwit.blogspot.com/2008/08/java-near-speed-groovy.html

поддерживаю первонаха.

> Интересно - на scala есть ли какая "нетленка"? Типа рельсов для ребе? Любопытно было бы взглянуть на потуги на "боевое" применение ....

Scala применяется в Yandex, Twitter, SAP в продакшене. Фреймворк есть - liftweb. Но всё же лучше что-нибудь по проще, хотя направление у Scala верное.

А вообще дело за LOP.

>А вообще дело за LOP. +1 всеобъемлющие языки устарели.

> Единый стандарт на все нужен только ленивым тупицам. Нормальные спецы любят выбирать инструмент из обилия доступных.

Спецы делают на том, на чем нужно заказчику. И всеравно на чем, так как владеют разными средствами одинаково хорошо. Выбирая мало распространённые средства вы делаете хуже заказчику тем самым проявляя свою некомпетентность.

>Спецы делают на том, на чем нужно заказчику.

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

>. И всеравно на чем, так как владеют разными средствами одинаково хорошо.

То есть по факту знают как проитерироваться по массиву на паскале, си/++, жабе и С#. А хорошо не знают ничего.

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

Ну на то он и чудило. Мы вроде про спецов а не чудил. Виноват тот кто его нанял.


> То есть по факту знают как проитерироваться по массиву на паскале, си/++, жабе и С#. А хорошо не знают ничего.

Т.е. по вашему хорошо владеть 4рьмя языками программирования не реально ? Смешно.
Даже если конкретный разработчик и не знает того за что взялся из вышеперечисленного - всегда можно найти того, кто хорошо владеет или найти помощь/примеры в интернете. Используя малораспространённые приблуды типа Scala, Clojure все может быть намного плачевнее.

>Мы вроде про спецов а не чудил. Виноват тот кто его нанял.

Чудила - заказчик/совладелец конторы. Он сам всех нанял.

>Т.е. по вашему хорошо владеть 4рьмя языками программирования не реально ?

Я думаю те люди которые указывают в резюме десяток языков - на практике пишут на них совершенно одинаково - то есть они на всех языках пишут "по паскалевски", или "сяшно", или "по жабски", или "как на С#". Я не раз и не два сталкивался с проктами по которым совершенно четко можно сказать какой язык является стереотипом стиля программирования - видел как в жабе изобретают mallocки, как умудряются при обработке строк поламать уникод, потому что изобретяют его ручной хендлинг, видел жабские работы сишарпщиков и сишарповские работы жабщиков. И самое главное давно усвоил что человек который утверждает что что-то знает досконально - всегда ошибается. Проверено приблизительно сотней собеседуемых (при чем не далеко студентов). И ошибается не в "хотровыковыряных вопросах", а в основах. Видел как народ изолировал память в тредах, как не понимают что не так в a=b, b=a. И при этом годами работали высокооплачиваемыми программистами.

Так что я и гооврю что уметь написать один и тот же фор на одинаковых императивных, процедурных, обектных языках как жаба, С#, C/++, OP - много ума не надо.

Ума много надо чтобы даже на них писать хорошо, а для этого просто необходимо иметь представления об базовых понятиях в программировании, а не уметь написать for, цитировать GoF, и знать три самых модных фреймворка.

>Aaaaaaand! The wiinnner iiis! SCALA!

Alarm, Alarm! Michael Buffer is here!

>Я думаю те люди которые указывают в резюме десяток языков - на практике пишут на них совершенно одинаково

Это давно известно: Ъ-программист на любом языке напишет Fortran-программу :)

> It does so by making all data structure immutable and by language-level abstractions for concurrent data access. In that respect, it is similar to Erlang as it requires a functional programming style everywhere.

Может уже поэтому можно закопать? Ибо постоянно приходится ковырять персистентные данные, что в функциональный стиль плохо вписывается.

>Это давно известно: Ъ-программист на любом языке напишет Fortran-программу :) quickquest ** (*) (03.10.2008 20:21:41)

Причем строго соблюдая ГОСТ 23056-78 :D

> Чудила - заказчик/совладелец конторы. Он сам всех нанял.

Ну возможно MSACCESS в его случае не самый плохой вариант. У нас в свое время были сервисы на нем с базами свыше 100МБ. И ничего, жужжало.


> И самое главное давно усвоил что человек который утверждает что что-то знает досконально - всегда ошибается.

А знать все и ненужно, а в принципе и невозможно. Нужно уметь быстро и качественно пользоваться справочной литературой. Цель - чтобы приложение делало то что нужно и работало надежно. Все. А внутренние велосипеды устранятся со временем. Полюбому любое приложение проходит обкатку и рефакторинг. Гораздо важнее уметь быстро находить решение.
И таки таки да - для начала достаточно уметь "делать for", знать IO и строить UI. Все просто. Ненадо усложнять.
Конечно это не про критически важные приложения.

>Ну возможно MSACCESS в его случае не самый плохой вариант

Какого только бреда не прочитаешь на ЛОРе...

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

> Вы всерьез полагаете, что поделию, не удовлетворяющему требованиям ACID можно доверить что-то кроме хранения списка покупок на выходные?

Я не полагаю. Я располагаю. Вы можете читать отзывы и тесты, а я видел и работал и знаю о чем говорю. И кто сказал что описанный выше сервис требует что-то более серьёзное чем "список покупок" ?

> Я думаю те люди которые указывают в резюме десяток языков - на практике пишут на них совершенно одинаково - то есть они на всех языках пишут "по паскалевски", или "сяшно", или "по жабски", или "как на С#".

Знеаю нескольких человек, которые владеют несколькими стилями. Не десятью конечно. Но утверждение, что один человек, на каком бы языке не писал, использует один стиль - неверно.

Я после Java пытался написать обьёмную прогу на D. Через месяц понял что использую стиль Java и выкинул 60% классов, заменив их более свойственными D конструкциями. Сейчас при использовании и того и другого стиля проблем не наблюдается.

>Но утверждение, что один человек, на каком бы языке не писал, использует один стиль - неверно.

Я это и не утверждаю. Я утверждаю что человек который знает язык/платформу на уровне "for", IO и UI и не знаком нисчем кроме попсовой императивщины - так делает с высокой вероятностью. Вроде Луговский как-то выразил здравую мысль (он говорил о FP) - человек знакомый с FP на чем угодно будет писать лучше чем человек с ним не знакомый. Обощив эту мысль можно сказать что фундаментальные знания необходимы не для того, чтобы сайты писать на лиспе, а для того чтобы даже на любой жабе писать грамотно.

>я вообще за groovy

Groovy судя по всему R.I.P. Во всяком случае судя по http://groovy.codehaus.org/Download последняя бета была зимой и с тех пор тишина. Какбэ настораживает судьба проекта. Да и ниша у groovy клеевой код для тормозных нетребовательных веб-сайтов, скрипты на скорую руку и т.п. Ни на что серьезное не претендует вопчем, а-ля Перл/Руби/Питон для JVM

Ну разумеется, ACID придумали маркетологи для отъема денег у бедных разработчиков. А чоткие поцаны клали на все эти транзакции.

> Может уже поэтому можно закопать? Ибо постоянно приходится ковырять персистентные данные, что в функциональный стиль плохо вписывается.

Кто меня поправит? Вот http://clojure.org/state описана иделогия, но если кратко -- как я понял -- для person.year_of_birthday=1987; они предлагают копировать весь person, дабы не нарушать функциональщину и проще делать транзакции?

плюсстопицот.

> Ну разумеется, ACID придумали маркетологи для отъема денег у бедных разработчиков. А чоткие поцаны клали на все эти транзакции.

До тебя туго доходит - оно работало. Работало из года в год на корпоративных продакшн серверах. Раз оно работает таки да, пацаны КЛАЛИ на все эти тесты. Никто не говорит что это идеальный вариант, но он ПРИЕМЛИМ, также как и mysql с myisam таблицами.
А теоретики могут продолжать лаять все что угодно, караван будет идти.

Да базару ноль, приемлем. Для хранения списка покупок.

> Ну разумеется, ACID придумали маркетологи для отъема денег у бедных разработчиков. А чоткие поцаны клали на все эти транзакции.

Че-та мне сдается, что держа свои таблички в базе с ACID можно иметь этот ACID даже в Аксессе.

>Кто меня поправит? Вот http://clojure.org/state описана иделогия, но если кратко -- как я понял -- для person.year_of_birthday=1987; они предлагают копировать весь person, дабы не нарушать функциональщину и проще делать транзакции?

А если они правы? Ведь не даром Луговски убеждал нас 5 лет подряд, что ФП рулит, не? Затраты на выделение памяти и создание объекта сейчас в жабе равны нулю, на сборку мусора тем более. А затраты на поиск метода, виноватого в порче shared данных в параллельном доступе к структурам ну ООООООЧЕНЬ большие. Так может стоит копировать таки весь person?

>для person.year_of_birthday=1987; они предлагают копировать весь person, дабы не нарушать функциональщину и проще делать транзакции?

Ну - так происходит в любом орме. Просто там где структуры мутабельные жто надо учитывать - а там где немутабельные транзакции строятся более естественно.

>Так может стоит копировать таки весь person?

В смысле маппинга на базу данных - так происходит всегда. Другое дело что такой подход необязателен - не везде нужны параллельные изолированные транзакции. Можно держать мутабельное дерево которое может обновременно мутироваться несколькими потоками с синхронизацией доступа если надо. Я так и делаю в некоторых проектах. Для этого достаточным условием является безконфликнтая логика.

> Ведь не даром Луговски убеждал нас 5 лет подряд, что ФП рулит, не?

Ты давай аргументы, а не ссылки на (одиозную) личность.

> Так может стоит копировать таки весь person?

А если он большой?

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

> А затраты на поиск метода, виноватого в порче shared данных в параллельном доступе к структурам ну ООООООЧЕНЬ большие. Так может стоит копировать таки весь person?

А может проще залочить?

>В смысле маппинга на базу данных - так происходит всегда.

А меня интересует сам язык, в общем сходи глянь на ссылку, ИМХО дизайнер чересчур зарвался с функциональщиной.

> Затраты на выделение памяти и создание объекта сейчас в жабе равны нулю, на сборку мусора тем более

Афигеть, сборщик мусора работает за отрицательное время %) Память освобождается раньше, чем выделяется O_o

>А может проще залочить?

Тут вообще вопрос интересный в смысле подхода. Возьмем к пример lor. Сколько на самом деле тут мутабельных данных и как часто они мутируют? Взять главную страницу: список статей. Запрос в вебе, заползти в постгрес, выковырять список, материализовать его в виде резалтсета, показать пользователю. И так _для каждого пользователя_ который запросил первую страницу. Она одинаковая (как минимум в виде списка).

Внимание вопрос _нафига_ это делается каждый раз? Вытащить оди раз построить дерево - и рисовать его. При желании рессечь страницу по данным наложить отображение на рессеченные части отображение, все положить в кеш и ассемблить страницу почти мгновенно. Только никто так не делает почему-то.

Почему? Ага - память. Только что-то мне подсказывает что если 8 лет назад памяти на сервак было метра 64, то сейчас пльзовательские десктопы в магазинах содержат 4гб и феномы с четырмя ядрами. Тут коллега говорил о базе данных в 100 метров в аксессе. Да у меня амарок жрет больше! ЗАгрузить 100 метровую базу в память и сбрасывать только мутации на винт - не вопрос.

Да и второй ргумент - а действительно ли база данных загруженная в память будет ее кушать а не _экономить_? А почему она будет ее экономить? А вот тут уже интересный ответ - а сколько _дубликатов_ грузит в память обычная архитектура? Сколько хитов идет в первую страницу лора, сколько народов смотрит одни и те же коменты? Чем больше нагрузка на сайт - тем больше отжирается памяти - при чем учитывая иммутабельность данных на 99% - это все ненужные копии.

Вот только это принципиально другая архитектура.

Я в одном проекте попробовал - в результате серверная аппликуха на жабе перестала вывлезать за 64 метра (раньше приходилось говорить -mx512mb), стала в десятки раз быстре, и проще. Мутабельное дерево с паралельным доступом и локами там где необходимо, безконфликтная логика. И это даже без оптимизации по уже отрендеренному представлению.

>ИМХО дизайнер чересчур зарвался с функциональщиной.

Сам еще не читал руки не дошли - но народ советует прочитать вот это: http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf

>> Затраты на выделение памяти и создание объекта сейчас в жабе равны нулю, на сборку мусора тем более

> Афигеть, сборщик мусора работает за отрицательное время %) Память освобождается раньше, чем выделяется O_o

Не. При работе сборщика мусора jvm параллельно с ним успевает сделать больше, чем в остальное время. :)

В Java кстати уже давным-давно параллельные сборщики мусора есть.

у нас тоже года два назад один активист внедрил базы на MSACCESS. Когда размер перевалил за 300 мб стали периодически записи пропадатьи прочие глюки. На MSACCESS мона только какой нибудь видео салон держать или типа того. Когда бабок жалко.

> у нас тоже года два назад один активист внедрил базы на MSACCESS. Когда размер перевалил за 300 мб стали периодически записи пропадатьи прочие глюки. На MSACCESS мона только какой нибудь видео салон держать или типа того. Когда бабок жалко.

Я тут смотрел резюмешки, там один чудило писал, что организовал OLAP систему на акцессе. Вот я и думаю какой там такой OLAP ?

>А может проще залочить?

А, да, действительно. А потом подпирать сбоку костылями, чтобы бороться с дедлоками и гонками за блокированием? Что только люди не придумают, чтобы не учиться программировать и сэкономить 2кб памяти на выделении нового объекта

:puke:

>Память освобождается раньше, чем выделяется O_o

Спасибо, ржал-валялся. Пеши ищо, интересно читать такие каменты. По теме: для серверного варианта JVM сейчас пишут новый более производительный, ориентированный на многопроцессность и мультипоточность сборщик G1

>Ты давай аргументы, а не ссылки на (одиозную) личность.

Аргументы? А это http://lambda-the-ultimate.org/classic/message10106.html ?

>Вообще, модель <я единственный в мире, вот только иногда где-то кто-то изредка со мной конфликтует, тогда я защищаюсь мьютексом> мне нравится гораздо больше,

VisualBasic ? А мне тоже больше гораздо нравится модель <кинул на форму грид кинул ищо адин кинул группу радиобаттонов написал пару обработчиков событий пошел домой пивко попить. завтра продолжу увлекательное занятие программирование>

>Внимание вопрос _нафига_ это делается каждый раз? Вытащить оди раз построить дерево - и рисовать его.

Внимание ответ: потому что счетчики количества ответов меняются от рефреша к рефрешу, и желательно отдавать клиенту акутальное количество иначе клиент будет расстроен и сделает свой ЛОР, с бэкджеком и т.п.

>> Память освобождается раньше, чем выделяется O_o

> Спасибо, ржал-валялся.

А ты не выдавай перлов типа "затраты на выделение памяти и создание объекта сейчас в жабе равны нулю, на сборку мусора тем более", никто не будет цепляться.

> для серверного варианта JVM сейчас пишут новый более производительный, ориентированный на многопроцессность и мультипоточность сборщик G1

Я знаю. Он типа даже будет обеспечивать детерминированные задержки. Почти всегда, ага. Но вот при этом он будет жрать неиллюзорные ресурсы, так что не надо тут вещать, что расходы на выделение памяти меньше расходов на сборку мусора.

Ну а остальное не я говорил, так что не мне и отвечать.

>Я в одном проекте попробовал - в результате серверная аппликуха на жабе перестала вывлезать за 64 метра (раньше приходилось говорить -mx512mb), стала в десятки раз быстре, и проще. Мутабельное дерево с паралельным доступом и локами там где необходимо, безконфликтная логика. И это даже без оптимизации по уже отрендеренному представлению.

Дык нет проблем. Но ведь ДУМАТЬ надо. А где ты найдешь тех разработчиков, которые будут ДУМАТЬ за $1000/month? Проект здали>убежали, побежали на новый проект, а если они будут ДУМАТЬ, они будут жить хуже бангалорских бомжей

Зайди сюда http://forum.ixbt.com/topic.cgi?id=5:4818 http://forum.ixbt.com/topic.cgi?id=5:13-69 Форум еле ползает и поиск отключается. И это на 4-процессорном оптироне.

как бы бета была в мае, не знаю где вы там нашли зиму.
а баги там открываются и закрываются ежедневно.
сильная нига groovy - это grails, вон недавно SAP выпустил Composition on Grails 1.0

>Внимание вопрос _нафига_ это делается каждый раз?

кто-то неосилил настроить кэш в хибернейте?